Is this a CLEAN install or do you have some extensions

CLEAN install from the Github. I moved the folder somewhere else.
Extensions have been disabled to the core. This is on-going since I
upgraded to 3.4. Last working version is 3.2.7. Sorry Please do not insist
to clear cache as suggested on numerous posts as this is related to the
code itself.

On Fri, Jul 10, 2015 at 12:44 PM, Brian Teeman notifications@github.com
wrote:

Is this a CLEAN install or do you have some extensions

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/7374
http://issues.joomla.org/tracker/joomla-cms/7374.

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

The problem is that if it is the code why cant anyone else replicate this

On 10 July 2015 at 15:57, alexandrucotioras notifications@github.com
wrote:

CLEAN install from the Github. I moved the folder somewhere else.
Extensions have been disabled to the core. This is on-going since I
upgraded to 3.4. Last working version is 3.2.7. Sorry Please do not insist
to clear cache as suggested on numerous posts as this is related to the
code itself.

On Fri, Jul 10, 2015 at 12:44 PM, Brian Teeman notifications@github.com
wrote:

Is this a CLEAN install or do you have some extensions

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/joomla-cms/7374
http://issues.joomla.org/tracker/joomla-cms/7374.

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

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

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

PHP 5.9 ? Really?

Joomla 3.4.4 Dev? Why are we raising issues against non released code?

Although you dont like the answer - this is probably a cache issue after upgrade.

Thanks for your kind understanding. I was expecting to see a decent
response response regarding this issue, but it it seems Joomla support
itself is not aware of this anyway. Suggesting cache is the issue is like
not granting access to a folder in AD and telling the user to log off. You
can close the call (I actually reported this the second time) but I will
never accept that this is the official support...Clearing the cache...This
is what I do for a living
... Go tell that to a grandma developer... Nobody knows squat about fixing
the code after the 3.4 upgrade, and you're telling me to clear the cache.
Great...

PHP 5.9 ? Really?

Joomla 3.4.4 Dev? Why are we raising issues against no released code?

Although you dont like the answer - this is probably a cache issue after
upgrade.

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

I've been experiencing a similar issue.
with both PHP 5.3 and 5.4
with both Joomla 3.4.3 and 3.3.6
Rockettheme Anacron template 1.4 with Gantry 4.1.29
Everything is OK upon installation
installed BreezingForms 1.8.5 Stable (870)
installed Redirect on Login 3.4.0
Everything is OK upon installation
Added 400 users
Everything is OK
Added 250 user groups
Everything is OK
Added AdminTools
Global Configuration is very slow to save with error about jquery.min.js
Also experienced modules and articles will not save without several clicks on the buttons, the screen eventually comes back with the module or article locked (checked out) and the module or article has not changed.
I increased max_input_vars from 1000 to 3000
Improves Global Configuration situation. Did not affect Save, Save and Close or Save and New buttons.

@alexandrucotioras what a pathetic reply. If you want me to look at YOUR SITE and debug it FOR FREE then I will - however official support is NON EXISTENT - Joomla is a free product with community support - there is no such thing as official support - we tell you what all our experience in writing and supporting Joomla tells us - that in 99% of the cases with an error message like this then its a cache issue after upgrade. If grandma developer cannot debug their own code after an upgrade then maybe they should stick to knitting...

@alexandrucotioras If you want me to look at your EXACT site with the problem then complete the FREE form at https://fix.myjoomla.com/now and I will look for FREE in the interests of pinning this issue right down and closing this issue without having to go back and forth like this.

This will NOT be a Joomla core issue - I'm 99.9% sure of this!

PHP 5.9 has not ever been released.

Joomla 3.4.4 has not ever been released

@erimkus If you are using 250 User Groups then saving Joomla Global Configuration will be slow - this is NOT a problem with installing Admin Tools.

Thank you Phil!

If it were as widespread of an issue as you make it sound to be, you'd get a different response. Fact is, it isn't. So there are a lot of potential answers here. Clearing cache is absolutely a valid troubleshooting step when HTML, CSS, or JS changes are made. As for why you still get the error, it could be an extension incompatibility, layout override using now incompatible JavaScript, or dozens of other answers.

Implying there is a code bug on very commonly used actions that nobody can replicate isn't going to win you friends. So everyone calm down and work together to figure out if there is a legitimate core issue or an extension is screwing things up.

