JText::_('Add "Install from Web" tab')
is not a correct language constant
Suggest to use

COM_INSTALLER_INSTALL_FROM_WEB_TAB=

@infograf768 good catch ! Have added language string for the description, with meaningful markup.

Ok, Real Plugin is now done and installable in one-click, and server has been adapted too. So it's ready for tests.

Plugin name in xml should be:
<name>plg_installer_webinstaller</name> // to be translatable by the ini files

The xml should include language as a folder
<folder>language</language>
to display correctly the sys.ini when installing

Also, the ini and sys.ini files should be already added in the core language folder when committing this PR BEFORE installation of the plugin, as otherwise the plugin name and description will not be translated by TTs.

Also, I would add the new "Install from Web Tab" last as users are used to present UI.

@infograf768 :

Thanks for the well-thought feedbacks

1. We have added the language strings and language files as suggested (indeed very good idea!)
2. We have added a parameter to choose the tab position (first or last) in the plugin's parameters (basic options), that way each admin can set the tab position to the right setting for his site.

We have tested by 2 devs everything in these changes, and all is ok.

Everything should be deployed on the CDNs by around 8:00 AM French time, and if you still have the previous 1.0.0 plugin installed, you should see the nice "Update" button to 1-click update the plugin to 1.0.1 that implements the tabs setting and use of new language files. Otherwise no problem, the Install button will install the right version by then.

So we addressed all testers' feedbacks, and this should be ok for merging this PR.

Just fixed language strings as suggested by Brian on tracker, and added a tooltip to the close box of the JED message at top to avoid any surprises for going to options settings which is by design so people learn where the setting is if they want to re-enable it later.

So all reported improvement suggestions on this PR have been taken care of.

Improved language strings for Joomla! Extensions Directory to match exactly the official name, as reported by Brian on tracker.

With 2 successful tests on this FR, this PR is now ready.

With 2 successful tests on this FR, this PR is now ready.

Wow. Can I submit my pet project and have it merged into 3.2 as well? What happened to due process here?

Seriously though, why are we providing support for a 3rd party plugin that is not provided with core? Fine, mess with the ability for a plugin to interact with com_installer - I have not problem with that (apart from the lack of consultation). But you don't add parameters to the core to support it - you do it with the plugin itself. What on earth are you guys thinking?

This PR sets a dangerous precedent.

Recommendation:

Remove plugin language files, setting from com_installer's configuration and "app store" specific code from layouts. I'm ok with the rest objectively speaking but I don't think it has been thought through very well.

@eddieajau :
Just to clarify an obvious misunderstanding:

1. It's not a third-party plugin. It's an official Joomla extension, a plugin that has been discussed on Joomla groups and approved by PLT, and that is hosted by Joomla itself on Github (contributions and PRs welcome as usual).
2. The basic language strings have been requested to be in the core by the official Joomla Translations Manager on the FR tracker, to allow the installation process itself in the user's language and to be translated by the accredited Joomla translation teams. So makes fully sense for an official extension.
3. Finally this plugin is for the official JED, not a third-party.
4. PLT has decided on a strategy to have core but optional extensions. This is just the first one of a lot to come.
5. There are no settings in com_installer except the disabling/enabling of a message that there is a JED and a way to use it simply.
6. There is no specific code for this plugin in layouts nor in any other code part.
7. Reimplementing this as a separate official plugin just corresponds to the changes suggestions of PLT that have been formulated on public CMS development discussion group and has been approved by PLT.
8. Finally, it corresponds to the Year 2013 Joomla goals, recommendations and implementation and design specs.

And to clarify your misunderstanding:

It's not a third-party plugin

Yes it is. It's not core so it should be treated as a 3rd party extension, optional extension. You've put in code to advertise its existence which is an unacceptable and sloppy coupling in my view. I don't care if the Pope wrote the extension - it's about separation of control.

Where is the information about the plugin by the way? I must have missed the announcement on list again. Can you point me to your post about it and your request for comment?

The basic language strings have been requested to be in the core by the official Joomla Translations Manager

This should have been discussed on list with other developers that are also interested in making distributions. Do I need to remind you of your posts concerning changes you didn't like in 3.0? I can find them if you like.

Finally this plugin is for the official JED, not a third-party

Who cares - and that's no excuse for writing sloppy code. You are still coupling an opt-in extension to the core.

PLT has decided on a strategy to have core but optional extensions

I know - I helped put the idea in the roadmap itself. But I envisaged we as a community of developers would all talk about how we would implement change and organise ourselves to reach this goal. Once again you've decided to take things upon yourself limiting contribution to a select few people.

There are no settings in com_installer except the disabling/enabling of a message that there is a JED and a way to use it simply.

This approach is unacceptable and just plain stupid in my view. Really? An option to turn a message on and off?

