Product images not showing after migration of magento website - image

I recently migrated my magento website to a different server, and here's the process I used:
made a dump of the database.
copied all the system files from the FTP to my hard drive.
emptied the VAR folder
emptied the media cache folders
replaced the strings in the SQL dump from http://www.oldsite.com to http://www.newsite.com
restored the database on the new server
modified the local.xml file to suit the new database host, login and password.
uploaded the system files to the new server
Everything seems to work fine, except for the fact that the product images are not being displayed on the frontend for some reason.
For example, here's a path from an image that was supposed to be showing, which I got through firebug:
http://www.newsite.com/media/catalog/product/cache/1/small_image/113x113/9df78eab33525d08d6e5fb8d27136e95/1/_/1_9.jpg
When I search for the path of the image the site is supposed to show in the FTP, the file is actually there. I can download it and display it on my computer. I don't know why this is happening. It doesn't make any sense to me.
This /media/catalog/product/cache/ was generated by the system, because I erased it myself before uploading the site, so I guess it isn't a cache related issue.
Well, I described the issue the best I could. I hope you can help me out.
EDIT:
Hmm, it turns out the problem was the .htaccess file inside the media folder! Removed the file -> Problem solved!

Just in case anyone else has the same problem, removing the .htaccess in the media folder did the trick. I don't know if that's the best possible solution though! Thanks!

Change Options All -Indexes to Options -Indexes in the above mentioned .htaccess file.

copied all the system files from the FTP to my hard drive.
This one makes me a bit suspecting. Magento has case-sensitive folders in the media folder. There would be, for instance, an 'a' folder and an 'A' folder in the same location.
If you downloaded your files unarchived (file by file) via FTP to a Windows machine, this would cause a conflict and would omit up to half your images.

Ok, since everything checked out with the base URL, my next suggestion is a migration path option if you have cPanel on the old server, and since most do, this should help:
Create a full backup of the account using cPanel. This will create a tar.gz of the entire account.
Download the tarred backup to your computer and unzip.
Find home_dir.tar - this is what contains your HTML root information. You can either upload this directly to the server and untar there using SSH, or do it on your local computer and upload.
Find the SQL folder in the untarred backup. There should be a dump of your database there. Use source to put that information into a new database.
On the server, delete use_cache.ser and change config information for the new database.
Your .htaccess should have come over in the home_dir.tar, but make sure that it's correct per our other question
Once that's done, you should be fully functional, unless you need to make changes in the database base_url for the new server.

Images not showing in Magento 1.7 to 1.9 upgrade:
My solution:
in /media/.htaccess
fixed options syntax:
# Options ExecCGI Includes IncludesNOEXEC SymLinksIfOwnerMatch -Indexes
Options +ExecCGI +Includes +IncludesNOEXEC +SymLinksIfOwnerMatch -Indexes
removed these. Maybe conflict with .htaccess in site root directory??
# For security reasons, Option followsymlinks cannot be overridden.
# Options +FollowSymLinks
# Options +SymLinksIfOwnerMatch
# RewriteEngie on
also changed ownership of .htaccess to apache
chown apache:apache /var/www/mystore/media/.htaccess
Would like opinion of why these may be causing 500 errors.

php bin/magento catalog:images:resize
This helped me, but it take's a lot of time to complete

for magento 2.4.5
in pub//media/.htaccess
change „FollowSymLinks“ to „SymLinksIfOwnerMatch“. example:
############################################
enable rewrites
Options +SymLinksIfOwnerMatch
RewriteEngine on
## you can put here your pub/media folder path relative to web root
#RewriteBase /magento/pub/media/
############################################

Related

Laravel 9 How to hide listing the storage directory

So My issue is as follows. My users can upload files and profile images into the app, Right clicking a profile image and opening in a new tab shows the image (which I want)
https:/my-app.com/storage/profile-photos/sad65f87as5f.png
If I remove the filename part of the url then I get forbidden which I also want
https:/my-app.com/storage/profile-photos
If I then however remove profile-photos from the url it lists all the folders in my storage directory. How do i make this forbidden?
https:/my-app.com/storage
In addition I have an uploads folder in the storage directory and this and all its contents are publicly available.
I'm using apache php8.1 and laravel9 in this project. It is also a production environment.
*** Solution ***
As alluded to in the comments below by DadoH, i needed to add code to stop indexing to the .htaccess file.
Adding to storage folder didn't work but adding the Options -Indexes line to the top of the .htaccess in the public folder did.
You can disable browsing of a folder when there is no index, if you add Options -Indexes into your .htaccess in your storage folder.

Magento Use Web Server Rewrites in Multi Domain Setup

