Simplifying the installer

[Hannes Papenberg]

Hi folks,
during the development from 1.5 to the current code, we added quite a
few views to the installer component. We originally started out with the
"install" and "manage" view and right now we have 7 views in that
component, some of them pretty similar.

In order to reduce the code size, make it easier to use and to maintain
and to put the "power through simplicity" back into Joomla, I'd like to
propose to do a little cleanup here. From my POV, we can merge some of
the views and make the UI a bit more consistent in comparison to the
rest of the core components.

I have the following proposals:

1. Merge the "database" and "warnings" view into one combined "warnings"
view. That would move all system-status messages of that component onto
one screen.

2. Merge the "discover" and "manage" view into one combined "manage"
view, where the discoverable extensions are a filter option. That would
fit more into the scheme of us having the "Trashed" status for content
items.

3. Merge the "update" and "manage" view into one combined "manage" view,
where the updateable extensions are a filter option. That would also fit
more into the above mentioned scheme.

The general idea is, that you only need one view to display lists of
extensions in the installer. In the end, both the discover and the
update view are only lists or even rather filters on the manage view. So
we should handle it that way.

I took the liberty and started with #1, which you can find here:
https://github.com/Hackwar/joomla-cms/tree/installer

One thing to keep in mind when this should be accepted is, that we
should still provide a shortcut to the updates- and discoverable-list
and that some of the lingo that we use in the installer right now would
have to be changed. (for example, the warnings view might become a
maintenance view or something like that.)

What do you think about that proposal?

Hannes

[Gary Jay Brooks]

Should I be able to download the the zip file, upload to hosting directory, and see the installer?   

[Hannes Papenberg]

I was talking about com_installer in the backend, not the installation
of Joomla.

Hannes

> --
> You received this message because you are subscribed to the Google
> Groups "Joomla! CMS Development" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to joomla-dev-cm...@googlegroups.com.
> To post to this group, send an email to joomla-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/joomla-dev-cms.
> For more options, visit https://groups.google.com/groups/opt_out.

[Ofer Cohen]

Hey Hannes

I see the next pull request lately: https://github.com/joomla/joomla-cms/pull/2170/

I would suggest to make some coordination to reduce the merges between the two requests.

Thanks, Ofer

Hannes

[Hannes Papenberg]

I guess that Don actually talks about the installation of Joomla, while
I'm talking about the extension installer of Joomla. ;-)

> <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com>.

> To post to this group, send an email to
> joomla-...@googlegroups.com

> <mailto:joomla-...@googlegroups.com>.

[Matt Thomas]

Hi Hannes,

I very much like this idea and putting "power through simplicity" back into Joomla.

+1

Best,

Matt Thomas
Founder betweenbrain™
Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

Sent from mobile. Please excuse any typos and brevity.

[Ofer Cohen]

oopssi...

Ofer Cohen

http://embad.com 
Facebook | Twitter | LinkedIn

[Hannes Papenberg]

Ok, so unless I get some negative feedback here, I'll open up a pull
request then. :-)

Hannes

Am 08.10.2013 14:18, schrieb Matt Thomas:
>
> Hi Hannes,
>
> I very much like this idea and putting "power through simplicity" back
> into Joomla.
>
> +1
>
> Best,
>
> Matt Thomas

> Founder betweenbrain�

> Lead Developer Construct Template Development Framework
> Phone: 203.632.9322
> Twitter: @betweenbrain
> Github: https://github.com/betweenbrain
>
> Sent from mobile. Please excuse any typos and brevity.
>
> On Oct 8, 2013 8:04 AM, "Hannes Papenberg" <hack...@googlemail.com

> <mailto:hack...@googlemail.com>> wrote:
>
> I guess that Don actually talks about the installation of Joomla,
> while
> I'm talking about the extension installer of Joomla. ;-)
>
> Am 08.10.2013 13:53, schrieb Ofer Cohen:
> > Hey Hannes
> >
> > I see the next pull request
> > lately: https://github.com/joomla/joomla-cms/pull/2170/
> > I would suggest to make some coordination to reduce the merges
> between
> > the two requests.
> >
> > Thanks, Ofer
> >
> >
> > On Sun, Oct 6, 2013 at 2:08 PM, Hannes Papenberg
> > <hack...@googlemail.com <mailto:hack...@googlemail.com>