There is no specific code for this plugin in layouts nor in any other code part

http://appscdn.joomla.org/webapps/jedapps/webinstaller.xml

Want me to keep going?

Reimplementing this as a separate official plugin just corresponds to the changes suggestions of PLT that have been formulated on public CMS development discussion group and has been approved by PLT

Then how about you include other people in the process, communicate what you are doing, answer questions that are asked of you and listen to advice?

Finally, it corresponds to the Year 2013 Joomla goals, recommendations and implementation and design specs

Yes, yes, yes - so you've said and I'm not going to repeat what I've already said and you've refused to listen to.

@davidhurley, why is this being merged when we don't even really have the working group on distributions up and running properly, let alone making any sort of recommendations for how we should handle cases like this (and I can tell you, if this is the standard we are setting, I'm finding another FOSS project to contribute to)? In addition, why has this PR been "snuck in" way after feature freeze deadline? Given the initial lengthy discussion, I would have found it prudent to call for more than "2 testers" (which weren't developers) for approval.

@Beat, here's an example of how I'd approach your problem (before you falsely accuse me of just complaining - again).

You want to advertise the existence of your plugin. Ok, that's fine and I have no issue with that. How do we solve that problem? Not by hardcoding the advertisement that's for sure. So why don't we look at a way to have an advertising space that can hook to an official feed? Hrm, that could be useful for other types of messages as well in the future (VEL, important extension news, whatever). And if you approach it like that, a setting to toggle the "advertising bar" on and of makes perfect sense (and you don't have to do crazy things like include language files from an optional extension).

That is just one idea. I'm sure if given the chance our community of developers will come up with many more (two or three other and generically sustainable ideas just popped into my head).

@davidhurley I apologise. It's not hard to see the PLT is between a rock and a hard place. You don't have to be a rocket scientist to realise this feature is motivated more by politics than sound engineering judgement.

My suggestion, shared previously by the way (but not yet fully acted upon
probably because of the same time crunch and burn out issues everyone else
has been dealing with), is to do the advertisement in the postinstall
message component. Advantage is the message is in the code where it should
be, even if it's still hooking some piece of an external extension into
core. Disadvantages are the postinstall notification can be ignored if
someone doesn't realize what they're doing and the message isn't in the
extension manager.

On Wed, Oct 9, 2013 at 4:48 PM, Andrew Eddie notifications@github.comwrote:

@Beat https://github.com/Beat, here's an example of how I'd approach
your problem (before you falsely accuse me of just complaining - again).

You want to advertise the existence of your plugin. Ok, that's fine and I
have no issue with that. How do we solve that problem? Not by hardcoding
the advertisement that's for sure. So why don't we look at a way to have an
advertising space that can hook to an official feed? Hrm, that could be
useful for other types of messages as well in the future (VEL, important
extension news, whatever). And if you approach it like that, a setting to
toggle the "advertising bar" on and of makes perfect sense (and you don't
have to do crazy things like include language files from an optional
extension).

That is just one idea. I'm sure if given the chance our community of
developers will come up with many more (two or three other and generically
sustainable ideas just popped into my head).

—
Reply to this email directly or view it on GitHub#2143 (comment)
.

Do you mean as a part of the Installation application itself? If that's what you meant, I'd be ok with that.

I think there is a common consensus that a message system which can be used by multiple extensions is indeed a desirable solution. Time constraints and current workloads prevented that from being implemented immediately and Michael and I both discussed the use of the postinstall message component as a possible solution. I hope this can be continued to be improved upon over time. In my opinion that's one thing I love. Nothing is set in stone - we can continue to make changes and improvements to the CMS as we go along.

Let's get more discussion about the actual implications of a message system (or the post-install message component) and how it could be used by other extensions as well.

One thing worth noting is that the installation application piece is not seen at all if the user installs Joomla! via a third-party control panel (such as Softaculous or Fantastico). I think this is something we've neglected to consider a bit as we continue to build out the Installation application. We need to take this into account and make the options available in a second post-install location rather than just within the install process and the installation application.

No, I mean our actual postinstall messages component, the CMS' first RAD built component incidentally. See https://github.com/joomla/joomla-cms/tree/master/administrator/components/com_postinstall for
the display and https://github.com/joomla/joomla-cms/blob/master/installation/sql/mysql/joomla.sql#L1978 for
the current dataset. https://github.com/joomla/joomla-cms/blob/master/administrator/components/com_cpanel/views/cpanel/view.html.php#L52-76 is
one way of displaying a notification (in that case, it's a modal on the admin cpanel, just after the user logs in). The same snippet could be reused changing the eid in the FOFModel::getTmpInstance() call for any extension to implement it.

It certainly isn't a perfect solution (there's still debate about how to display the notification & what should go in there) but in terms of actions, it is spot on for making things simple for users.

