I've set up a new server for my magentocommerce.
Unfortunatly when I moved the domain to the new location (tests have been done using another domain) a weird issue started happening: when the login page displays on the frontend, or the backend and I (and customers, of course) do submit the right credentials the page refresh, the cookie gets set but the form is displayed again. It's such a cache being served instead of the right content (catalog).
The only solution actually is delete the cache on the browser and retry.
I've used varnish http accelerator for two days, but since I've had too much issues dealing with it I uninstalled it and cleaned things up (now there's only the apache instance to serve user requests).
I also installed APC caching and Fooman Speedster.
What can it be to cause this issue?
Can you please help me to get in the right direction to fix this issue? On the old server it was not happening, but since that time there have been some modification to the store (nothing to do with authentication anyway).
The apache error log does not report anything, the only thing in there is PHP: syntax error, unexpected BOOL_TRUE in /etc/php5/apache2/conf.d/apc.ini on line 4 which has to do with the line apc.enabled = 1.
Look at the System -> Configuration -> Web tab in the admin panel and see if the Cookie Path and Cookie Domain are set correctly for the new server. You can do it directly in the database as well. In this case, search for rows with web/cookie/cookie_path and web/cookie/cookie_domain paths. Setting them to empty values in the admin panel or NULL in the database may also help.
You should also clear Magento cache (System -> Cache Management) and APC cache (here's how to do it: How to clear APC cache entries?).
I don't know if it solves your specific form problem but we had the same error in the apache error log.
Our failure was, we've copied the apc.ini code from http://magebase.com/magento-tutorials/speeding-up-magento-with-apc-or-memcached/. They use "#" for comments.
Turns out we had to use ";" for comments. After these changes, there were no more errors in the apache error log.
Related
I clicked on the 'Update WordPress' link in the admin dashboard of my WordPress site, and I am getting this error:
"The file 'wp-config.php' already exists. If you need to reset any of the
configuration items in this file, please delete it first. You may try installing now."
When I try to click the "installing now" link, it seems that WordPress is installing fresh. I want to keep all of the content of my WordPress installation.
I have tried to change the name of the wp-config.php file but that didn't do anything.
Is just a browser cache.
On first URL load, you are redirected from domain.ext to domain.ext/wp-admin/setup-config.php
If you are on Chrome, just open the developers console, go to "Network" tab. Reload the page and right click anywhere in the console, and hit "Clear browser cache".
Now refresh again and you will see your website
I ran into this same issue while I was transferring a site. The issue ended up being with the .htaccess file. I fixed it by resetting my permalinks. There may be other causes to this issue but this worked for me:
Click on General => Permalinks
Click Save Changes (to reset permalinks)
Try to display the website first on the incognito tab. If it works correctly, clear the browser cache.
Once the page refresh has been completed, the website will appear.
You can use the following shortcuts to clear the browser cache.
Windows: Ctrl + F5
Mac OS: CMD + Shift + R
This usually happens when you use an old version of Wordpress files or old database, and you use partly new files of Wordpress.
All you need to do is to delete all WP files and install a fresh Wordpress (new files unzipped from a new version of Wordpress) and use an empty database.
If you're planning to migrate or move from another website, you should use the export/import function built in wordpress.
he file wp-config.php already exists. If you need to reset any of the configuration items in this file, please delete it first. You may try installing now.
Answer:- Please Clear Your browser's cache.
Did I miss the party?
Today I have a problem like what you experienced 5 years ago. The solution is: Remove all caching plugins (Cloudflare, Jetpack, Litespeed).
Maybe you could try to delete 'wp-config.php' file, or take a backup of this file in different folder and then try again.
If you are using bluehost and did not do the one click install :
I solved this problem by deleting the default error pages 404.php 500.php etc...
I do not know why exactly this was causing this issue... Sorry for the sloppy answer but tried clearing cache and recreating the .htaccess file it didn't work.
I removed the added spaces that the Wordpress's own web 'easy installer' created in the wp-config.php file to help me out.
Guess the Wordpress's own wp-config.php ?checker? isn't compatible with Wordpress's own installer. Wow.
Once the added spaces were removed, site comes up fine. I simply modeled the spacing that is in the wp-config-sample.php file.
Because you just installed wp.
Just hit ctrl+F5 done!!!
More likely it is cache issue and this error comes when we try to install one Wordpress inside of another sub folder of the cpanel in the same Wordpress installation and it will be mostly resolved when you try to check it in the private window or another browser
For me it was file permission set to 666 changing it to 664 worked.
If someone is still for a solution.
This happened to me on an existing site while trying to update.
the problem was following line in wp-config.php near the end.
/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-admin/setup-config.php');
Removing this fixed the problem.
Hope this helps.
RESOLVED: I had the same problem. post hack situation on other account, shared hosting and server NUKED. Luckily I had the backup files from one of the WP plugins but the main page didnt load, I could only go to 404 and from there to other pages but not main page, the error was wp-config eists...install...blah blah blah.....so I tried everything, multiple re-installs, changed the wp_prefix as per previous install on the fresh install and nothing helped, even ordered paid support from the backup plugin developer as I was sure that it fooked because I had Opencart also installed there but the backup was intended for WP only, my web developer also did something, perhaps removed the OC bits from DB, but thank god i managed to resolve it on my own(and justhost),. so I contacted the justhost for the SECOND TIME and they told me that the account is on VARNISH i.e. some sort of automated cache limit, so I told them to take it off and they wanted to know what have I done to reduce the LOAD to the server, so I told this and that and two seconds later everything loaded perfectly. took me about 20 hours to get main page loading, plus probably it will take 10 hours for fine tuning of the site. anyway if you contact jour host make sure you ask them if they are not blocking cahce as the first time I got in contact they couldnt help me.
I also meet with same error and Mr Pierre R is right its just a cache. Just clear your cache or check in private window. All fine.
if someone have still this error..
goto->admin->setup.php (delete this file error will be solve)
hope this will help.
after updating to magento 1.8.1 it stopped saving the changes of the theme options in the system configuration… i made a backup and created 1 to 1 copy on my local machine… and by editing the theme options.. and saving!! everything is ok !!!
i can’t understand y the problem is only on the server… i mean these r the same files.. the same database… and everything is ok with the permissions… and the php version is by both 5.4… so i have no idea why it should function on my local server and not on the web server !!!
after saving… i still get the message “The configuration has been saved.” the problem is it's not being saved...
it's only about the theme options.. other Configurations can be saved normally...
so i can't understand y.. and i don't know where to look !!!
it’s driving me almost crazy
i made a screen capture to give a hint how it looks like:
http://www.youtube.com/watch?v=pBfIWXxGB64&feature=youtu.be
Nothing happens when you try to save the payment methods page. The problem is caused by the Chrome browser's auto-fill feature. Chrome will auto-fill the PayPal username/email. Click on the PayPal Payment Solutions tab, then click Configure near Express Checkout and remove the auto-filled username/password.
Now you can save the page.
Alternatively, try FireFox, Safari or Internet Explorer.
Taken from this page
This is 100% cache issue.
Clearing cache folder from magento_root/var does not clear all cache created by magento.
You need to clear cache from magento admin:
flush magento cache
and
flush cache storage
If that wont help, try to clear /tmp directory on server.
Also: if it's a theme related configuration issue, maybe after upgrade some file permissions have been changed.
I got this in my PHP log. So for me the solution was to increase the amoutn of input variables to 10000 via .htaccess file
PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini
Greetings.
I am right now in the middle of reinstalling my whole dedicated server. I went with
-Ubuntu Server 10.10
-PHP 5.3.3.1
-php-fpm
-nginx
Now, almost everything seems to work, though there remains one problem with the sessions. No matter what I do, the sessions doesn't seem to store themselves properly (and they did on the previous setup).
The base application is phpBB board. When I login, it's okay - though it appends additional SID parameter to all of the URLs.
forum/index.php?sid=f506ccd42065322f61cb56fc6df6557a
You can navigate around the forums without problem, though if you delete the SID parameter, you get logged out. I thought, that perhaps the sessions aren't stored in cookies, but in URLs, but php configuration seems fine.
The same occurs with phpMyAdmin - I also get logged out, when I delete the token parameter.
In the meantime, it seems the cookies are getting created anyway, it's like they aren't used, or are getting deleted immediately.
I am getting more and more frustrated with that, maybe someone has an idea on how to troubleshoot that? I will post any configuration files necessary.
I thought maybe it's the problem with suhosin (it wasn't installed on the previous setup), but I have no clue. The PHP config is out-of-the box atm, I only modified nginx config.
The various session cookie parameters are all documented here.
In particular, check the "session.use_cookies", "session.use_only_cookies", and "session.trans_sid" settings. If PHP can't succesfully create a cookie, it'll fall back to the trans_sid method (which is what you're seeeing: the session ID being passed around as a query/form variable).
You can trivially check if any cookie-related headers are going out by using Firebug and HTTPFox in Firefox. Both let you view the incoming/outgoing headers for requests.
May be some usefull information can be found in PHP-fpm error log? Set parameters in php.ini
error_reporting = E_ALL & ~E_DEPRECATED
log_errors = On
error_log = ;
some file php can write in or "syslog"
Also try to look in nginx error log.
Does PHP-fpm process-owner has write permissions to sessions dir? See session.save_path on php.ini for session dir
See if your session_path is correct and has the right permissions. That fixed my problem.
Also, be mindful of the user and group of the processes, as this will effect the default permissions that the session files are created with. If set to default, it may create as root, and then not be able to be read the next time the session file is accessed.
Look for Unix user/group of processes in your php-fpm.conf
and set both user and group to php-fpm
Magento isn't displaying anything but a white homepage, in the error_log the error given is:
client denied by server configuration: /var/www/httpdocs/app/etc/local.xml
I can access the admin area fine, does anyone know why this might happen?
The log entry appears to be created by calls magento is making to ensure you have secured your admin properly. Rather than it being an error it is actually something you want to see as it is effectively saying your admin is secure. Clearly this is just noise in your logs.
There is a really elegant solution on how to fix this and speed up your admin page load described here:
http://www.yireo.com/tutorials/magento/magento-administration/1322-client-denied-by-server-configuration-appetclocalxml
Essentially create the file in the location below with the contents shown. Once you have added the file:
app/design/adminhtml/default/default/layout/local.xml
With the contents:
<layout>
<default>
<remove name="notification_security" />
<remove name="notification_survey" />
</default>
</layout>
Remember to flush your caches: System > Cache Management
Okay... few mixed issues on this page, here is my attempt to clear these up...
Client denied by server configuration: /var/www/httpdocs/app/etc/local.xml
Alan: is correct is this unrelated to your issue... Magento as of 1.4 fills your error log with this message, one for each page you access in the Admin area... This is as a result of Magento "testing" your config file to see if it can be seen be the world... Kinda dumb as this is error is showing it is protected...
The solution to which you were looking for when you came accross the page, seems to be to "hack the core": http://www.magentocommerce.com/boards/viewthread/213947/#t306425
APC issue stated as APC not palying nicely with Magento:-
Switching Magentos caching backed from "apc" back to "files"... You must clear your var/cache directory "rm -R var/cache/*" before switching Magento back to use cache method files from APC... otherwise Magento will read old cache and barf... It is also sensible for the same reason to clear APC by restarting Apache prior to switching to use APC...
And Finally... Original question:-
White screen... most likely as a result of a PHP error and your server having display errors turned off... Firstly manually clear cache on command line from within Magento document root "rm -R var/cache/*"... this may solve as broken cache can cause this... if not... check php config that "display_errors" equals 1 or On... To view PHP settings, in Magento document root, on command line $echo "<?php phpinfo() ?>" > phpinfo.php... request phpinfo.php in browser from magento domain and review php settings, change as necessary...
Other: Renaming errors/local.xml.sample to errors/local.xml will result in you being able to see the complete Magento Error Exception...
Hope this helps someone...
The wording on that error
client denied by server configuration: /var/www/httpdocs/app/etc/local.xml
is an Apache error message that's unrelated to your problem. Someone tried to directly access your local.xml file via a web browser but were blocked by the server configuration. This is correct behavior.
Your white screen error is happening for another reason.
Are there other errors in the log?
Configure PHP to log PHP errors separately.
You can access the magento admin, so turn on logging for Magento specific errors
With the above in place, configure your store to only server file to your IP so you can figure out which error in the log(s) (Apache, PHP, or Magento) is related to your direct request.
APC caching apparently doesn't play nicely with Magento, disabling it threw a PHP error that an outdated theme was producing
I have a problem where i am losing the PHP session between 2 pages.
The session_start() is included in a file called session-inc.php into every page requiring a session to be set. This works for all pages on the site except one particular page, member-profile.php. When this page is visited a new session with a different id (same session name) is set and used instead.
A few more details:
Session name is set manually
All pages are on the same server under the same domain name
If i put an additional session_start() above the include('session-inc.php') in the member-profile.php file, the session is carried over correctly
I have tried setting the session_cookie_domain and session.session_name in the .htaccess, this worked for this domain but it stopped the session being passed over to out payment domain
We are running apache 2.2.6 with php 5.2.5
Putting the session_start() above the include('session-inc.php') in the member-profile.php file is the quick and dirty fix for this problem, but i am wondering if anybody know why this would be happening.
Cheers
Will
According to PHP documentation, session_start must be called before any output is sent back to the browser-- could this page have a rogue CR/LF, Unicode byte-order mark or similar that is causing output before you include('session-inc.php')?
While migrating a legacy site from PHP4 to PHP5 I noticed a php.ini configuration setting that causes php to auto-start the session upon every request. It's an alternative to placing session_start() onto every page...
There are multiple ways to enable this setting:
Put the following line into php.ini:
session.auto_start = on
or put this into your apache virtual-site config or .htaccess file:
<IfModule mod_php5.c>
php_flag session.auto_start on
</IfModule>
and it should make $_SESSION changes available across all pages
I have just encountered this problem. Interestingly, browsing via http://127.0.0.1 instead of http://localhost helped me.
I just spent all day diagnosing this issue in my Ionic3 - to - PHP project. TL; DR - make sure your client is actually sending session credentials.
In the interest of helping anyone who makes this mistake, I will share how I found the problem.
I used these tools to diagnose the session on both the client and server:
1) Add a test file with phpinfo() to the server to review PHP session options.
2) Review the PHP code to make sure that no output, intentional or un-intentional occurs before the session_start() line. Check the status bar of Visual Studio Code to make sure the Byte Order Mark (BOM) is absent from the PHP files.
3) Review server PHP logs (in /var/log/nginx/error.log for me). Add error_log() lines to the php file to dump the session_id() or $_SESSION array.
4) Use tcpdump -An 'port 80 or port 443' to view the actual HTTP requests and replies. (That's where I discovered the missing cookies).
For an Ionic3 data provider the correct syntax for the client is:
var obsHttp = this.http.post(url, body,
{ headers: new HttpHeaders({
'Content-Type':'application/x-www-form-urlencoded'
}),withCredentials: true }).timeout(this.timeoutTime);
Notice the withCrentials:true
One needs to call subscribe on the obsHttp() observable to send the request.
Found the issue
There was a byte order mark at the beginning of the main includes file of the second domain. as stated by ken, cant have any output before a session start, it was not setting the session correctly.
SOLUTION:
session.auto_start = on
in file: php.ini
It solved the issue of re-generating session id on page reload (page refresh / change pages).
The issue appeared after the update of CPanel (and included Multi PHP), even the php version remained the same.
The PHP.ini file didn't had that variable at all.
Went in Cpanel -> MultiPHP INI Editor -> Editor Mode (not Basic, in basic you do not have this setting) and added the line. Press Save.
TIPS / WHEN TO USE THIS SOLUTION:
To determine if that is the problem, put a line at the very beginning and at the very end of your index.php file to check the session id. Use function:
session_id();
Navigate through pages / reload the page. If the session_id value changes the problem is not in your code and this solution should solve your problem (the session is lost outside of your code).
I also tried to verify the availability of saving session on the web server (session.save_path) but, even if it was a lead, it was not the case.
I imagine this is a "feature" of Cpanel with MULTIPHP UPDATE that will happen quite often.
I had this problem, and the cause was that PHP was ignoring all cookies after the first 100. (I asked this question to try to find out why, but so far nobody has figured it out). The browser was sending the PHPSESSID*, but since it was the 110th cookie, PHP was ignoring it.
To figure out if this problem is what's affecting you, use your browser's dev tools to look at the cookies that the browser is sending with the request, and compare that list to the $_COOKIE array in PHP. They should be the same. But if the browser is sending a PHPSESSID*, and there's no PHPSESSID* in $_COOKIE, then that would explain why sessions aren't working.
I solved the problem by not having my site use so many cookies, which is good practice anyway.
*PHPSESSID is the default session name. Your site may use a different name.
To solve the session_id change after each request, you change the parameter session.auto_start and session.cookie_httponly into the php configuration file.
to find the used php configuration file
php -i | grep "php.ini"
then you open it, and try to find the parameter session.auto_start . you set
session.auto_start = 1
session.cookie_httponly = 0
finally you restart your httpd/apache service.
Found the issue
In my case it was due to Varnish Settings please check your varnish settings. PHPSESSID you can exclude the cookie from the Varnish Settings.
I'm not an expert, but found a solution after careful investigation of domain name in the cookies info of two webpages opened on Firefox. (Right click on the page, select inspection and the storage). checked domain names and found that one with www.example.com and the other without www (example.com). changed all the page links to same format and the problem solved for my case.
Found the problem was a byte order mark (BOM) being ouputted at the start of the file. Got rid of it and it sorted out the session problem.