I have to two stores each having different domain. They are hosted on dedicated server with SuExec disabled. I have copied the .htaccess and index.php and everything works fine.
The problem I am having is with my 2nd store Web Server Rewrites. As soon I enabled this for the 2nd store which is using symbolic link to the root directory, it starts giving page not found error.
domain2.com/index.php/abc.html ----- Works Fine with Use Web Server Rewrites Turned Off
domain2.com/abc.html ----- Does not work with Use Web Server Rewrites Turned ON
The base store works without any problem.
Any help is much appreciated.
Farrukh Khan
-> Flush The Magento Cache
Goto System->Cache Management
Refresh the catalog rewrites
Goto All Cache and change drop down to Refresh.
Click save
On most server, this should take out the index.php in your URL’s.
If you are getting a 404 error, continue reading.
-> Fixed Mode_Rewrite Errors
Please check you webserver configuration.
Do you use Apache? Maybe there is something like "AllowOverride none" in your configuration which disables .htaccess-files (the .htaccess-file in your magento-root-directory defines the rewrite-rules).
The most common cause for this is that you have an incorrect .htaccess file in your ftp.
Goto the magentocommerce.com site and download the magento files again.
Extract the files, and ONLY upload the .htaccess file to your Magento root directory.
This should fix any problems related to enabling the use of web server rewrites in Magento.
I was facing the same problem above, but now i solved already. The main reason for that problem is .htaccess file. By replacing .htaccess file with magento default .htaccess file solve all the problem. Web Server Rewrites Turned on or off, you can do as you like.
After saving the configuration, don't forget to clear cache.

Magento index page loads but 404 errors on all others

Currently I am struggling with the categories and products showing 404 errors when I navigate away from the working home page.
I was able to install Magento and I am using a copy of an existing working site. The purpose is to use this new site as my dev sandbox. I am using Magento 1.11. This is also a multiple store site.
Things I have tried:
Reindex the Catalog URL Rewrite, this unfortunately never completes.
To try and solve this I have deleted all the lock files and then I have also deleted all the entries in the core_url_rewrite table.
I have also changed the Base URL in the core_config_data table to my new URL.
Thank you in advance!
Just like Fiasco Labs said, you probably turned on URL Rewriting:
System -> Configuration -> General -> Web -> Search Engine Optimizations -> Use Server Rewrites but don't have mod_rewrite Installed/Enabled.
Either Install/Enable it on your host, or just turn the server rewrites off.
Another reason, if you HAVE mod_rewrite Installed/Enabled, you might be missing .htaccess file in your Magento root.
even with mod_rewrite enabled, the error can be a misconfiguration of apache. Have a look at etc/httpd/conf/httpd.conf file. Find the part where is defined (standard Apache config dir). You should find:
AllowOverride All
If there is a
AllowOverride None
Change it to All and the magic happens. Then restart Apache with:
sudo service httpd restart

Magento 1.4.2 Upload HTTP Error on CentOS

Recently I upgraded Magento from 1.4.1 to 1.4.2 on CentOS and I have the issue where I can't upload images to the server through the WYSIWYG (Upload HTTP Error). I have researched the issue on numerous forums but none of the solutions work. Here is what I have tried:
Made sure the permissions are writable on media directory and tmp folder. I can create folders, just can't upload images.
Tried modifying the .htaccess in media folder:
#Options All -Indexes
#Options -ExecCGI
I have tried turning this off suhosin in php.ini
suhosin.session.cryptua = off
I have tried adding a php.ini in Magento root with:
magic_quotes_gpc = off
short_open_tag = on
extension=pdo.so
extension=pdo_mysql.so
I have the following in my .htaccess:
<IfModule mod_security.c>
###########################################
# disable POST processing to not break multiple image upload
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>
and tried adding this to the .htaccess as well:
SetEnvIfNoCase Content-Type "^multipart/form-data;" "MODSEC_NOPOSTBUFFERING=Do not buffer file uploads"
I don't see errors in any of the log files, so I am totally stumped.
Looking with firebug I see no network traffic when I click the upload file. So it makes me think that this is a JavaScript issue or a flash issue.
I have replaced the prototype.js with 1.6 but that did nothing. Also giving full permissions to the flash uploader (/skin/adminhtml/default/default/media) did nothing.
We've had such a problem once. It was connected with events in our custom modules. One of them was conflicting with the uploader module (the solution was to change its scope from global to frontend - but your case may be different). Try disabling all of your custom (/local/ and /community/) modules using their XML configuration (set their value of 'enabled' to false or just move out the files from /etc/modules/ to /app/disabled/). If it helps just turn them on, one by one.
Another, similar situation happened when we used htaccess and rewrites to add/remove slashes to certain magento addresses.

Blank index.html in CMS softwares instead of .htaccess

I noticed Joomla, Wordpress and other CMSs have blank index.html files in ALL their sub folders to prevent people from peeking into the folder structure. My question is why can't they forbid folder viewing using the .htaccess file instead of putting a blank index.html file into all the folders. What's the difference and why have they chosen index.html?
Turning off folder 'Indexes' is best done in the master httpd.conf or vhosts.conf file rather than local .htaccess files.
Joomla (and Mambo before it) have been around quite a while and are used widely on shared hosting servers. The decision was taken to use index.html files as a safe fallback given the 'mixed' nature of shared hosting. Obviously .htaccess files are apache only, can cause server 500 errors if present on servers not expecting them or if they contain directives not supported by certain server setups. Consequently by default Joomla doesn't ship with a .htaccess file as such. There is a htaccess.txt file which the user needs to put in place manually if they activate certain features. It is assumed that a user knowledgeable enough to put the file in place will understand the consequences and if it does kill their site they will immediately understand the cause - due to the error immediately following their actions.
As server setups have advanced there is (sometimes heated) discussion about the current validity of the use of index.html files - but for now the policy is that all add-ons should ship with 'blank' index.html files in all folders.

Resources