Click CTRL-F5 once to make sure you have latest JS loaded

But this is probably because you have some 3rd party plugin loading its own JS code,

• update your 3rd party plugins (which is usually a must do !! after upgrading Joomla from 2.5 to 3.x) and then retry
• also test in duplicate website where you can disable your 3rd party plugins

I see you have firefox, and if you have some basic programming skills you may try doing "profiling"

• install firebug
• go to console profile
• click to start the profiling (it should say "profiling running")
• then try to save and wait a few seconds
• then click to stop the profiling and look at the stats

question, how much User groups do you have on your site?
if a loot then it can be a reason of your issue ... but as I remember it should be solved in Joomla 3.5 by #8132 ... please test

I did not create any user groups or access levels. I only have two users
and that's all.

Aleksandar Antić
Microsoft Certified Engineer
ANTICFORMA - Web design & development
Kneza Miloša 19/22, Kragujevac
+381 64 138 0054, +381 34 313 688
office@anticforma.com
www.anticforma.com

On Sat, Nov 21, 2015 at 4:36 PM, Fedir Zinchuk notifications@github.com
wrote:

question, how much User groups do you have on your site?
if a loot then it can be a reason of your issue ... but as I remember it
already solved in Joomla 3.5 in #8132
#8132 ... please test

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

I have all up to date version of all plugins. I must mention I tried
disabling every non Joomla component, library, package, module, template
etc.. but with no luck!
I ran profiles as you suggested and this is the output screen.
One thing I just noticed is that when I click to Close the menu item of the
default menu (Main menu) I was editing, the script appeared, then I killed
it, and after that I was redirected to the Bottom menu as on the image I
attached.

Aleksandar Antić
Microsoft Certified Engineer
ANTICFORMA - Web design & development
Kneza Miloša 19/22, Kragujevac
+381 64 138 0054, +381 34 313 688
office@anticforma.com
www.anticforma.com

On Sat, Nov 21, 2015 at 4:29 PM, Georgios Papadakis <
notifications@github.com> wrote:

Click CTRL-F5 once to make sure you have latest JS loaded

But this is probably because you have some 3rd party plugin loading its
own JS code,

• update your 3rd party plugins (which is usually a must do !! after upgrading Joomla from 2.5 to 3.x) and then retry
• also test in duplicate website where you can disable your 3rd party plugins

I see you have firefox, and if you have some basic programming skills you
may try doing "profiling"

• install firebug
• go to console profile
• click to start the profiling (it should say "profiling running")
• then try to save and wait a few seconds
• then click to stop the profiling and look at the stats

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

• this is the profiling of the JS code run on form load
  and is not relevant / nor useful in regards to your issue

• you need to stop form submission, try doing this:
  after the JS code runs for 3-4 seconds and before the form submits (you said it take 15 seconds)

either click on the browser X icon (address bard) to stop browser from continueing
(or ? when asked to continue script execution, say no)

then click on the profile "tab" to also stop profiling
hopefully there will be good info there

Could you please take a look at the .docx file where I pasted all the profiler data I got
profile Word.docx

Ok the JS files are compressed so it is a little difficult to read this
but it looks like it is Joomla JS (form validation) is taking up this execution time,

• validateField(), own time: 11372ms

• your form has more than 2321 fields, maybe it is the S5 that is inserting several form fields or other plugin

this is strange joomla form validation performance issue has been fixed

• try to retest by temporarily disabling the S5 system plugin that inserts the extra parameters and see if this makes a difference

I disabled s5 system plugin called s5 Flex menu but it makes no difference. This is the menu plugin I use with all my websites, it never caused any problems!

Does the S5 Tab appear in the menu item after disabling the system plugin ?

No as you can see on the image!

I talked to the template provider who told me their java scripts do not load in the back end, only in front end.

It's not the JavaScript its the number of fields. Increase the value of php Max input vars

Can you suggest to what value should I increase php Max input vars? In the System Information - PHP Information section I get this message - The built in phpinfo() function has been disabled by your host.
Is there any way I can check this value without contacting my hosting administrator?

Get a new host - only an idiot host would disable that. Who knows what else they have messed up

I got information from my host that max_input_vars is set to 10000.
max_input_vars = 10000.
Do you have any other idea what could be causing this issue?

from where comes all these 2000+ fields? that @ggppdk told, for sure it not from Joomla core.
if you will find it, then you will solve the problem

I have more than 2000 modules (mostly custom_html) on my site. Should I eliminate or temporary disable those? If I disable them all, do you think this could help me to investigate the problem?

I unpublished all modules and nothing changes. Also I tried disabling all non core Joomla modules, plugins, components, libraries, packages, files. Should I start building this website from the beginning? I have been working with Joomla for more than then years and I never had such an issue as this one that cannot be solved! I really don't know what to do any more?