> <mailto:hack...@googlemail.com

> > <mailto:joomla-dev-cms%2Bunsu...@googlegroups.com
> <mailto:joomla-dev-cms%252Buns...@googlegroups.com>>.

> > To post to this group, send an email to
> > joomla-...@googlegroups.com
> <mailto:joomla-...@googlegroups.com>

> > <mailto:joomla-...@googlegroups.com

[Donald Gilbert]

Ofer, Hannes is correct. I'm referring to the Joomla! Installation Application, which you see / use when you first install Joomla.

Hannes is working on the admin com_installer component.

[Andrew Eddie]

Just an addition for the "todo" list on this one. For some unknown reason, normal installation and discovery installation is handled by different code (and, in the case of plugins, it will honour SQL files under normal installation but not via a discovery installation). Getting normal and discovery installation to work with the *same* code would be a big help.

Regards,

Andrew Eddie

[Michael Babker]

Several months back, Matias and I were working on a refactored Installer library (which is still separate to the install app and com_installer, who named these things!?  LOL) with a goal of streamlining that code.  Reducing code duplication, killing JObject dependencies, just overall making things more manageable.  See https://github.com/joomla-projects/joomla-cms/tree/feature-JInstaller/libraries/cms/installer for the library code.  The install path is actually streamlined now in that branch with the same feature set across all extensions (another thing missing right now).  It's a viable goal to finish that library and get it into 4.0, just a matter of sitting down and starting work on it again.

--

[Andrew Eddie]

On 9 October 2013 14:46, Michael Babker <michael...@gmail.com> wrote:

Several months back, Matias and I were working on a refactored Installer library (which is still separate to the install app and com_installer, who named these things!?  LOL) 

Well, on that note, could/should com_installer be renamed to com_extensions (aka the Joomla Extensions Manager)? 

Just thinking out loud further, Hannes, what do you think about doing the refactor under the banner of com_extensions (or pick another name) and having that testbed the "official extension" idea that is floating around? That also paves the way for the new JED listing features to plug into it and, potentially, give us an avenue for back-porting/back-supporting 2.5 with the same features. The idea being we could make com_extensions useful for the 3.x tree and if it proves itself, it drops straight into 4.0 (or, we can do something different if the development strategy gets revised).

Again, just thinking out loud but it might help kill a few birds with one stone.

Regards,

Andrew Eddie

[Hannes Papenberg]

Hi Andrew,
works for me. I guess its mainly a question for the higher powers of the
project. ;-)

Hannes

Am 09.10.2013 06:56, schrieb Andrew Eddie:
> On 9 October 2013 14:46, Michael Babker <michael...@gmail.com

[Bakual]

Just thinking out loud further, Hannes, what do you think about doing the refactor under the banner of com_extensions (or pick another name) and having that testbed the "official extension" idea that is floating around? That also paves the way for the new JED listing features to plug into it and, potentially, give us an avenue for back-porting/back-supporting 2.5 with the same features. The idea being we could make com_extensions useful for the 3.x tree and if it proves itself, it drops straight into 4.0 (or, we can do something different if the development strategy gets revised).

 

I think the idea of a standalone component for the "install from web" feature is dead by now. It's now built as an optional plugin (with advertisment banner) in the installer. I don't currently see how this could be backported to 2.5.

See PR https://github.com/joomla/joomla-cms/pull/2143 for more information. 

[Andrew Eddie]

On 9 October 2013 18:00, Bakual <werbe...@bakual.ch> wrote:

 

I think the idea of a standalone component for the "install from web" feature is dead by now. It's now built as an optional plugin (with advertisment banner) in the installer. I don't currently see how this could be backported to 2.5.

See PR https://github.com/joomla/joomla-cms/pull/2143 for more information. 

(facepalm) so much for due process. 

Regards

Andrew Eddie  

--

Regards,
Andrew Eddie
http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

[George Wilson]

In fairness to the team - the PLT were the ones who asked for the plugin - so that's what was delivered.

As far as I'm aware there are still plans for the plugin to be back ported to 2.5 (although feel free to correct me!)

But in my opinion the best thing we can do now is make the plugin as stable as possible - so it can be a core feature rather than a plugin. I think having the App Store in core is essential to the JLite idea

