I've recently purchased a virtual server in order to use it as a stage development for my site which is based on a forum script (ipb).
Problem is that before the installation and after it, ipb shows me some messages about suhostin limits. For example
'suhosin.post.max_vars' is 1000 and has to be changed to 4096
'suhosin.request.max_vars' is 1000 and has to be changed to 4096
For both occasions, it says that these settings are on my php.ini. After looking up, couldn't find any mention of suhosin there. But I found them at /etc/php5/conf.d/suhosin.ini and I proceed and changed them with the correct values.
Problem is that I keep gettin the error messages and when I load phpinfo, I see that the old values are still there. I restarted apache, I even restarted the server but suhosin still has the old values even if I edit the suhosin.ini file and see my edits are there.
Could anyone explain what I'm doing wrong ? I even added the lines to php.ini but still nothing changed.
Thanks
You need to make a file called "php.ini" in your admin directory (you find this through the root where you have your forums) and put the following in. Change the values as needed.
suhosin.request.max_varname_length = 400
suhosin.get.max_value_length = 2000
suhosin.request.max_vars = 4100
suhosin.post.max_vars = 4100
Related
i have a serious problem in Magento Admin Backend. After login its shows a BLANK Page. i used the same files and database in different server, there it was working fine but when i have transferred files into LIVE then Admin issues came. Please help me over this as i got frustrated from last some dayz. If you need any more dertails then plz ask but i need to resolve this soon. Link: http://studywings.com/index.php/admin/
Magento ver: 1.7
flush your magento root /var/cache folder and /var/session folders, It may have previous server session that may cause problems.
Otherwise disable all third party modules and try again. I think this will help
I had the Same problem,
i have also debug the any errors occured, i tried index.php file
ini_set('display_errors', 1);
error_reporting(E_ALL);
$_SERVER['MAGE_IS_DEVELOPER_MODE'] = true;
pleced above code in index.php file. after that i have tried admin login.
showing the errors are session related, header already send errors.
i have to add the code in root/index.php file in top add the following line.
ob_start();
after that tried the login its worked.
Cheers..!
Is url changes to this after click login button or not?
http://yourdomain.com/index.php/admin/index/index/key/(key value)/
if url changes but not not show the dashboard page then go to
app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
make copy of this file
Find the code for setting session cookie parameters these started on line 77
Comment out the final three lines and be sure to remove the comma after $this->getCookie()->getPath(). You should end up with this:
// set session cookie params
session_set_cookie_params(
$this->getCookie()->getLifetime(),
$this->getCookie()->getPath()
// $this->getCookie()->getDomain(),
// $this->getCookie()->isSecure(),
// $this->getCookie()->getHttponly()
also line 104 comment out :
//call_user_func_array('session_set_cookie_params', $cookieParams);
If there is no change in url after click login then try to uncomment display error and see error_log file of your server
I think this problem is due to file permissions. As you added files from one server to another, permissions might be get changed.. Try to give the permissions to all the files. Check this http://www.mage-shop.com/forum/threads/3-Magento-Admin-Backend-Blank-Page-Error
There are a number of things that can cause it, but it's most common after migrating to a new server, last time it happened to me it was an excessively low php memory_limit setting on the new server - the Admin part of the site uses a lot more resources per user than the frontend.
In general when having this issue:
Flush out your cache by emptying var/cache
Clear out sessions by emptying var/sessions
Check the magento error logs/reports for an error code in var\logs and var/reports
Turn on magento error logs in mysql if logging isn't already on! (look in core_config_data for WHERE path like 'dev/log/active'
Check if your php configuration is displaying errors
Check your apache/php error logs for more clues - memory errors will show up here for example
Try this solution
It sounds like you want to enable Developer mode. Add this to your .htaccess file:
SetEnv MAGE_IS_DEVELOPER_MODE "true"
You may also want to enable display errors in index.php:
ini_set('display_errors', 1);
The best way I have found to debug is with X-Debug in a local environment. You can also use log files to help debug in a production environment, if your unable to run X-Debug in the environment.
I've got a more detailed posting here:
http://www.molotovbliss.com/debugging-tips-and-tricks-with-magento-commerce
Consider also installing XDebug
Hope this helps you!
Just to complete the other answers....
I am upgrading a magento install, and got the same problem, in the end I had another folder inside of var/
magento/var/minifycache
Only worked after clear deleting the files inside of this folder.
I had the same problem after uninstalling an extension. I thought that clearing cache would be enough, and I did without success... later speaking with the technical team, they commented me that it did not work because I hace memcache installed, and needed to be done the cleaning via system - backend (that i coudl not see...)
Ok I got Drupal 7.19, mySQL 5.1.66-cll PHP 5.3.21
Now I searched for he above error and found various answers of various age, however it doesn't address, my problem.
I get the error for any file bigger than 100k
went through php.ini settings.php as well as account settings, which is now 5000k.
and max post and max file are way higher.
The site has only 2 image fields, the original as well as one other. It doesn't matter which one is used in a content, the field settings for the original one were never changed and the themed installation came with images larger than 500k.
While for the time I can live with resizing images before uploading, it nevertheless is a pain in the .... and I really would appreciate any help.
I had a similar problem which i resolved via the php.ini file as well as the apache mod_security user.conf file.
My httpd is apache2, which has mod_security enabled, which also did not allow me to upload over 100k image file in Drupal. Apparently this is a common problem for the web-hosting provider (liquid web) because it took no more than 3 minutes to resolve.
First the php.ini file was altered (on CentOS it is in /usr/local/lib/) with lines:
;upload_tmp_dir = /tmp (yes it has a semi-colon at the start)
and also the line:
session.save_path = "/tmp"
Second file that was altered is the modsec2.user.conf file located on (CentOS) at /usr/local/apache/conf/
(appended at the bottom of the file in the last 2 lines):
SecUploadDir /tmp
SecTmpDir /tmp
Then /etc/init.d/httpd restart (or reload) apache and you should be able to bypass this limit for file uploads by mod_apache if it is enabled. Best of luck and please know that this is my first answer on stack so please be considerate.
just you can request your hosting provider
to added into the sites whitelist.conf file :
<IfModule mod_security2.c>
<LocationMatch .*>
SecRuleRemoveById 340147
</LocationMatch>
</IfModule>
I moved website to new server, domain stay the same, files structure stay the same, but path to public_html has beed changed. Database has been also moved.
I tried to clean cache, but i dont think I made it. This is error i get:
Could not find action file at: /home/account_name/domains/domain.co.uk/public_html/manager/controllers/default/welcome.php
account_name is different now.
I havent access to the old server, so I cant login and clear cache. I tried to do it using php script I found, but it didnt help.
Moving to new server documentation - there is welcome.php error and how to fix it, but since I haven't access to website from old server, I can't do it.
Also I can't login and clear cache in admin panel, because this message in when i wan get access to it.
I also change in db, in modx_workspaces->path from {core_path} to home/account_name/domains/domain.co.uk/publis_html/core, but didn't help.
How can i clear cache or if it's not the case, what should I do to make it work?
Update
I have change location in settings:
config.core.php
connectors/config.core.php
core/config/config.inc.php
manager/config.core.php
In .htaccess I couldn't find path to website, I didn't change anything.
I remove all content from core/cache/, except one file (.gitignore), and if I go to domain.co.uk/manager/ it's blank page, no content at all. And still can't log in.
Clear the cache on the new server manually VIA FTP or from a shell.
Change that modx_workspaces thing back
did you change all your settings in core/config/config.inc.php ?? if not do so, that is where you will set most of your paths & database credentials.
you have a backup? good!
Now upgrade to the same version of modx, that should fix all your path issues. [make sure you are not logged into the manager while trying to upgrade]
When moving the site to the new server rather watch two things:
the right paths into this files
/config.core.php
/core/config/config.inc.php
/connectors/config.core.php
/manager/config.core.php
the folder /core/cache/ is empty. They can be cleaned simply by removing the contents via ftp.
and correct the value in the database back to {core_path}
We have an established Magento store running Magento 1.4.2.0 and recently something happened to make all of the products in the back end disappear. The products still show properly on the front end and as far as I can tell the store is still working correctly.
Categories show in the admin, and you can see that the categories have products assigned to them. Here is what I have tried so far:
Checked the server free space and load - both are quite acceptable (66% disk space used, load of < 0.1 )
Cleared the cache using the Magento admin.
Physically removed the cache folder and recreated it with the same permissions.
Reindexed all tabled using the Magento admin.
Restarted Apache (v2.x)
Restarted MySQL (v5.x)
Checked the Apache error logs and Magento report directory for issues (both are writable and have some content in it but not of consequence)
Checked the HTTP response of the request - there are no failed AJAX calls or non-HTTP 200 statuses (apart from cached responses).
Cleared the browser cache and tried both Chrome and Firefox.
Taken a copy of the DB and all files and I can reproduce this issue. It appears to be database related as when I loaded up a copy of the production database the products disappeared.
Checked the permissions/ownership on the application directory with the following:
chown -R www-data:www-data .
find . -type f -exec chmod 640 {} \;
find . -type d -exec chmod 750 {} \;
Changing the store view does not change what is visible.
Given that I don't know what the scope of the problem is I'm a little hesitant to go so far as restarting the server itself (although will try this tonight during a quiet time) to resolve this problem without getting some input from others. We have full root access to the box so can poke and play.
Here's a screenshot of products in Magento admin:
http://i.stack.imgur.com/wTkwr.png
Note in particular that there are no filter options - these normally appear when you look at a list of products, even if there are none to display.
All ideas welcomed.
Cheers,
- Bob -
Looks like all products are in the database, but you don't see a grid in the admin because of error somewhere in the code. Switch on the developer mode (add in the .htaccess: SetEnv MAGE_IS_DEVELOPER_MODE 1), it will help you to see what happened. Check Magento and server log files - maybe some errors you will find here. Also increase PHP Memory limit.
If you use a CVS, try to rollback. The error you get is 90% caused by code changes.
I'm using Zend Framework for PHP and handling sessions with the Zend_Session module. This is what I have in my Initializer (or bootstrap):
Zend_Session::start();
Zend_Session::rememberMe(864000);
864000 seconds should be good for 10 days, but I'm still being kicked out at about an hour (or maybe a little less). I've tested to see if this statement works at all by setting it to 10 seconds, and indeed I am kicked out at the appropriate time, but when I set it to a very high value, it doesn't work! I went through some of the documentation here:
http://framework.zend.com/manual/en/zend.session.html
Another method I saw was to use the following:
$authSession = new Zend_Session_Namespace('Zend_Auth');
$authSession->setExpirationSeconds(3600);
Now, I have different namespaces. Does this mean I have to set this for all of them if I want to keep them from expiring? I haven't tested this method of setting the expiration, but I really wanted to see what the gurus on here had to say about what the correct way of approaching this problem is. Thanks a lot guys...
Also, does anyone know how I can make it so that the session never expires? I've tried setting the second to 0 and -1, but that throws an error.
I had the same problem and solved it by putting:
resources.session.save_path = APPLICATION_PATH "/../data/session/"
resources.session.gc_maxlifetime = 864000
resources.session.remember_me_seconds = 864000
in the application.ini (as suggested by tawfekov) and
protected function _initSessions() {
$this->bootstrap('session');
}
in the Bootstrap.php (this I typically forgot at first). You have to give the session directory the correct access rights (chmod 777). I described the issue here. Hopefully this will help the next person with the same issue.
Your client's computer clock, date, AND time zone need to be set correctly for session expirations to work. Otherwise the time conversions are off, and likely causing your cookie to expire the minute it hits the their browser.
Try calling remember me before starting the session:
Zend_Session::rememberMe(864000);
Zend_Session::start();
Otherwise I believe it will use the default of remember_me_seconds. See 49.4.4. rememberMe(integer $seconds)
Also, does anyone know how I can make
it so that the session never expires?
I've tried setting the second to 0 and
-1, but that throws an error.
I don't think that is possible. The session is controlled by whether the cookie exists on the users computer. Those cookies can be deleted, even by the users if they clear their cache. I think the best you can do is set it to a very large number. Say 12 months.
I guess you are using ZF 1.8 or above ,
so you can put in the config.ini file
resources.session.save_path = APPLICATION_PATH "/../data/session"
resources.session.remember_me_seconds = 864000
and these setting will automatically loaded
again only in ZF 1.8 or above if not you had to load these config manually
i hope it helps you :)
Are there other PHP applications running on the server?
Assuming you're using the standard, file-based, session handler, PHP will store all sessions in the same place (typically /tmp).
If you have some other script on the server using the default session_gc_maxlifetime settings, it may be eating your session files.
The easiest fix to try is to configure PHP to store session files for this application someplace special -- that way other apps running on the server will never accidently "clean up" session data from this app.
Try creating a directory like /tmp/myAppPhpSessions (or whatever), and adding:
ini_set('session.save_path','/tmp/myAppPhpSessions');
ini_set('session.gc_maxlifetime', 864000);
at the very top of your bootstrap file.
Make sure session.auto_start is off in php.ini