the modules should not affect here ... very strange
no idea for now, sorry

Ok, do a save as on the browser, and save the HTML source in a file, zip it
and provide a download link to it

• i don't think it has any critical data in it, right ?

Thus we can see the real contents of the form

This is the link to zip html file. I went to back end, opened the default menu item and then I clicked Save Page As in the browser. This is the download link - http://dev.olympic.rs/downloads/OlympicTravel-Administration-Menus-Edit-Item.zip

Ok i see that

• S5 FLEX menu is loaded in the page (you said you disabled it ???)
• and it is adding 1 form button per module to open it in modal popup (Joomla modal popup layout ?) thus you have more than 2000+ buttons because of your 2000+ modules

also disabling the modules will not stop S5 from using them for configuration display purposes

i have not looked at it much !!, maybe i ll have time again later

i think the performance issue is a combination of

• S5 FLEX menu
• 2000 modules
• J3.x changes compared to J2.5 (-OR- changes of S5 Flex menu for J3)

Can you please check again, with the S5 Flex Menu disabled. The link is the same! I doubt the S5 Flex Menu plugin causes problems because I have been using it for a long time without problems!

aahh, yes right the buttons are not added by S5

• the 4000 buttons are the close and close and save buttons for the module modal popup in the module assignment TAB

Possible fix is using the HTML5 tag parameter: form="FormName"

<button form="FormName"  ...

the above maybe enough to exclude them from being found and examined/used by Joomla Form validtation code

OK, great since we get so far, can you be more specific about what exactly I have to do in order to fix this?

Since this doesn't seem to be an issue of the core itself, I'm going to close it.
Please do not use this issue as a support thread. Either take it to direct communication or use the forum.

Ok, can you please suggest me what to do with regards to this problem? How did we came to the conclusion this is not a core Joomla issue?

@Bakual, please see the latest comments too about module assignments

it should be examined if the for module assignments are the source of this performance issue
the website has 2000 modules, and the issue seems to related to module assignments TAB

Yes but I unpublished all 2000 modules. To be more precise I only have 17 modules published right now. Default menu item that we examined has only 10 or 15 modules assigned to it!

Can you please open this issue tracker again. As I said I unpublished all the modules. I only have few of them published and the problem still exists!

done @aantic @ggppdk

I trashed all modules and the problem is gone! Finally! Thank you! You can close this issue!

but I just finished the fix for joomla JS validator hahah
please test #7460

@Fedik,

I see that you updated your pull request: "JavaScript validation performance"

and you added CSS class 'novalidate' to the 'close' and 'close and save' buttons of the modal popups used in the module assignment TAB

• these (as said above) they do not need to participate in any validation and seem to be the source of the reported issue they only close the modal window or trigger 'click' on the 'save' button of the module edit form inside the iframe of the modal

your fix should work, but someone with a lot of modules should test too

it easy to test on "Sample Test" installation, in any menu item editing with profiling by Browser Developer Tool,
on my PC before that patch validation take around 140ms
after that patch just around 40ms

it do not required to have 1000 modules for test, but with them the result will be more "bright"

@Fedik you are right that your fix

• does improve performance in terms of module related buttons and other excluded fields, (nice work!)
• and that testing with less modules can show the difference

but i was wondering if that is the -only- place that number modules effects form validation performance,

very probably, it is the only place (considering the total count of fields and that profiling info showing that validateField takes almost all of the time)

Currently we have a bug, when validation runs twice, once is the main validation by validate.js and second is html5fallback.js (even on push Cancel) ... so if the form have a lot of fields it will have huge overload.

First I thought that the buttons cannot affect the validation performance, but I was wrong, html5fallback.js checks for buttons to.
Each module there have 3 button (2 for close, 1 for save), and for 2000 modules it will be 2000*3=6000 additional "inputs" for validation.

I must return to this topic because my issue is back.
At first I had problem with Saving and/or Closing menu items but I eliminated this problem by trashing all the modules - I had around 2000 modules. Now in the final stage of building a website I reached almost 2000 menu items and 400 modules. Whichever module I open in Joomla back end, even Who is Online, and press the button Save and Close or just Close, the onload event starts after 5 seconds - the action of Saving lasts for more than 5 seconds. Save as Copy also takes that long. Sometimes I even get a popup informing me about unresponsive script jquery.min.js:2 and strangely this happens occasionally. This issue must be related to validation process with joomla having a lot of menu items and modules.
Do you have any solution for this? I use the latest 3.4.8 Joomla!

test #7460 (as I already wrote before)
no test - no fix ... easy

Should I copy and paste these lines of code in the appropriate lines of the appropriate joomla files?
Will I loose these changes on the next Joomla update!

I hope you wont mind showing me how to implement these changes although it says - main target is users who have hundreds of User groups and I don't even have user groups created!

