No problem with the upgrade from 1.0.0 to 1.0.1, but I notice that the File Inspector is now reporting a Core file failed: e107_plugins/list_new/section/list_comment.php
Only one of my sites uses the "list new" plugin, and it seems to be working ok.
No problem with the upgrade from 1.0.0 to 1.0.1, but I notice that the File Inspector is now reporting a Core file failed: e107_plugins/list_new/section/list_comment.php
Only one of my sites uses the "list new" plugin, and it seems to be working ok.
I have the same issue on 4 of my sites, it makes little difference to me as I do not use this plugin. Other than that keep up the good work
Having real problems getting back into my sites (test ones). Copied the 1.0.1 upgrade files over the 1.0.0 ones and now cannot login to 2 different sites. Only message is ' access denied'
I cannot see any specific problems. I have cleared cookies and browsing history and also tried a different browser - no difference. Anyone give me any pointers please (I'm glad I didn't put this straight to my live site)
@Chris, the issue is being discussed here: [-link-]
Please use the e107 debug addon (see wiki/google) to find PHP errors and warnings. Find similar errors related to the server session such as these ( [-link-] ).
Looks like the error is related to the use of IP addresses rather than dns name. My test box is a qnap nas device with apache/mysql built in. I was accessing it using ip address. I copied the old class2.php file back to the site and can now access the systems again. Will test again having set a dns entry and let you know.
Can now confirm that the new class2.php works ok when the dns entry is used. I have no problem with admin and non-admin access now. FYI php 5.2.14 mysql 5.1.36 apache is qnap version (TS 210, current firmware)
Thanks for the extensive info. So just to get this all understandable for all; accessing the website through ip address directly causes this issue; when using a dns routing like a domain name everything is fine?
@Moc: the "list new" plugin is working ok; it just failed the file inspector verification. On that site (and two others) I uploaded the .tar.gz file, and extracted it on-site, so I don't think it's a failed upload. Everything else extracted ok.
@Brad R: Well a reupload in binary mode fixed it for BRAW, so I would assume it would do the same for you. The core image is fine cause on all of my installation it passes, and we have had no other reports of this. I understand its working OK, but it would be best if it passed the file inspector as well to avoid any future issues or complications
Moc Everything works OK when using full dns names. If I use ip address, I cannot login at all. In case it makes a difference, my test sites are 1 level below the main website level eg 192.168.1.1/e107 rather than just 192.168.1.1
I'm trying to setup a new install. I get access denied when attempting to login. I am forced to use the IP address to keep the current site live while I setup e107 on the new host and get approval. Is there a work around for this issue on 1.0.1 or should I back down to 1.0.0 until this issue is resolved?
@Chris, thanks, I'll make sure the information gets passed along.
@E Hall: I would suggest downgrading to 1.0.0 in this particular case as the 1.0.1 version consists of mainly minor bugfixes and some small feature additions and does not contain any security risks. I'll bring this issue to the devs and hopefully it will be debugged and fixed soon.
Hi guys, I'm trying to do a test upgrade from 0.7.25 to 1.0.1 but I've run into an issue.
Firstly, I'll explain my procedure....
I exported/backed up my database and my live site and then basically created a copy of the site/database on another domain on the same server, only difference being that it's in a sub folder which I corrected in admin/settings/preferences. Tested that the copy site was functioning as it should then downloaded e107_v0.7.x_to_1.0.1_upgrade, extracted, configured and ftp'd to my test site.
Now, when I try to log into my admin I get to the login page, enter my user/pass, then get a "COOKIE SUPPORT IS REQUIRED" message when it tries to load the eCapcha page.
I've cleared the cache and cookies from my browser, cleared /e107_files/cache/ (except for user_extended.xml file), I've tried different browsers, even did a clean install of Safari, still no joy.
I've Googled and searched these forums and read every upgrade/install document in the wiki but haven't found anything mentioning this specific issue.
I'm sure it's something simple (if you know where to look) but I've run out of ideas.
Thought I turned all plugins off before the upgrade but obviously missed eCaptcha.
Turned this off via phpMyadmin and can now login. Ran through the database checks etc and all comes up rosey but now when I click on plugins/eCaptcha (or any other plugin) to turn it back on I get an "Internal Server Error" "The server encountered an internal error or misconfiguration and was unable to complete your request."
Have un-installed/re-installed and re-uploaded all plugins but still no go.
Server Error Log shows.. "/home/xxxxx/public_html/e107/e107_plugins/backup/.htaccess: Invalid command 'php_value', perhaps misspelled or defined by a module not included in the server configuration"
and it's the same error regardless of which plugin I click on.
The error is related to server configuration. Your htaccess file probably contains overrides for certain php settings, this is not allowed by your host/server configuration. Please contact your host to sort that out. Its not e107 related. Delete your .htaccess file or remove the php overrides and you should be good
I had checked the .htaccess and that wasn't the cause. Turned out to be a simple CHMod/permissions error. Dang plugins folder was 777 for some reason, changed back to 755 and can now admin plugins correctly.
Now, when I turn eCaptcha back on, I still have the "Cookies Required" issue, [sigh] I only use it for Admin login so for now I think it can just stay off.
TBH, it's a low volumn site and I'm not sure it's worth wasting more time on the upgrade right now.
A permission error would be noted in the apache error log as
SoftException in Application.cpp:601: Directory ..... is writeable by group
The error line you posted above clearly suggests a PHP override (in your htaccess file) that is not allowed by your host or server configuration (for example when running suPHP)
Try changing the cookie name in the admin preferences, see if that solves it More references [-link-]