On Wed, Oct 9, 2013 at 5:29 PM, Andrew Eddie notifications@github.comwrote:

Do you mean as a part of the Installation application itself? If that's
what you meant, I'd be ok with that.

—
Reply to this email directly or view it on GitHub#2143 (comment)
.

Ok I wasn't aware that even existed. Is there some more information I can peruse rather than asking you dumb questions :)

New component for 3.2, merged after the alpha package last month. This beta will be its first public demo. :-)

The links I posted are pretty much the relevant pieces. There's also the actions piece (https://github.com/joomla/joomla-cms/blob/master/plugins/twofactorauth/totp/postinstall/actions.php) worth taking a look at. I haven't fully studied through the technical aspects of the code myself yet, I just know we've got a system in the CMS we desperately needed now.

Damn, so many new toys to play with - I can't keep up :)

Ok, I get the post-install component thing. Yes, this definitely need to be refactored to use that. @Beat, do you think you can do that?

I already wrote a module which can show the postinstall message notification. My plan was to expand it a bit further so it would automatically search for messages for the active component. With this one could simply load the module within the extension manager and it would check if there are messages related to it.
Unfortunately my idea was shot down badly initially, but if there is interest I can still do that.

So, the root cause here is that the plugin is not including its own language files. If it did, the problem goes away and you don't need to include the language files in the core. It's a bug in the plugin, nothing more, nothing less.

@eddieajau wrote:

It's a bug in the plugin, nothing more, nothing less.

Sorry, wrong "root cause" reasoning, and thus wrong conclusion too, eddieajau : Netiquette says to read a conversation before adding to it: See the request above of Joomla Translations Manager infograf768 before jumping to wrong conclusions and accusing the Apps* team of bugs and lack of knowledge. Nothing more too, nothing less either. Thanks.

I also note that you didn't read my full explanation there on the language too, despite replying to it there:
https://groups.google.com/d/msg/joomla-dev-cms/3QOB6INv6i0/rBP7_FCNjF8J
or ignored it.

If you want to put in place better Translations Teams tools that allows them to translate N packages in addition of core Joomla or help the lots of work that managing so many teams is, got for it, volunteer and just do it :-)

As this PR is merged and closed, best is to not duplicate your conversations of groups here, and just do conversations on google groups, as this is the place for work. Thanks.

I did a PR with a module to show a postinstall message in an extension. Would that be a possible solution?

It's not ready yet to merge but I would be interested in opinions.

@beat, I did read your explanation, I just don't agree that you made the right call (and you frequently ignore most of my questions, not least of which is asking where the plugin code lives). Let me explain.

Joomla has always been designed for extensions to install their own language files. Extensions should never, ever request that their local language files need to be included with the core in order for the extension to work. I understand JM's problem, but this is a process problem and you've chosen to "hack the core" to solve it. We are going to need to discuss this type of issue with the TT's because as we move forward with distributions, this "process problem" is going to get worse. Solving it by slapping every possible official extension's language files in that core is totally impractical and it doesn't scale Beat.

Secondly, you are setting a bad example for all other extension developers. You are saying when a problem is too hard, we'll "cheat" because we can. I'm sure every other language developer would like the ability for the Joomla Translation Teams to provide translations. In fact, I've already asked that question but we still haven't found a suitable answer (nor have you).

Thirdly, you'll claim that this is an "official" extension and that makes it all better. Please show me the discussion about what constitutes an "official extension"? We have no rules or regulations or expectations about what they actually look like so whatever arguments you put forward are simply your unofficial opinion. You are just making the rules up as you go alone to suit yourself. I don't mind if that's the case, just be honest about it and stop spinning up a "he made me do it" scenario.

Finally, this PR is where the code is so it's the perfect place to be discussing YOUR code. I'm not sure why you would think it's logical to respond to my questions about your PR in a Google Group.

In conclusion, I think you should do the right thing and remove the language files and put them in the plugin where they belong - that is how they are supposed to be designed. I'm still less than impressed with the rest of your proposal, but I honestly can't be bothered arguing with you about it. You then need to talk to the TT's about how they can help you maintain language files for you extension (that's what every other extension developer has to do). This is a problem we need to solve. Yes, it's the harder way to approach the problem.

What I'm going to do is flag a number of things to discuss:

1. Define what an "official extension" is because this will overlap with the Distribution WG.
2. Define what the rules, responsibilities and expectations are for an "official extension".
3. Work with the TT's to find amicable solutions for how to manage translations in a distributed environment.

The point here, Beat, is that you ask your peers to help sort out issues that are going when those decisions are going to affect everyone. You made exactly the same claims around the time 3.0 was released and you found things had changed without your apparent knowledge.