check
https://docs.joomla.org/Testing_Joomla!_patches
and
https://docs.joomla.org/Component_Patchtester_for_Testers

but first I need to check and fix the conflict in that pull request

... it says - main target is users who have hundreds of User groups ...

it was half of year ago ... your issue is related, read previous comments

I tried to install the Patchtester Component on my website but received
this warning: JFolder::create: Could not create folder.Path:
administrator/templates/hathor/html/com_patchtester
Is this error caused by missing the Hathor administrator template? Do I
need to install it prior to installing Component Patchtester?
To get back to the issue, as modules and menus grow on my website the Save
and Close takes up to 10 seconds and browser freezes for some time?
I need to fix this as soon as possible. Would you give me a hand here?
Currently I have about 2000 menus and 500 modules!
This issue is related only to Module and Menu Manager, the rest of the CMS
works good! For instance Article Manager Save, Save and Close, Save as Copy
and Close buttons work instantly!
Global Configuration works well, Template Manager is a bit slow also due to
the Menu Assignments.

no idea, you can try to download all these files https://github.com/joomla/joomla-cms/pull/7460/files and replace them manually ... but first, do backup of course

I wasn't able to install the com_patchtester due to the permission error on the folder I specified but I replicated the Joomla installation on another server and successfully installed com_patchtester. Also I was able to Fetch Data but when I filter out by Pull ID 7460 there are not matching results?

I found this specific issue by typing validate in the filter field. So I applied the patch and now I will be testing it!

You need to use the "standard" id:7460 in the patch tester component's search filter (or search by its title); that's patched to work better for next release. As for the Hathor override thing it first checks for existence of the template then tries to copy layout overrides into the template if it's found. If it couldn't create the directory that'd keep the copy from working right.

This actually works and it works great. The Save and Close event starts after less than a second or maybe a bit more. Comparing to 10 seconds it was before it makes me feel great and relieved. Since I tested it on another server what should be my next step? I am confused about this issue related to the Hathor template. I actually have the folder administrator/templates/hathor but I don't see this template in Joomla Template Manager? Why is that? I tried to Discover it but no luck! I believe the permission settings on the folder hathor/html on my server prevents me to install com_patchtester!

I added a catch for the Exception that was getting thrown by the API when it failed creating that directory so in future patch tester packages it would still install but only raise a warning about failing to copy in the layout overrides.

OK, can you please tell me what happens when I uninstall com_patchtester
component, do I loose all the changes applied to CMS? Do I need to have
this component installed in order to get rid off the issue?
What happens with this patch on Joomla update? When this patch gets
included in the most recent version of Joomla?
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
This
email has been sent from a virus-free computer protected by Avast.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Aleksandar Antić
Microsoft Certified Engineer
ANTICFORMA - Web design & development
Kneza Miloša 19/22, Kragujevac
+381 64 138 0054, +381 34 313 688
office@anticforma.com
www.anticforma.com

On Mon, Jan 11, 2016 at 9:21 PM, Michael Babker notifications@github.com
wrote:

I added a catch for the Exception that was getting thrown by the API when
it failed creating that directory so in future patch tester packages it
would still install but only raise a warning about failing to copy in the
layout overrides.

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

When you're finished testing it is highly advised that you revert the file changes. If you uninstall the component before doing so, you're left with whatever changes came from the patch instead of the correct files for the version you're running. If the files you patched are included in the update package, those files will be overwritten with the update package's version as normal.

do I loose all the changes applied to CMS

no, but you will loose them in next Joomla upgrade (as @mbabker already answered ) unless this patch will be accepted,
you can help to accept it, go to https://issues.joomla.org/tracker/joomla-cms/7460 and tell about your test result

OK, I just posted the comment. OK I understand but I need this to work on
my website because I save a lot of time by having this patch applied.
Should I just keep the component and the patch applied until it actually
gets part of Joomla standard installation. How will I know when this
happens? Sorry for so many questions but this is the first time I am using
Joomla Issue Tracker and I am not very familiar with the entire process!
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
This
email has been sent from a virus-free computer protected by Avast.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Aleksandar Antić
Microsoft Certified Engineer
ANTICFORMA - Web design & development
Kneza Miloša 19/22, Kragujevac
+381 64 138 0054, +381 34 313 688
office@anticforma.com
www.anticforma.com

On Mon, Jan 11, 2016 at 10:07 PM, Fedir Zinchuk notifications@github.com
wrote:

do I loose all the changes applied to CMS

