Hello,
can you complete your description
Joomla version?
Kunena version?
lg
tobs

J3.4 nightly build
K3.0.6 / K3.0.7-dev

https://groups.google.com/d/msg/joomla-dev-cms/Mm3NATrx1vA/AQfVhgUlEooJ


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5239.

confirmed!

It is true that Kunena install calls JHtml::_('behavior.framework', true);, but I actually I don't see MooTools loaded in the offending page:

...
  <script src="/media/jui/js/jquery.min.js" type="text/javascript"></script>
  <script src="/media/jui/js/jquery-noconflict.js" type="text/javascript"></script>
  <script src="/media/jui/js/jquery-migrate.min.js" type="text/javascript"></script>
  <script src="/media/system/js/tabs-state.js" type="text/javascript"></script>
  <script src="/media/system/js/core.js" type="text/javascript"></script>
  <script src="/media/jui/js/bootstrap.min.js" type="text/javascript"></script>
  <script src="templates/isis/js/template.js?4977d4340a5a1e1cabcaea9be8abd8c9" type="text/javascript"></script>
...

@dgt41 ehmmm... can you give a look at this?

<script src="/media/system/js/core.js" type="text/javascript"></script>
he is loading mootools but not mootools-more

That isn't even MooTools, that's core Joomla JavaScript. You should
have media/system/js/mootools*.js files being loaded.

On Friday, November 28, 2014, Jelle Kok notifications@github.com wrote:

he is loading mootools but not mootools-more

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

Nope mootools*.js files aren't loaded in the page

One very quick solution is to add

echo "<script>document.write('<script src=\"//ajax.googleapis.com/ajax/libs/mootools/1.5.1/mootools-yui-compressed.js\"><\/script>')</script>”;

after the line 58 on install.php

