After clearing Magento's image cache, the site seems unable to rebuild image caches and certain pages are loading with a url extension ?___SID=U. All product images are coming up blank and look to be halting further loading of the site (no footer or sidebar loading on those pages).
It seems to be a permissions issue? Relevant folder (media) is currently recursively set to 777. But I'm still having issues.
Also renamed the htaccess in media to htaccess-old
No luck. Can't upload new images either. And no the server isn't out of storage.
Make sure PHP "GD" graphics module is installed. Magento uses it to create the thumbnails. Type in your shell:
php5 -m | grep gd
This should output a gd all by itself on a single line. If it does not, then you need to install the gd module.
Therefore, to install gd, type the following commands in the shell (tested on Ubuntu 12, but may vary depending on your OS):
sudo apt-get install php5-gd
Next, restart Apache. How to do that may be particular to your installation, so make sure that you know the right way to do it.
Ubuntu 12:
sudo service apache2 graceful
OS X:
sudo apachectl graceful
If you don't need a "graceful" restart (preserves existing connections) then simply use the word "restart" instead of the word "graceful" in the above commands.
There are more comprehensive instructions at this link.
media folder permission 777
deleted htaccess file under the media folder
clear the cache
cache folder is writeable
rebuilt all indexes
try also:
cd /var/www/html/var
rm -rf cache/* full_page_cache/*
Also in addition check if your GD library is installed with jpeg support.
<?php
if (function_exists('imagecreatefromjpeg')) {
echo 'ok';
} else {
echo 'jpeg support not installed';
}
?>
Related
I'm trying to install Magento unto my CentOS that I'm running off Hyper-V and it's driving me crazy. I set everything up as per tutorial, but every time I reach the locale page of the setup it says "AVC denial... attempting to write to /var. I'm pretty new with linux but I tried almost everything, I did what the error told me and set the label of the /var directory and all the directories below it to httpd_sys_content_t and made sure it has write permission. After that didn't work I gave up and decided to reposition the server to a custom folder in /usr directory, I changed all the apache config files so it doesn't mention /var directory at all, but the apache process is still attempting to write to it for some reason. Can anybody help me out with this?
Try
grep "denied" /var/log/audit/audit.log
What's there?
And for your information, Magento want to access file on magento folder var, log or report or cache
Go to your Magento folder and you can change it with
sudo chmod -R 777 var
it will give access to write and change file inside there.
I'm running a MacPro G5 w/ 10.5.8. I ran:
sudo port selfupdate and then ran:
sudo port upgrade outdated
When it was all finished, I rebooted and apache2 was broken and would not serve PHP file any longer. If I replace the httpd.conf file, it will serve html files.
I finally gave up and restored the backup and the machine is running again. The problem is I have a second machine that I did the same thing on and don't want to go through the same process. I've read several posts about uninstalling/reinstalling Macports like this one from Kirk Roybal How to do a clean reinstall with macports?, but it doesn't say if this process will destroy or reset the contents of the /opt/local/ directory. Especially the MySQL DBs and htdocs contents. Does anyone know if this process is linked or destructive? I'll make backups of everything, of course, before trying anything.
SOLUTION:
I got it to work by making the php53 install work instead of going backwards. Here's what I did:
sudo port select --set php php53 (set MacPorts to use php53 instead of php5)
sudo port installed (Check to make sure php53-apache2handler is installed)
sudo port install php53-apache2handler (It wasn't and yours probably isn't either)
once that's done installing
php -v (check the version of PHP that's running)
cd /opt/local/apache2/modules
sudo /opt/local/apache2/bin/apxs -a -e -n php mod_php53.so (activates php within apache)
this should append
LoadModule php5_module modules/mod_php53.so
to your /opt/local/apache2/conf/httpd.conf file (check it now)
There will also be a line like this
LoadModule php5_module modules/mod_php5.so
Comment it out or remove it so is doesn't interfere with new install
It should also move a copy of mod_php53.so to
/opt/local/apache2/modules
If it's not there, see php53-apache2handler install above.
Check your httpd.conf file for errors
/opt/local/apache2/bin/httpd -S
Finally, create/edit php.ini file to tell apache2 how to connect to MySQL database
cd /opt/local/etc/php53
sudo cp php.ini-production php.ini (for production machine use development for dev machine)
sudo cp php.ini php.ini.bak
Add the default socket paths to php.ini
pdo_mysql.default_socket=/opt/local/var/run/mysql5/mysqld.sock (may vary based on MySQL version. Check the /opt/local/var/run directory if not sure)
mysql.default_socket=/opt/local/var/run/mysql5/mysqld.sock
mysqli.default_socket=/opt/local/var/run/mysql5/mysqld.sock
If you are having problems connecting to MySQL, check for typos in the above paths FIRST. Trust me it will save you tons of time!
If all went according to plan, you should be able to restart the machine, test to make sure all ports started automatically and things should be working.
The files that you add (eg: MySQL DBs) are not destroyed by an update. If you modify files that are managed by MacPorts (eg: they are listed in 'port contents '), then those modifications will be clobbered by an update.
Some projects install config files as examples and have the user make the real config file so as to not clobber it with an update. It looks like the apache2 port follows this pattern. It installs /opt/local/apache2/conf/original/httpd.conf and then copies it to the real location of /opt/local/apache2/conf/httpd.conf at activation time only if the file does not exist.
My objective is to have Joomla 3.1 running on an Ubuntu server using nginx.
I am testing the setup locally but I keep encountering problems. I think this is concerned with the permissions in my Joomla source files.
I tried to install a package (T3) manually using the "Install From Directory" option. However, I receive the following message:
Warning JFTP: :store: Bad response
JInstaller: :Install: Failed to copy file
/usr/share/nginx/immigrationinformation.com/components/com_installer/t3-1.4.1/source/plg_system_t3/t3.php
to
/usr/share/nginx/immigrationinformation.com/plugins/system/t3/t3.php
Package Install: There was an error installing an extension:
plg_system_t3
I know that this is the wrong way to set up the server but currently I have all the source files permissions set to 777. When this T3 package tries to install, it creates a folder in plugins/system/ called t3. This has only permissions drwxr-xr-x and thus the reason for the above errors.
My question is: What is the correct method to set up my Joomla 3.1 package such that I can ensure a smooth operation of the site, in a secure manner.
Thanks in advance!
The permissions when t3 installs are correct, it sounds like the problem is with ownership rather than permissions.
I think in ubuntu the system user is www-data so you would need to run the following over ssh
chown -hR www-data:www-data /path/to/joomla/root
Then upload the plugin through the joomla installer (and change folder permissions back to 755 and files to 644).
I'm running Drupal 7.4 on localhost, and I've downloaded some themes/modules but I'm unable to install them. I go to administration/modules, for example, select 'Upload a module or theme archive to install', choose the tar.gz from my file system, and before the install I'm asked for a FTP user and password and can not advance.
I'm working locally, so I'm thinking maybe I made some mistake during the install. How can I correct this? I have to do a lot of testing on local before moving the site to a server.
I found the solution here. All I have to do is place the modules/themes inside drupal_folder/sites/default/modules or themes and that's it.
Thanks #nmc
This can happen when sites/default folder is not owned by the user that executes the install script. Make sure the folder sites/default is owned by the apache user (from your drupal root):
Ubuntu:
chown www-data sites/default
Fedora:
chown apache sites/default
If your not able to install the module, because the lack of a ftp connection, it's possible to use the old fashion way.
The other solution has described it, but it's not correct for a 100%.
If you want to do it the drupal way, you need to install the modules/themes to
drupalfolder/sites/all/modules
or
drupalfolder/sites/all/themes
if you are having a multi-installation of drupal, then:
drupalfolder/sites/domain_name/modules
or
drupalfolder/sites/domain_name/themes
I am trying to copy a CodeIgniter installation using svn to a different, brand new server. I have it checked in (did sudo svn commit -m "Initial commit") on the old box. On the the new one, I ran
sudo yum install httpd
sudo yum install php
sudo yum install mysql
Started all the services, checked out exactly the same codeigniter installation, in the /var/www/html directory, and only the first index page loads and all the links are broken. I made sure that the .htaccess files in the web root are exactly the same. A 'svn status --verbose' command in the system/application/config directory returns exactly the same version numbers on both boxes. What could be the problem?
Just to clarify what happens, the 'home' pages loads (ex: myurl.com) but when I click on a link, like "About" it loads the correct URL 'myurl.com/about' in my browser, but the browser says the page doesn't exist 'Oops! This link appears to be broken.'.
I have checked the 'svn status' of the controllers folder and the views folder, all the same version numbers. Any advice would be a huge help!
UPDATE: I have found a "base_href" Constant defined in system/applications/config.php, I changed it, but it hasn't made any difference.
Thanks
This sounds like a mod_rewrite issue to me - enable mod_rewrite, restart httpd, and see what happens when you click on your link.