No Code Attached Yet
avatar Sulpher
Sulpher
16 May 2020

Additional comments

I am using 3rd party extension and noticed an error in browser console:

This site overrides Array.from() with an implementation that doesn't support iterables, which could cause Google Maps JavaScript API v3 to not work correctly.

It is caused by Joomla Mootools.
Here is the description of similar problem:
https://joomla.stackexchange.com/questions/27891/joomla-site-overrides-array-from-causing-google-maps-javascript-api-v3-to-not

Quote:

I did a quick search and found stuff in media\system\js\mootools-core-uncompressed.js around line 133 in my joomla version.

I hope it is possible to update Mootools script to avoid such error.

Joomla 3.9.18

avatar Sulpher Sulpher - open - 16 May 2020
avatar joomla-cms-bot joomla-cms-bot - change - 16 May 2020
Labels Added: No Code Attached Yet
avatar joomla-cms-bot joomla-cms-bot - labeled - 16 May 2020
avatar mbabker
mbabker - comment - 17 May 2020

I hope it is possible to update Mootools script to avoid such error.

IIRC, MooTools 1.5 had compatibility breaks that makes upgrading the library a bad idea.

avatar dgrammatiko
dgrammatiko - comment - 17 May 2020

I don't know how many times I reported that the com_privacy introduced Mootools in the front end for no reason (that was in 2019 not a decade ago). FIX IT

Also I'm regretting that I never did a PR to introduce a new set of editor button (ext buttons) like 5-6 years ago. That would have eliminated for good Mootools with the only disadvantage that version 3 would had 2 sets of editor buttons (the core would have used the new ones but the old ones -mootools based- would be also available, although I guess all devs would had dropped them). Well we can't turn back time, that's my regret or my mistake...

avatar richard67
richard67 - comment - 17 May 2020

As far as I understand, @dgrammatiko 's proposal of having 2 sets of editor buttons would be a progressive feature enhancement, i.e. bring new feature enhancements without breaking existing ones, and as far as I understood recent motions from Production Department, we allow this now, so the proposal could be implemented in J3.

@HLeithner What do you think about it?

avatar HLeithner
HLeithner - comment - 18 May 2020

@Sulpher if you have a custom template and don't use frontend editing (and com_privacy) mootools shouldn't be loaded. I'm sure you find a plugin in JED that removes mootools from the frontend or replace it's with a newer version. That com_privacy uses mootools in the frond could be maybe overritten by a templates/layout override?

And upgrading mootools in J3 seams to be a b/c break stated by michael. Doesn't mean you can try to do it by your self.

avatar Sulpher
Sulpher - comment - 18 May 2020

@Sulpher if you have a custom template and don't use frontend editing (and com_privacy) mootools shouldn't be loaded. I'm sure you find a plugin in JED that removes mootools from the frontend or replace it's with a newer version. That com_privacy uses mootools in the frond could be maybe overritten by a templates/layout override?

I am using the front-end and com_privacy.
Since Mootools is a core part of Joomla, I guess using 3rd party extension can be considered as a temporary solution only.

Of course, the best way is to rewrite the code to avoid using Mootools as a heavy library, but I guess it is possible in J4 only...

avatar HLeithner
HLeithner - comment - 18 May 2020

In J4 mootools has been removed already.

avatar dgrammatiko
dgrammatiko - comment - 19 May 2020

That com_privacy uses mootools in the frond could be maybe overritten by a templates/layout override?

@HLeithner if only people took my comments seriously: #20051 (comment)

avatar HLeithner
HLeithner - comment - 19 May 2020

Brian asked for help, we missed a chance that can only be fixed in j4... I hope that there is no framework needed in frontend in j4 for any core component but I don't know if some layouts simply pull jquery or what ever. Should be checked before beta.

avatar dgrammatiko
dgrammatiko - comment - 19 May 2020

I hope that there is no framework needed in frontend in j4

That was my plan with the custom elements: https://github.com/joomla-projects/custom-elements But the last time I tried to bring it to production state and asked for some a11y help I was attacked and therefore I dropped the idea. Also my plan was to have every and each form field as a custom element for two very self explanatory reasons:

  • Custom elements are truly dev friendly (controlled with some element attributes instead of messing in some weird js init function)
  • they're the best way (at least that I know) to go out of the hard Bootstrap/Fonta Awesome/Whatever lock-in

It's not that Joomla has to have hard dependencies, it's a decision (not mine). I seriously tried for years to make this project more friendly (even to not devs) but the resistance is very real...

avatar dgrammatiko
dgrammatiko - comment - 19 May 2020

Brian asked for help, we missed a chance that can only be fixed in j4

@HLeithner you're wrong, follow the discussion and you'll find that I even tried to give him some code (although not tested because probably I was working on J4 and couldn't just switch for a stupid echo renderModal().
Also this IS still fixable for J3. Add another layout and make it default for all the new installations. In the release that has this change also mention that people should switch the Layout to the new one (if their site is BS based, or even if it's not, but you can't make that change for them).

avatar HLeithner
HLeithner - comment - 19 May 2020

I hope that there is no framework needed in frontend in j4

That was my plan with the custom elements: https://github.com/joomla-projects/custom-elements But the last time I tried to bring it to production state and asked for some a11y help I was attacked and therefore I dropped the idea. Also my plan was to have every and each form field as a custom element for two very self explanatory reasons:

  • Custom elements are truly dev friendly (controlled with some element attributes instead of messing in some weird js init function)
  • they're the best way (at least that I know) to go out of the hard Bootstrap/Fonta Awesome/Whatever lock-in

It's not that Joomla has to have hard dependencies, it's a decision (not mine). I seriously tried for years to make this project more friendly (even to not devs) but the resistance is very real...

I personally see NO javascript the best option if not absolutely needed. So webcomponents should be avoided if they bring no gain to a field.

But that's my opinion.

avatar dgrammatiko
dgrammatiko - comment - 19 May 2020

I personally see NO javascript the best option

I will agree to some degree, the point is that there is needed functionality that is not yet (or will never be) available in the platform. It's true that you could get far without any JS but it will be impossible for all the provided functionality in a Joomla form (validation, subforms, WYSIWYG editors, etc)...

Add a Comment

Login with GitHub to post a comment