public function preflight($type, $parent) {
echo "<script>document.write('<script src=\"//ajax.googleapis.com/ajax/libs/mootools/1.5.1/mootools-yui-compressed.js\"><\/script>')</script>”;
.
.
.

for me it more kunena bug,
Call JHtml::_('behavior.framework', true); in com_kunena/admin/install/tmpl/default.php useless, because they load this layout using format=raw (there a good reason for this) and as result of course there no any script loaded.

In their case JHtml::_('behavior.framework', true); must be called early, before they display popup... somwhere there https://github.com/Kunena/Kunena-Forum/blob/master/install.php#L78 (if I right understand)

I have tried Fedik but this doesn't help, mootools it still does't loaded, there are too some script put inline in raw called

Without having tried, I think @dgt41 solution would be safer as it will work even if and when we get totally rid of MooTools...

This isn't the right solution, the package must also install on local without internet connection.

The problem is loading mootools by JHtml::_('behavior.framework', true);

Yes, you're right.
... but IMHO you can't count on Joomla having done that on your behalf.
If there is no way for you to call JHtml::_('behavior.framework', true); you should' probably load the local copy of MooTools "the hard way"...

Try my solution, and if you add an if version >=3.4 you are totally comp with 2.5 and all 3.x

@dgt41 the (right) objection is "what if I do this on a plane/sailing boat/mountain hut, without internet connection"?

yes with echo "<script src='//ajax.googleapis.com/ajax/libs/mootools/1.5.1/mootools-yui-compressed.js' language='JavaScript'></script>"; Its working, but you need internet connection to load the js

just load the local copy or provide your own (like people used to do with jQuery at 2.5 times...)

Change the src="/media/system/mootools.js"

At which time mootools will be removed from J! package ?

If a developer could rely on Joomla loading mootools before then its a B/C break which we dont allow in the 3.x series if that is no longer true

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5239.

At which time mootools will be removed from J! package ?
Not before 4.x I guess
But as I said nobody can count on MooTools having been already loaded: I don't see this as a breach of B/C...

Mootools will not be removed before v4.0 but the main idea is to reduce the usage

same goes with jQuery: it is extremely likely it has already been loaded, but you must load it yourself to be sure...

@xillibit it was just my guess ... thing is, that JHtml::_('behavior.framework', true); must be called on the page that render the popup but not in the popup layout (as it currently).

@brianteeman then we need load mootools on each page, because some developer could expect it ... extension must call load mootools or load jquery on page where it need, it not Joomla! job.
I still think that in current case it Kunena bug, before it was hidden, because they call JHtml::_('behavior.framework', true); in wrong place and thought it works, but on real was loaded mootools that Joomla! used for own needs.

@Fedik but if we move the JHtml::_('behavior.framework', true); to the same line on install. its still not loading.

I have created a pr for kunena, to load it manually.

I think the fact is that there are contexts (like this) where a call to JHtml::_('behavior.framework', true); has no effect. So either we say that JHtml::_('behavior.framework', true); is broken and we fix it (but I don't see that feasible in contexts like this), or we just accept this as a fact of life and... fix the code that (wrongly) relied on it.

After all the original Kunena coder was perfectly aware of his duty to load MooTools: the only problem was that his code was not effective, but this was masked by the fact that we already did loaded MooTools (something I think we never committed to do...)

@810 you right, this part is strange

I think I'm getting somewhere with figuring this out.

Kunena's postinstall script looks to enqueue a script snippet into the message queue to load their installer after com_installer completes its installation task. The reason the Mootools load fails is because they are loading it while the com_installer install task is still executing, but there is a redirect at the end of the task back to the display task, and redirects clear all media load requests.

While working toward 3.4, a PR was made which removed uses of Mootools on this view, which caused Mootools to stop being loaded by the view. There isn't anything else in this request that depends on Mootools on a new install, so the end result is:

1) Mootools is not loaded at all at administrator/index.php?option=com_installer&view=install
2) Anything which was using Mootools (such as Kunena's installer) no longer functions because it cannot load Mootools itself without a plugin (which, looking at their installer, they could do with their system plugin and a session variable).

So now the argument is whether this is a B/C break or not. If you are on the side leaning toward yes, that would mean that we CANNOT remove any calls to JHtml::_('behavior.framework') and that core would essentially be mandated to always load Mootools until 4.0 (at least in the admin application). I can't say I have an argument at the moment for this not being a B/C break other than the core view is behaving as it should and only loads its own dependencies, of which Mootools is not one.

I would say if I need something to let my extension work I should make sure that it is available. So for me it isn't a B/C break.

In case we decide it is a B/C, here is a PR that is fixing it for good... #5249

#5249 has been the shortest lived PR ever!

... so... what do we do? Kunena is fixing things on their side, but do we want to fix them ourselves too?

I am afraid that Kunena is not alone depending on mootools (at least in installer)
Until we advertise loudly (using JED) that mootools is getting out of core at a said date/release, I guess we are stuck with it.

It's not a B/C break. If you need something that requires mootools you should load mootools explicitly. If you need something that requires jQuery you should load it explicitly. If you need something that requires bootstrap you should load it explicitly....

Except for in this circumstance, they can load it all they want but it won't load for reasons I explained above. Kunena would have to use their system plugin to load it in this case.

I agree Roberto (I think I've been the most vociferous along this line), but in cases like this JHtml::_('behavior.framework', true); doesn't do any good and MooTools must be loaded inline if it is not already loaded...

Maybe a mid term solution is to put back behavior.framework in installer but advertise loud and clear that this will be removed at 3.5 (or whenever decided).
IMHO there is a way that devs can cope with it, it is almost advertised in my comments above, so even removing shouldn’t be the end of the world… (i guess)

IMO all the inline solution does is suggest that the core API is unusable and a lot of folks would use this issue to start yet another FUD campaign about that. I think we're about due our holiday "Joomla is dying" thread just based on past year experiences, let's not give those folks fuel for the fire

I don't think Joomla is in the wrong by not loading Mootools in the view; the view isn't dependent upon it. Likewise, Kunena has done nothing wrong in their code. However, Kunena's code no longer works because Joomla stopped loading a JavaScript library in a view. There's no "right" answer here, the answer here should be what is going to be best for the majority of users.

I see few options here:
1. Restore the behavior.framework in the toolbar buttons where was removed with #4888 (this ain’t gonna move us forward)
2. Make a behavior.framework call in installer (the impact is low as installer isn’t the app you load every other day)
3. Say your code your problem, fix it. (and expect the rage of furious devs cursing the joomla etc. we’ve seen this before)

IMHO 2 is the best mid term solution, we move forward but we also curry some old baggages (at least for few more months…)

I don't want to defend my now defunct #5249 at all (far from that!), but couldn't there be other situations (beside the installer) where 3rd party devs are relying on MooTools (and yes, I agree they should load it themselves, but maybe reality is different from theory)? And if loading it always doesn't do any harm (which I agree must be demonstrated), wouldn't forcing the loading of it just for this 3.4 release be an acceptable interim solution? Then we'll have the time to advertise that devs must test their extension without counting on ourselves having done the dirty work. Actually the forced loading can be subject to a template parameter so devs can easily test what's happening with their code when we do not load MooTools for them...

@smanzi Sergio, exactly this is my first option. If we revert the behavior.framework on those few toolbar buttons, functionality is same as 3.3, but we also get the option to override layout in isis and be mootools free. This is also an acceptable option, but I tend to believe no.2 is the best approach here

@dgt41 If this is the only place where we removed MooTools, I think this is perfectly OK!

Or... if there is a way for us to create a system plugin injecting MooTools and that is active only in that context, it maybe can be even better, so devs can more easily test future compatibility...

com_installer is a funny beast. It is one of the few places possible in
Joomla to inject something and not have your expected media load. The
extension install scripts and displaying the install results are two
separate requests, so you could follow every best practice known in Joomla
and still get burned by something like this. In fact, I cannot think of
anywhere else in a core install where this edge case is possible.

If we follow our B/C policy literally, the only option here is to ensure
MooTools always loads in com_installer (specifically the install view)
until 4.0 when it is allowed to break B/C. There is no need to revert any
other change; all those changes did is expose an issue.

On Saturday, November 29, 2014, Sergio Manzi (smz) notifications@github.com
wrote:

I don't want to defend my now defunct #5249
#5249 at all (far from that!),
but couldn't there be other situations (beside the installer) where 3rd
party devs are relying on MooTools (and yes, I agree they should load
it themselves, but maybe reality is different from theory)? And if
loading it always doesn't do any harm (which I agree must be demonstrated),
wouldn't forcing the loading of it just for this 3.4 release be an
acceptable interim solution? Then we'll have the time to advertise that
devs must test their extension without counting on ourselves having
done the dirty work. Actually the forced loading can be subject to a
template parameter so devs can easily test what's happening with their code
when we do not load MooTools for them...

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

@smanzi Your idea for a plugin was turned down when discussed in the google CMS group

I'd like to test it but I agree with @mbabker that we should only commit to load it in the installer if that dependency cannot be done by 3rd part plugins.

Loading mootools always (@smanzi's #5249 ) would break extensions that are actually avoiding to load parts of the core that use mootools. So it would cause B/C issues with other extensions. A system plugin is not an option because you'll need to enable it and extensions expect it to be loaded just including the mootools call. That will generate a lot of issues for the extensions support teams.

So if there is a concrete case where mootools cannot be loaded by extensions let's fix that and keep the main plan/roadmap of migrating to jQuery.

@phproberto +1000

@phproberto

So if there is a concrete case where mootools cannot be loaded by extensions let's fix that and keep the main plan/roadmap of migrating to jQuery.

This is a strong standing, but I agree 100%

@phproberto Unrelated (at least partially):

A system plugin is not an option because you'll need to enable it

Isn't there a way to have a system plugin installed and activated by default?

Only using an install script - chicken and egg

On 29 November 2014 at 19:15, Sergio Manzi (smz) notifications@github.com
wrote:

@phproberto https://github.com/phproberto Unrelated (at least
partially):

A system plugin is not an option because you'll need to enable it

Isn't there a way to have a system plugin installed and activated by
default?

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

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Isn't there a way to have a system plugin installed and enabled by default?

All plugins can be disabled by users. There's no guarantee to developers if we put the Mootools load in a plugin that it will be there.

@brianteeman

I moved forward and created #5251 as I realize this is the winning option…
Xmas is around the corner, so lets make everybody happy

Maybe I misinterpreted @phproberto's words: I thought the meaning was "if an extension has problem with this, let 'em fix it!", but @dgt41 paatch does indeed works and allows the installation of the current Kunena code without problems. And... yes, it is Xmas time: let's everybody be happy!

Fixed in #5251

Thanks everybody for scaring me on saturday

See my comment in here: #5251 (comment)

We are using a hack to load our installed via enqueued message, which means that the conventional methods to load JS doesn't work.

Anyway, I'm going to look if I can fix this inside Kunena, in the mean time THANK YOU for keeping the backwards compatibility!