no, but you will loose them in next Joomla upgrade (as @mbabker
https://github.com/mbabker already answered [image: ] ) unless
this patch will be accepted,
you can help to accept it, go to
https://issues.joomla.org/tracker/joomla-cms/7460 and tell about your
test result

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

So as long as you don't do a refresh of the GitHub issues in the component and you don't uninstall the patch tester component, you should be fine to keep the patch applied until the next update. The component will only list open pull requests, so if it gets closed for any reason (including merging), it'll disappear off the list view when you refresh the data and inherently you'd be unable to revert it in the patch testing component.

If you want to keep it running, my suggestion would be to revert the patch just before applying the updates for the next release. In the release notes, there's a link to all of the items that were closed during that release period (that page is here). If that patch has been applied to the release, it'll be in that list. Otherwise, after you finish updating you may need to apply the patch again.

However, just so you know, the patch tester does a full replace of the affected files in a patch (it doesn't actually patch them for various reasons; it's designed mainly to be run in a development environment where you're testing stuff against the current git repo, not really for a production release) so the patched file is in the state of wherever the contributor branched the main repo and made their changes. So if the patched file(s) are vastly different from what's expected in the next release (meaning they haven't really kept up-to-date with the repo's changes), it's possible there could be unintended side effects from running that patch.

So long and short, if you're gonna run it on a production site, I'd suggest doing some thorough testing of the site in full (#7460 changes some of the core JavaScript files for example, and I'm not sure how vastly different any of the patched files are compared to 3.4.8 or the 3.5 beta off hand) just to make sure everything still works as intended. If everything's fine, you should be able to leave it be until the next release.

Thanks for the detailed explanation. I must emphasize that this issue seems to be very old - this is still the first result in Google when you look for this issue - http://forum.joomla.org/viewtopic.php?f=624&t=695914 and you can see this Joomla forum post is from 2012. Why can't Joomla developers solve this issue! Joomla has a problem when having a large number of menu items / modules and it is a fact!!! With #7460 the problem is gone as it seems. I will do some more testing!

Also, can I provide you with my Joomla back end login data so you can test this issue, without a need for recreating the exact same environment?

What are my options if, as you say, for some reason this pull request gets
closed/merged and it dissapears from the list and I am unable to revert it?
On Jan 11, 2016 10:47 PM, "Michael Babker" notifications@github.com wrote:

So as long as you don't do a refresh of the GitHub issues in the component
and you don't uninstall the patch tester component, you should be fine to
keep the patch applied until the next update. The component will only list
open pull requests, so if it gets closed for any reason (including
merging), it'll disappear off the list view when you refresh the data and
inherently you'd be unable to revert it in the patch testing component.

If you want to keep it running, my suggestion would be to revert the patch
just before applying the updates for the next release. In the release
notes, there's a link to all of the items that were closed during that
release period (that page is here
https://github.com/joomla/joomla-cms/issues?q=milestone%3A%22Joomla%21+3.5.0%22+is%3Aclosed).
If that patch has been applied to the release, it'll be in that list.
Otherwise, after you finish updating you may need to apply the patch again.

However, just so you know, the patch tester does a full replace of the
affected files in a patch (it doesn't actually patch them for various
reasons; it's designed mainly to be run in a development environment where
you're testing stuff against the current git repo, not really for a
production release) so the patched file is in the state of wherever the
contributor branched the main repo and made their changes. So if the
patched file(s) are vastly different from what's expected in the next
release (meaning they haven't really kept up-to-date with the repo's
changes), it's possible there could be unintended side effects from running
that patch.

So long and short, if you're gonna run it on a production site, I'd
suggest doing some thorough testing of the site in full (#7460
#7460 changes some of the core
JavaScript files for example, and I'm not sure how vastly different any of
the patched files are compared to 3.4.8 or the 3.5 beta off hand) just to
make sure everything still works as intended. If everything's fine, you
should be able to leave it be until the next release.

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

Hi Fedik just to let you know that I have been testing your patch for more than a day and it saved me a lot of time. This patch should be immediately added to standard Joomla code by my opinion. All buttons work as a charm. To be honest I hate when I click the Save and Close button and need to wait 10 seconds. This completely solves this issue!

@aantic thanks! will hope there will be more testers (need at least 2), to get this thing accepted

Would you be willing to accept some custom coding work to make my website
front end load faster. Would you share your email with me so I can send you
all the details? I am hopeless and have nobody to ask anymore.
I exhausted all my resources and I was wandering if you might be able to
help!
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
This
email has been sent from a virus-free computer protected by Avast.
www.avast.com
https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Aleksandar Antić
Microsoft Certified Engineer
ANTICFORMA - Web design & development
Kneza Miloša 19/22, Kragujevac
+381 64 138 0054, +381 34 313 688
office@anticforma.com
www.anticforma.com

On Wed, Jan 13, 2016 at 7:58 PM, Fedir Zinchuk notifications@github.com
wrote:

@aantic https://github.com/aantic thanks! will hope there will be more
testers (need at least 2), to get this thing accepted [image: ]

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