Kind Regards,
George

[Andrew Eddie]

On 9 October 2013 19:57, George Wilson <georgeja...@googlemail.com> wrote:

In fairness to the team - the PLT were the ones who asked for the plugin - so that's what was delivered.

The plugin is not the problem. 

Adding new triggers and display elements to support new plugins for com_installer is not the problem (lack of documentation for the new feature aside and I don't think much thought was been given to the new events - "onInstallerViewAfterLastTab" - seriously? but whatever).

The problem is adding a 3rd-party extension's language files (/administrator/language/en-GB/en-GB.plg_installer_webinstaller.*ini) to the core and a setting in com_installer (COM_INSTALLER_SHOW_JED_INFORMATION_LABEL). Adding display elements to support said plugin in layout files IS a problem. The plugin should carry its own language files and manipulate JForm appropriately (stand on its own two feet in other words). The problem is the changes to com_installer only benefit this one, new plugin. Those modifications should be reverted prior to release of 3.2 (and I would say the same thing to anyone trying to slip a non-essential PR in under the radar four days ago as well). It sets a ridiculous precedent.

Would appear that Hannes has a chance to get these changes into 3.2 after all ;) I agree with the general direction of this proposal by the way. How about we discuss how to support installer plugins into the mix (which I, ironically, think is not such a bad idea)?

Regards,

Andrew Eddie

[piotr_cz]

If you'll be working in the installer, consider looking at how menu items in administration are created.

There's some inconsistency in the components from Joomla installation manually installed ones.

