Apart from deleting session files with find using a custom modification time as mentioned by others, you also can:
Save the sessions in your database. Of course this will put load on your database and it's not the fastest way, but you can handle way more sessions that way and you can share sessions between multiple frontend servers. You can change the ...
With file based sessions, they will be auto-pruned by the PHP session clean-up cron – so the files are likely to be deleted within ~7200 seconds of creation. So even on a busy site (30k uniques per day), there usually only around 4,000 session files in ./var/session – which is nothing even for a low-end Linux server.
However, the clean-up actually relies on ...
The following procedure describes the basic needs for moving your magento-shop to another server. There might be additional things to consider (changing domains, DNS, PHP-Configuration, tools & programms on your server) which need to take care of on your own.
1. Backup files in your Magento directory on your old server:
You might empty your var/cache, ...
The Magento requirements check is a decent script to run to confirm your server meets the requirements (you need to change the opening PHP tag to <?php if your server doesn't support short open tags), and if you open it is has a list of PHP extensions needed, which it lists as:
So I'd say you ...
Follow this i think it will help you to solve your issue :-
now add the following to the magento-logrotate.conf file:
execute your configuration now:
logrotate -f /etc/logrotate.d/magento-...
We've used a separate MySQL server in several instances where the shops were facing high traffic. There are a couple of advantages to it
Dedicated database servers can be tweaked to the specific needs of MySQL which are different from a webserver
It's easy to add a second (load balanced) database server to the cluster when needed
When your database goes ...
The reason for this error is that store_id and website_id for admin should be set to 0 (zero). But, when you import database to new server, somehow these values are not set to 0.
Open PhpMyAdmin and run the following query in your database:-
UPDATE `core_store` SET store_id = 0 WHERE code='admin';
UPDATE `core_store_group` SET ...
Please check and verify below steps:
Check if your server is compatible with Magento. Download file from this link Magento Server Compatibility check and follow the instructions given.
Check for the .htaccess in each folder and in root too. Magento has .htaccess in almost all folders. Verify it for media folder in case the problem is with image
Execute the ...
The official system requirements (or rather: recommendations) are:
Increase the PHP memory limit to at least 768MB for normal operation or 2GB for testing.
Source: Recommendations for CentOS and Ubuntu
I would only increase it to a higher value if you encounter problems where the memory limit is hit. Then debug and fix these problems, and set the memory ...
In addition to Sander's answer, I would add that at certain levels of PCI compliance this is a requirement:
Separate Web and Database Servers CHD is stored en mass in the
database, making it a high-value target to an attacker. Separate
database server means that access can be strictly controlled (limited
exposure). Required by Section 1 ...
I've asked a related question some time ago:
What I never found out (I left that job for a new one, and the original problem became someone else's) is if Magento's sessions will honor these settings, or if they implement their session handling using Zend (and presumably some ...
Seems there's no curl installed on your server. Check your phpinfo() for curl.
If not present, you or your provider can enable it in the PHP config:
/etc/php5/apache2/php.ini (or similar)
You don't need to have multiple directories for multiple domains if you are using single magento instance to fulfill your requirements.
Step 1: Point all domains to Magento root directory, i.e. same document root in the webserver (Apache or Nginx) configuration.
Step 2: Configure domain names as base URLs for each website in System Configuration in ...
NFS and nothing else for all our servers. Writes and reads are so very, very limited that there is no reason to use anything else. Varnish caches almost everything so activity over NFS is negligible.
Performance is quick, reliable and secure. No reason at all to use anything else.
In the past we've used deviations based around rsync - but only in odd ...
Usually a cron job is sufficient, but here is a few things to keep in mind:
1) Set the session to last no longer than session.gc_maxlifetime (php -i | grep session.gc_maxlifetime)seconds (this will set up expired sessions to be prepared for garbage collection by the php.ini or .htaccess)
2) You might want to store the sessions in the database see here for ...
Since Why does Magento POST to its own app/etc/local.xml? might not have been clear enough, I'll add this as an answer:
Actually these messages are a good thing, Magento would warn you in the admin panel if it could access the file via HTTP. If you see this log message, everything is fine. Magento tries to access app/etc/local.xml via HTTP, which fails, so ...
There is a security risk to this. First start with...
Yes, this is possible
As your question does not specify anything, I'll list some things that are necessary to achieve this:
You'll need two document roots, two directories on the server, one to store the M1 code and one to store M2 code. I think it would even be possible for one of the applications to ...
In terms of the web server the file system is largely irrelevant. When it comes to source code you should be using an opcode cache (the open source Zend one now available in 5.5 is a great option). This should cause PHP to not touch the file system at all once the cache is warm. And even so, the disk block cache in the Linux kernel renders most read ...
Firstly, don't blindly read any guide (whether provided by Magento or not) and try to ascertain server configuration and server specification for your own deployment.
Their tests and results are entirely specific to their test conditions and not applicable to your own store.
Every Magento store is different
Beyond that, selecting hardware for your deployment ...
1) You need to get the sql dump from the old database and import the sql file in the new database.
2) You need to make change in the local.xml. To do so goto app/etc/local.xml
Enter the username, password and dbname of the new database you created.
NOTE : Normally host name as localhost works. But for some servers you need to get the host name from the ...
In .htaccess on your server config file.
RewriteRule "^(.*/)?\.git/" - [F,L]
RedirectMatch 404 /\.git
Place this both method in .htaccess file.
It hides any file or directory whose name begins with .git Like .git directory or .gitignore file by returning a 404.
You've clearly got an error in your .htaccess file.
If you check your Apache error log, you should see a pointer as to where the error is exactly.
[Wed Mar 20 12:15:49 2013] [alert] [client 18.104.22.168] /home/chocoloo/public_html/.htaccess: Invalid command 'faulty_line', perhaps misspelled or defined by a module not included in the server configuration
On all of our setups we have a maintenance.php file which takes care of the cleaning of the logs and var directory once in a while. Since the sessions have to be either saved in the database or on the file system, this maintenance file will clean them up both. (See code below).
You can run the following command as a cron job to clean up the logs:
For Magento CMS and the like (that aren't cleaning old sessions up), I just use cron jobs based on php.ini settings.
The system cron.d setup for php5 does not clean Magento ./var/session (or anything besides default session folder (/var/lib/php5 for Ubuntu and /var/lib/php5/sessions or /tmp/ for most others Linux dists).
But you ...
To install Magento enable "Skip Base URL Validation Before the Next Step" in the installation and your install should proceed without ...
moving files and database
I assume these two steps are obvious:
copy all of your local files to production server
dump your magento local db and import it into your production server db
editing in production server
now on your production server you need to follow these two steps:
edit app/etc/local.xml file and change database info
in production db,in ...
if you want to boost your magento2 performance it's mainly about caching.
First, be sure you are in production mode for performance tests
Next step would be to use a cahe storage server instead of file caching. For xample a redis server