Phil - The repo version number gets bumped post release. So if someone says they're having an issue with code that is last release +1, it's fair to assume they cloned the repo or pulled a nightly build.

Thanks Michael. For me just trying to get to a resolution since I'd been moving along at a pretty good pace then all the sudden yesterday I started experiencing problems with the Save buttons. Could this be related to having 250+ user groups somehow?

What might cause the Save buttons to stop working or hang resulting in no changes and a locked out item? I thought this might be something I did, an id10t error, as opposed to a code issue.

I've deleted the "Joomla" cache, expired cache and the browser history. The save button problem for me is occurring in FF, IE and Chrome.

Hey @erimkus, @brianteeman probably has the correct links - but its a well known issue that too many user groups causes slow saving of the configuration due to all the form elements that javascript has to work through before submitting the form. And if the config doesnt save then thats a max_input_vars issue - but all that being said, this is a different issue to the one @alexandrucotioras is reporting in this issue.

Could this be related to having 250+ user groups somehow

yes I guess it is, your PC to slow to handle all these groups
as @PhilETaylor just wrote (while I write this comment ) it is JavaScript performance problem,
when you push Save, javascript do validation that take some time due the field Access Rules with 250 user groups in it, where each group have around 10 fields ... so script must check 2500+ fields

I've followed Brian's suggestion and added the max_input_vars = 3000 to my php.ini.
The Global Config slow save aside.
@alexandrucotioras is describing a problem with Save, Save&Close, Save and New, nothing happens and that is happening to me as well. I just thought I'd mention the Global Config problem I'm having in case its related. It's not, so what might be causing the Save buttons not saving.

this is a different issue to the one @alexandrucotioras is reporting in this issue.

I said that - and I have offered FREE support to look into his javascript errors for FREE so that we can get to the bottom of them and close this issue...

Hi @Fedik - so the 250 groups could cause the slow or no action of the Save buttons on articles and modules too?

@erimkus everywhere where you have Access rules configuration ...
Save button actually work, but need faster PC

Got it. Thanks

as possible quick solution I would suggest do not use Super Admin when you just need to edit the content, and use other user type that do not have access to edit Access Rules

The issue is not with cache. Whenever I click on the save button, if you take a look into the firebug, nothing happens and there are like continuous errors. I tried this a couple of times. I know when something is not working, you can try another browser. Why are you guys suggesting is the cache issue when I have a clear error in index.php line 38? And I cannot find the answer anywhere. I have like 3.2 and 3.2.7 working fine. I can fix my own issue by restoring the backup, but suggesting this is a cache issue and blaming it on the frontend plugins is not feasible. Let me get this straight: let' day you are right. The issue is from my end. The database got somehow corrupted after the 3.4 upgrade. Would you suggest scrapping my content for the sake of using save button. This is not feasible for me, I have always updated my joomla using official updates, why would it suddenly stop working? You can do whatever you want now, if it is down to just closing calls.

I have offered a FREE look into this issue and can then report back what the problem was - if you want to refuse that and just close the issue thats up to you.

A database doesnt "corrupt" the way you think, and certainly not suring an upgrade.

This is a Javascript issue - probably a mootools/jQuery conflict with a third party or template, or a cache issue. Period. It is not a core Joomla Code issue if only 1 person in a million has it and no one else can replicate it. Experience tells us that.

The offer of free assistance is there. That way we can get to the bottom of the issue. or not.

Thanks for the support, but I cannot wait 4 days for someone to reply, and when they do they blame it on the cache. This is a bug related to motools removal

So just interested in blaming Joomla for something that is not Joomla's fault and not really looking for a resolution to your problem - got it.

Your old issue notes you're looking for a JHtml::_('behavior.mootools') call. That hasn't existed since 3.0.0 was released in September 2012. There is no way any extension relying on that call worked in 3.x.

If updating from 3.2 to 3.4 broke the site and it is related to a script being dependent upon MooTools, if that script is part of the core CMS, we can resolve that issue. If the script is a third party extension, we can advise how the extension can ensure MooTools is loaded but we cannot fix third party code. If you're getting this behavior on all pages, that to me immediately flags a plugin (there is no difference between "frontend" and "backend" plugins, they all run on every request based on the triggered events. So if a plugin is doing something to add extra validation scripts to pages and is not ensuring MooTools gets loaded by calling JHtml::_('behavior.framework'), that is a bug in the plugin for failing to load its dependencies.