• during installation menu items for core components are created with [`menutype = menu`](https://github.com/joomla/joomla-cms/blob/master/installation/sql/mysql/joomla.sql#L1248)
  
• new components are installed with [`menutype = main`](https://github.com/joomla/joomla-cms/blob/master/libraries/cms/installer/adapter/component.php#L1266)

I'm not sure if there is any reason behind it, but this is an obstacle when using form field menuitem - can't specify both menu_types.

I discovered there's actually quite a mess in Administrator menu system (logic in administrator/modules/mod_menu/menu.php instead of libraries/cms/menu/administrator).

[Bakual]

The problem is adding a 3rd-party extension's language files (/administrator/language/en-GB/en-GB.plg_installer_webinstaller.*ini) to the core and a setting in com_installer (COM_INSTALLER_SHOW_JED_INFORMATION_LABEL). Adding display elements to support said plugin in layout files IS a problem. The plugin should carry its own language files and manipulate JForm appropriately (stand on its own two feet in other words). 

The code in view, layout, language files and config is all about the advertisment message for the new plugin. It can't be put into the plugin itself since it's not installed yet. So I see the reason for that being in the core. If you really want to show that message in this place, then you need that code.
However I fully agree with Andrew that it doesn't look right to have code in core which is targeted for a single (currently non-core) plugin.

I think instead of messing around with all that, one could have used the new postinstall message instead (if we finally get rid of the popup there it would be a good fit). Or use other places for the advertisment, like a prominent place on the JED where those searching for extensions will all land sooner than later. Or maybe it's possible to just enqueue a message from within the view, then at least it would not need changes in the layouts. There would be multiple options to make it better (imho).

[Andrew Eddie]

On 9 October 2013 21:07, Bakual <werbe...@bakual.ch> wrote:

The code in view, layout, language files and config is all about the advertisment message for the new plugin. It can't be put into the plugin itself since it's not installed yet. So I see the reason for that being in the core. If you really want to show that message in this place, then you need that code.

However I fully agree with Andrew that it doesn't look right to have code in core which is targeted for a single (currently non-core) plugin.

Yeah I understand, and in an earlier brain spurt, I think I might have even suggested something similar, but I would never have suggested to half install a plugin to make it work - it needs to be fully core, or fully optional. I have no problem with the project marketing the socks off the plugin, but we need to invent a way for it to work that is not exclusive to it (in exactly the same manner that, for example, people can implement different types of commenting solutions in articles - it's exactly the same type of engineering issue in my opinion). I have to admit, the thought of installer plugins is enticing, but let's not just slap any old code in the core.

Gosh, the sooner we split the CMS up into a family of extensions that can be built into custom distributions the better - it will stop these sorts of arguments.

Regards,

Andrew Eddie

[Hannes Papenberg]

> Gosh, the sooner we split the CMS up into a family of extensions that
> can be built into custom distributions the better - it will stop these
> sorts of arguments.

That said: When can we do that? Nothing is keeping us from doing that
right now and have it split up for 3.5. I'm not talking about doing all
the stuff necessary to have the complete distribution standing, but at
least having the different projects seperated out, defining maintainers
for the subprojects, cleaning up the issue trackers into the different
subprojects, etc. We can still then take those extensions, slap them
together, zip that up and provide it as a CMS installation for Joomla
3.5. But if we don't start with it now, we wont do it for 4.0 either,
because from my perspective, it will take longer than 6 months to
implement all and everything necessary for this.

Which again would bring up the discussion about our failed development
strategy.

Hannes

@Andrew: I don't necessarily want the changes that initiated this thread
to be part of 3.2. This was a proposal so far and I'm not sure this is
primetime ready yet, so it would be nice, but I also wouldn't break out
in tears when it wouldn't be a part. Your idea to use this as a
test-ballon for a core component is very appealing to me.

[Andrew Eddie]

On 9 October 2013 22:24, Hannes Papenberg <hack...@googlemail.com> wrote:

> Gosh, the sooner we split the CMS up into a family of extensions that
> can be built into custom distributions the better - it will stop these
> sorts of arguments.

That said: When can we do that? Nothing is keeping us from doing that
right now and have it split up for 3.5. I'm not talking about doing all
the stuff necessary to have the complete distribution standing, but at
least having the different projects seperated out, defining maintainers
for the subprojects, cleaning up the issue trackers into the different
subprojects, etc. We can still then take those extensions, slap them
together, zip that up and provide it as a CMS installation for Joomla
3.5. But if we don't start with it now, we wont do it for 4.0 either,
because from my perspective, it will take longer than 6 months to
implement all and everything necessary for this.

I'm in.

 

Which again would bring up the discussion about our failed development
strategy.

I know it's semantics but it was a success for a season. I just think it doesn't meet our current needs where we are moving away from refactoring the core into a sane foundation and into major feature additions.

 

@Andrew: I don't necessarily want the changes that initiated this thread
to be part of 3.2. This was a proposal so far and I'm not sure this is
primetime ready yet, so it would be nice, but I also wouldn't break out
in tears when it wouldn't be a part. Your idea to use this as a
test-ballon for a core component is very appealing to me.

No, no, I was being sarcastic.

On that note though, we need to fix this new PR for the app store. I think I could live with some sort of "advertising module" in the installer to cater for what Beat wants (but executed poorly). That could be used for a wide variety of things (VEL, important extension announcements, etc) and it then makes sense to have an option to turn it on and off. I'm sure we can find a better solution than hardcoding it.

Regards,

Andrew Eddie 

[Matt Thomas]

+1 Hannes. Once 3.2 is out, it would be good to begin this.

Best,

Matt Thomas
Founder betweenbrain™

Lead Developer Construct Template Development Framework
Phone: 203.632.9322
Twitter: @betweenbrain
Github: https://github.com/betweenbrain

[Beat]

Andrew,

I fully agree that it does not look logical to have the strings for an official plugin in core, at first glance.
And to begin I was against it too.
But then I got convinced by the translators and the translation manager that it makes sense logistically and in the users' interest.

How would you solve following problems (and is what you would put in place for less than 10 short strings worth your time and that of translators ?):

1. Handle the logistics of translating less than a dozen strings into all languages supported by Joomla using the existing translators and existing processes ?
2. Solve the issue of the 1-click installer notification messages translations ?

After quite some thoughts (and given that the new notification component is so new that building upon it a week back was too early), we decided to go the simple route for that, as we opened enough new road without wanting to revolution everything (we took the Airbus vs. Boeing Dreamliner approach: Take a new approach on one aspect at a time).

So let's be pragmatic and refine things one step at a time: Here is what was my checklist for a simple approach:

• Does the information notification do its job from a user perspective ? Yes, fully.
• Is it technically universal ? No.
• Does it need to be technically universal for 3.2 ? No, there is the notification component that will be a good choice for re-factoring that for 3.5
• Is the current plugin (and notification) portable easily to 2.5 ? Yes
• Would a notification using the notification component built on FOF/RAD be portable easily to 2.5 core ? :D Not really.
• Does this feature or any other 3.2 feature at first glance gain from developing a different universal approach than the notification component that was in development ? No
• Can we refactor the info notification for 3.5 using the notification component ? Sure thing! (but for 3.2 beta 1: it was just a few weeks too early!)
  

I'm welcoming the discussions in here for improving the installer (it's long time due task, and if Apps* can contribute to this movement for 3.5, I'm more than happy).

George is right, we had clear goal, directions, instructions and full support from PLT and other Joomla entities, a clear deadline and a good team. So we took a pragmatic, user-benefit-focussed approach to meet the goal and respect directions and instructions.

• Is it a perfect technically ? no
• is it "sloppy" ? certainly no.
• Does it work and fulfill its purpose and constraints given ? certainly yes.
• Is the installer-plugin-type a good idea ? I think so
• Does the Web Installer need to become core ? no, the official Joomla-own extension approach makes full sense here.
  
• Does the team that spent time to implement this deserve the terms used here ? certainly not!

• Do we need to rush-in technical-benefit-only improvements into 3.2 ? No
• From 3.2 onwards can it be improved ? yes, sure, like everything else in Joomla!

Different answers to the above are welcome. Those are just my own personal ones.

I do welcome this discussion and improvement suggestions that make sense to the user. In full respect (and without ironny). I've just not the time at this time to work on technical improvements that don't benefit the user in 3.2. After 3.2 is out, it's certainly a different story. :-)

So let's focus discussions on improvements for 3.5, and focus the doing on getting 3.2 out. ;-)

Best Regards,
Beat
http://www.joomlapolis.com/

[Andrew Eddie]

Yeah I know - it's easier to beg for forgiveness than ask for permission :P As I said, we have a lot of minds that WANT to help - it could have been discussed with a very short time-box and take the best of possibly a bad bunch of options (but probably achieving better than we currently have).

My response to the translators would have been "we need to find a better way".

Regards,
Andrew Eddie

[Beat]

On Thursday, October 10, 2013 9:35:34 AM UTC+2, Andrew Eddie wrote:

Yeah I know - it's easier to beg for forgiveness than ask for permission :P As I said, we have a lot of minds that WANT to help - it could have been discussed with a very short time-box and take the best of possibly a bad bunch of options (but probably achieving better than we currently have).

My response to the translators would have been "we need to find a better way".

There is also a strong possibility that by discussing without a code proposal we would have ended up without a solution at all, which is not better than what we have now (tested, working fine, providing the wanted user benefit, and following requirements). ;-)

Regarding the better way with translators, I'm all for it, go for it (my free time doesn't allow me to do it at this time) ! :-)

