Thread

Hi Buridan,

If you have caching enabled at all. You might want to visit “Tools” > “Data” > “Clear Caching”.  From here you will want to select “All caches” and click “Submit”

It could aslo be that not all javascript files were successfully uploaded to the server. Re-uploading a 2.1.3 version of the “themes/javascript” folder and it’s contents could do the trick.

Please let us know if either of these help you.

Hi Buridan,

If you have caching enabled at all. You might want to visit “Tools” > “Data” > “Clear Caching”.  From here you will want to select “All caches” and click “Submit”

I do this pretty much on a daily basis.

It could aslo be that not all javascript files were successfully uploaded to the server. Re-uploading a 2.1.3 version of the “themes/javascript” folder and it’s contents could do the trick.

I’ve done this several times now. I did it again and no luck.

Nevertheless, I think I’ve identified the problem - not sure. The index.html file (the forbidden access one) that’s included in the uploads folder is the only non-image file in the list and its location among all the other image files is where the sorting error occurs, i.e., everything after it.

K- who broke the file sorter again?  Sorry about that, buridan.  I’ve opened the file sort bug back up and we’ll get it addressed- looks like a JS error.  Is everything else resolved/known bug?

Thanks, Robin.

The EE version number error message is popping up again. I’ve attached a jpeg…

Hi, buridan. Is it still happening?

Hi, buridan. Is it still happening?

The EE version number error message? Yes, just logged in and was greeted with that pleasingly turquoise error message. 😉

Hi buridan

Which Accessories do you have installed at the moment?

Cheers

Greg

My accessories folder (/public_html/system/expressionengine/accessories) has the following:

acc.quick_tips.php
acc.news_and_stats.php
acc.learning.php
acc.expressionengine_info.php

Hi buridan,

Does the system/expressionengine/cache/ee_version/current_version file exist and if so what are the permissions of this file and its parent directory?

Cheers

Greg

the cache directory is at 777 but the “current_version” file was at 666 - changed it to 777. I do check on the file permissions for the cache directory periodically and I’m finding that the 777 permissions that I set recursively for the entire directory and its contents are not always kept and I have to do it all over again. Is there a reason why this is happening?

Okay, just tried an experiment…

I again recursively set all the cache directory and content permissions at 777, i.e., I checked that everything in that directory was at 777. As soon as I clear “All Caches” through - CP Home/Tools/Data/Clear Cached Data - the sql_cache directory changes to 755 and its index.html file changes to 644. The ee_version directory and contents don’t change. Is this normal?

No, that’s not normal. Unless you’re on EngineHosting which uses 755 and 644. Is the /system/expressionengine/cache folder itself set to 777?

Is the /system/expressionengine/cache folder itself set to 777?

Yes

Issue just started on a 2.1.3 system that did not show the error ever before.

No, that’s not normal. Unless you’re on EngineHosting which uses 755 and 644. Is the /system/expressionengine/cache folder itself set to 777?

Sue, Unix systems have a command which adminstrators can use to restrict the possible permission settings, which is probably what is happening to buridan here, separately from any EE issues.

Umask is explained here: 

http://en.wikipedia.org/wiki/Umask

Regards,
Clive

Sue, Unix systems have a command which adminstrators can use to restrict the possible permission settings, which is probably what is happening to buridan here, separately from any EE issues.

1) I did not experience this issue before 2.1.3.
2) Others have reported the same error message after 2.1.3.
3) I did not make any changes whatsoever to my directories prior to updating to 2.1.3.
4) I have no reason or evidence to believe that a systems admin made changes to the system simultaneous with my updating to 2.1.3.

I fully understand the necessity of eliminating possibilities, but what puzzles me is the slavish commitment to begin at square one and go through some sort of generic routine/list when circumstances and simple logic suggest the utter uselessness of doing so. I’ve witnessed this same frustration on other threads - one poster had to keep reminding everyone that the problem did not occur until the update to 2.1.3. In short, given all that has been covered in this thread, it makes no sense to look elsewhere than to EE as the culprit.