If you're unwilling to work with those of us who are trying to help, there is no point in this thread going on any longer. But I can assure you, there is not the major catastrophic error in core that you seem to imply there is otherwise 3.4.4 would have been tagged and released already.

If for some reason you still have problem with the toolbar in the back end then you can reinsert JHtml('behavior.mootools'); in the toolbar layout files. But it is easier to update the old component's JavaScript just change the document.id to getElementById and form validation to formvalidator.

no, I think it not mootools ... but who know real case
@alexandrucotioras TypeError: document.formvalidator is undefined say that FormValidator script not available on the page or broken... as you have only this error I think it just not available.
It can happen in next reason:

• one of your extension override/remove it
• you use template with layout overrides, that in some reason incompatible with latest changes
• you use incompatible layout overrides in default template

So, I would suggest: set admin template to default Isis, then compare template folder administrator/templates/isis/html/ with same folder in downloaded Joomla archive, and remove unnecessary files from your folder.

If the problem caused some additional extension, then I think you remember my comment from #7347, I have nothing add here.

If this not help then I think more simple will be make a clear installation, or try ask for addittional support on forum.joomla.org

Hi Fedir,
I'm sorry for yesterday, after all it is down to my side. My issue is with
Db after all. All is working fine until 3.2.7 stable. I have read that
running alter table in SQL should fix the issue. Unfortunately, I don't
have the patience to amend each query manually. So in my case, the old db
(which I've been updating since 2.5 without any issue) is not coping with
the 3.4. Even if you fix it from the database management inside joomla and
everything is green, save would not work. After all the fuss, I can confirm
a new install fixes it, but that means I have to start from scratch, which
is equal to just destroying the whole thing. Luckily I have backups and for
the moment I am cool using 3.2.7. In the future, with enough knowledge, I
will take a deeper look. By the way, please accept my apologies and thank
you for providing the update last night in github, hopefully this would
help other users in the future
On 11 Jul 2015 09:56, "Fedir Zinchuk" notifications@github.com wrote:

no, I think it not mootools ... but who know real case [image: ]
@alexandrucotioras https://github.com/alexandrucotioras TypeError:
document.formvalidator is undefined say that FormValidator script not
available on the page or broken... as you have only this error I think it
just not available.
It can happen in next reason:

• one of your extension override/remove it
• you use template with layout overrides, that in some reason incompatible with latest changes
• you use incompatible layout overrides in default template

So, I would suggest: set admin template to default Isis, then compare
template folder administrator/templates/isis/html/ with same folder in
downloaded Joomla archive, and remove unnecessary files from your folder.

If the problem caused some additional extension, then I think you remember
my comment from #7347 #7347,
I have nothing add here.

If this not help then I think more simple will be make a clear
installation, or try ask for addittional support on forum.joomla.org [image:
]

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

@alexandrucotioras again you are making assumptions (that this is a database/sql thing) that are totally inappropriate to the problem you have and not listening to those that are trying to help you.

Hi team,
Once again apologies for my tone.
You were right with cache, but this is not the browser cache or Cloudflare
in my case.
I tried to recreate the update again, this time on xampp on another server.
Tweaked the settings, updated to latest 3.4 stable, but I wasn't able to
break the save buttons. So I came back to my original setup, looked at the
error code and noticed there was a missing element pointing to pagedpeed
mod. I am using page speed mod with nginx, so I had to delete the folder
inside /var/ngx_pagespeed_cache. This forced the cache to reload and fixed
my issue. Apologies again for not doing enough research and wasting your
time, but I hope my case would help others in the future.
On 11 Jul 2015 14:32, "Phil Taylor" notifications@github.com wrote:

@alexandrucotioras https://github.com/alexandrucotioras again you are
making assumptions (that this is a database/sql thing) that are totally
inappropriate to the problem you have and not listening to those that are
trying to help you.

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

@alexandrucotioras Thanks for coming back to update us that this was indeed a cache issue ;-) hehe

Thanks. As it was a cache issue I'm closing here

opps was already closed

@alexandrucotioras just for curious, you use IE8 browser?

No. IE 11

On Sat, Jul 18, 2015 at 1:26 PM, Fedir Zinchuk notifications@github.com
wrote:

@alexandrucotioras https://github.com/alexandrucotioras just for
curious, you use IE8 browser?

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