[Andrew Eddie]

On 10 October 2013 18:08, Beat <bea...@gmail.com> wrote:

There is also a strong possibility that by discussing without a code proposal we would have ended up without a solution at all, which is not better than what we have now (tested, working fine, providing the wanted user benefit, and following requirements). ;-)

And that's why I said you would give such a thing a very short time frame in which to make a decision (24 or 48 hours would have been appropriate) and then you just go with the best option. I fully realise you don't want a decision like that to go round and round in circles. I would have though my comments translated ok but obviously not.

 

Regarding the better way with translators, I'm all for it, go for it (my free time doesn't allow me to do it at this time) ! :-)

That horse has bolted (again) and I'm putting my energy into the distribution working group for a while.

Regards,

Andrew Eddie

[Vic Drover]

I loved reading this line:

"And to begin I was against it too. But then I got convinced by the translators and the translation manager that it makes sense logistically and in the users' interest."

Bravo Beat. It's great to see that folks can remain flexible. It gets so much harder for me the older I get :)

[Andrew Eddie]

It's actually a bug in the plugin's manifest. Want me to explain why?

Regards,

Andrew Eddie 

[Beat]

On Thursday, October 10, 2013 3:00:07 PM UTC+2, Andrew Eddie wrote:

It's actually a bug in the plugin's manifest. Want me to explain why?

Thanks, Andrew, but not needed, as it's not a bug, but a feature requested by Joomla Translations Team Manager (as explained already in my reply above).

Beat