I have just migrated the website to new hosting and since then when I tried to upload new media files into the library, it always had HTTP error and media thumbnails are looking like in the attached picture.
I tried to find solution on the internet - removed and added new .htaccess file or added some code in it - none of these work. Has anyone ever faced this problem before? What's the solution?
Thank you,
Scott
This is a very annoying problem. In my experience, it causes due to three reasons;
Inappropriate folder permissions for wp-content/uploads folder.
If your site is using HTTPS through CDN like Cloudflare, it needs some additional configuration.
Another reason this might occur sometimes is if you change your theme or as in your case, the host. The solution for this one is to use this plugin Regenerate Thumbnails
You can share some more details for further discussion.
adding this as might help someone, an annoying error of my side.
Issue: migrated from localhost to a provider (in a fast maybe hacky way:)
exported the entire db from the local mysql (resulting in db.sql)
Changing the file db.sql:
changed the url 'localhost' to the domain, in the options-table (manually, typing it, the 2 rows)
replaced (as a String search-replace action) all localhost-links, globally (I used VIM :%s/localhost:8080/mydomain.com/g )
replaced (as a String search-replace action) the (default) table prefix "wp_" to 'mine': "mf_", globally (also VIM, as above)
Done with the db.sql. Now, uploaded (by filezilla) the files, recreated the db at the hosting provider by 'import' of the db.sql.
Did also: set all file and folder permissions as suggested in the web on many places. Did not forget to set stricter permissions for wp-config, and the 644 for .htaccess.
Issue: can access the application, can see (as admin) the media grid. However, all thumbnails were grey, and checking all suggestion as above and in other websites (like the access permissions) it seemed correctly set.
SOLUTION: In the table postmeta (!!!) there are attributes set to images, containing the text-part "wp". By changing the file db.sql globally, all "wp_" (the default prefix for the tables) to 'mine' ("mf_"), these attribute names were also changed.
(what i did then: exported the table postmeta and replace by VIM globally "mf_" again with "wp_", re-imported the table)
Please note: i am not a web developer and i am aware that it might not be the way supposed to be done, but it is the fastest, without much manual clicking around etc.
Maybe it helps someone, it happened a few times to me, so hopefully next time I myself will look into this stackoverflow answer, the idea of re-uploading the images (as suggested in several places) when they are already there is sort of daunting to me.
Related
I got a website in Wordpress and recently we discovered that it was infected by several malware scripts that insert scripts using the common base64 and eval functions like this:
We were able to solve most of the infected files but there are still some scripts being injected into the index.html, like these:
All these scripts marked in red make a requests to sites that immediately trigger my computer antivirus.
So question here is, how can I track which file loads these lines? How can I know which file prints them? I can't just search for the string since the code is encrypted like on the first image...
The truth is, it's probably going to be more than one file, and/or it's going to be something hidden deep in a plugin/upload folder.
This is going to be a bit time-consuming, but these are generally the steps I follow when fixing a hacked site to narrow things down and make sure I got all the crap out:
1) Before you do anything else, make sure you have a backup of both the files and db. That way, if you accidentally delete something, it's easy to restore.
2) Delete any unused themes or plugins, and make sure all existing plugins are up-to-date.
3) Update WordPress to the current version. Seriously. Keeping up-to-date is important. If you're more than two major releases behind, you'll want to update incrementally. (https://codex.wordpress.org/Upgrading_WordPress_-_Extended_Instructions)
4) After you've updated, connect via FTP and look for files older than when you updated. Look for extra files that shouldn't be there--this can be tricky, because hacked files are usually named things like wp-shortcode-s.php. I usually have a copy of WP core files open in a window beside my FTP client as a reference.
5) Check the first few lines of code on php and js files in your plugins folder for malicious code. Again, you might want to have a freshly downloaded copy of the plugin to compare files to.
6) Check the uploads folder and subfolders for malicious files.
I also keep checking my hacked site here to see how I'm doing:
http://isithacked.com/
And when you're finished, you might want to read up on how to harden WP to make it more difficult to hack.
Depending on the source of the malware, it's hard to give you a precise hint. There are a few more in-depth walk-through about the topic you can find on Google, here are some good examples which could help:
https://www.wordfence.com/docs/how-to-clean-a-hacked-wordpress-site-using-wordfence/
https://blog.sucuri.net/2011/02/cleaning-up-an-infected-web-site-part-i-wordpress-and-the-pharma-hack.html
Also if you are on a shared host, potentially the issue could be coming from an other compromised user. Hopefully you have a clean version of the site so that potentially moving to an other host (and upgrading) is an option.
I've got a weird issue lately and I am not sure what causes it. I've got a dedicated box with a few websites on it and it seems like memcache only works on half of them.
2 wordpress websites (both got W3 Total Cache with same settings) and one of them is stuck while the other one works fine. If I manually clear cache from W3 it will work until the next post.
At first I thought it was plugin's fault but then I've noticed similar issues on some of my other sites. For example, when I try to update a php file it will show me the file I uploaded unless the file size is different.
Another occasion was DIR which would point out to the old folder name (the one used when it was uploaded) unless I edit all the files in that folder that had DIR in them.
Any ideas/suggestions?
PS: All these things started happening after I installed php curl on my server.
Here's my problem :
I switched a Wordpress site from HostGator to MediaTemple. Since the domain name stays the same, I backed up and re-imported the database, downloaded and re-uploaded the site content without issues.
The first time, everything worked well except that in place of the images, I could only see question marks. Opening the image in a new tab would show "Not found". I went in the FTP and realized that the file names were in french and with accents in them like "é" and "à", and that in the process of downloading the files to my Mac (Using Coda) and re-uploading them in the server, the accents were all replaced by weird characters...
I tried to manually rename them, it did not work
I tried to do it using different Ftp apps, did not work
I tried using windows to do it, did not work
I managed by playing in Coda's preferences to change the encoding and to re-upload the files to the server while keeping all the accents but it still didn't work...
Database is in UTF-8, and I tried multiple collation like UTF8_bin and general_ci but it didn't work either...
I am pretty sure it is a character encoding issue since there is 1 or 2 images working on the site and they have no accents in their names but I really don't know where to look anymore.
Switched multiple Wordpress websites and never had this problem before, could somebody point me in the right direction please ?
In wordpress all the links are saved into the database and are not hard coded in the html files. So when you're shifting your website from one host to another, you must find and replace the previous host's links with the new host's links in the database file exported from the previous host before importing it into the new host.
Go to the following links for details.
How to Move WordPress From Local Server to Live Site
Moving WordPress - Wordpress Codex
Wish you good luck.
Ask your new hosting service to chown your files to your new account, which may be solve the problem.
Im relatively new to silverstripe cms and Im trying to move a site to a new host.
I followed all the instructions I could find on their official forums but to no avail.
Here is what I mean.
Here you can see what the site should look like
http://www.efekto.co.za
But this is what it looks like after I have moved it (copied everything to my public_html folder on the new site, set up the db username and passwords etc)
Please help cause I'm utterly and truly stuck at the moment.
Since someone else initialy moved the site so I decided to delete everything and move everything myself. Its hard to explain otherwise what I have tried or not tried.
First I tried to install just a base silverstripe. Got that right pretty much but only after I specified the database ip as 127.0.0.1 and not the external ip. So I deleted the base install again, copied over all the site files again and this time modified the db params to use 127.0.0.1 Some of the pages now actually reflect valid content but it seems that everything is not this light blue kind of color (seems to be a default of SS? ) It is as if it's missing some kind of master page or something as I can see content, but no module thingies like menus, blog section etc.
I also have to mention that to test this I change my hosts file so that www.efecto.co.za resolves to the sites new ip address with our new host. So from my machine it resolves to new ip but from the servers perspective when it fetches things like css its obviously going to fecth it from where www.efekto.co.za is currently hosted. Hope that makes sense?
So 1 step in the right direction at least. We have content and no more errors. Now whats up with this blue color scheme??
http://www.efekto.co.za seems to be fine now.
My guess: You've had a silverstripe-cache folder on your old server, which you've copied. It contains (as you might suspect) cached files with absolute paths. If your path structure is not exactly the same on both servers, you will run into problems. So always remove everything from the cache folder when moving sites around.
If that isn't the problem, take a look at the Apache log file (probably /var/log/apache2/error.log, but this can vary). As it's a server error, it should tell you what the problem is...
Check the error log in cpanel or whatever, perhaps a PHP or APACHE directive is different on this server. You'll find out from the logs what the problem is.
I got this once and the problem was that /dev/build wouldn't run because the php memory upper limit was set higher in SS than it was on the server.
Also go into _config and set the environment directive to 'debug', this will display as much output as SS can give you on the page.
I'm writing a CMS on PHP+MySQL. I want it to be self-updatable (throw one click in admin panel). What are the best practices?
How to compare current version of cms and a version of the update (application itself and database). Should it just download zip archive, upzip it and overwrite files? (but what to do with files that are no longer used). How to check if an update is downloaded correctly? Also it supports modules and I want this modules to be downloadable from the admin panel of cms.
And how should I update MySQL tables?
Keep your code in a separate location from configuration and otherwise variable files (uploaded images, cache files, etc.)
Keep the modules separate from the main code as well.
Make sure your code has file system permissions to change itself (use SuPHP for example).
If you do these, simplest would be to completely download the new version (no incremental patches), and unzip it to a directory adjacent to the one containing the current version. Because there won't be variable files inside the code directory, you can just remove or rename the old one and rename the new one to replace it.
You can keep the version number in a global constant in the code.
As for MySQL, there's no other way than making an upgrade script for every version that changes the DB layout. Even automatic solutions to change the table definition can't know how to update the existing data.
A slightly more experimental solution could be to use something like the phpsvnclient library.
With features:
List all files in a given SVN repository directory
Retrieve a given revision of a file
Retrieve the log of changes made in a repository or in a given file between two revisions
Get the repository latest revision
This way you can see if there are new files, removed files or updated files and only change those in your local application.
I recon this will be a little harder to implement, but the benefit would probably be that it is easier and quicker to add updates to your CMS.
You have two scenarios to deal with:
The web server can write to files.
The web server can not write to files.
This just dictates if you will be decompressing a ZIP file or using FTP to update the files. In ether case, your first step is to take a dump of the database and a backup of the existing files, so that the user can roll back if something goes horribly wrong. As others have said, its important to keep anything that the user will likely customize out of the scope of the update. Wordpress does this nicely. If a user has made changes to core logic code, they are likely smart enough to resolve any merge conflicts on their own (and smart enough to know that a one click upgrade is probably going to lose their modifications).
Your second step is to make sure that your script doesn't die if the browser is closed. This is a process that really should not be interrupted. You could accomplish this via ignore_user_abort(true);, or some other means. Or, if you like, allow the user to check a box that says "Keep going even if I get disconnected". I'm assuming that you'll be handling errors internally.
Now, depending on permissions, you can either:
Compress the files to be updated to the system /tmp directory
Compress the files to be updated to a temporary file in the home directory
Then you are ready to:
Download and decompress the update en situ , or in place.
Download and decompress the update to the system's /tmp directory and use FTP to update the files in the web root
You can then:
Apply any SQL changes as needed
Ask the user if everything went OK
Roll back if things went badly
Clean up your temp directory in the system /tmp directory, or any staging files in the user's web root / home directory.
The most important aspect is making sure you can roll back changes if things went bad. The other thing to ensure is that if you use /tmp, be sure to check permissions of your staging area. 0600 should do nicely.
Take a look at how Wordpress and others do it. If your choice of licenses and their's agree, you might even be able to re-use some of that code.
Good luck with your project.
There is a SQL library called SQLOO (that I created) that attempts to solve this problem. It's a little rough still, but the basic idea is that you setup the SQL schema in PHP code and then SQLOO changes the current database schema to match the code. This allows for the SQL schema and attached PHP code to be changed together and in much smaller chunks.
http://code.google.com/p/sqloo/
http://code.google.com/p/sqloo/source/browse/#svn/trunk/example <- examples
Based on experience with a number of applications, CMS and otherwise, this is a common pattern:
Upgrades are generally one-way. It's possible to take a snapshot of full system state for a restore upon failure, but to restore usually entails losing any data/content/logs added to the system since the upgrade. Performing an incremental rollback can put data at risk if something were not converted properly (e.g. database table changes, content conversions, foreign key constraints, index creation, etc.) This is especially true if you've made customizations that rollback scripts couldn't possibly account for.
Upgrade files are packaged with some means of authentication/verification, such as md5 or sha1 hashes and/or digital signature to ensure it came from a trusted source and was not tampered. This is particularly important for automated upgrade processes. Suppose a hacker exploited a vulnerability and told it to upgrade from a rogue source.
Application should be in an offline mode during the upgrade.
Application should perform a self-check after an upgrade.
I agree with Bart van Heukelom's answer, it's the most usual way of doing it.
The only other option would be to turn your CMS into a bunch of remote Web Services/scripts and external CSS/JS files that you host in one location only.
Then everyone using your CMS would connect to your central "CMS server" and all that would be on their (calling) server is a bunch of scripts to call your Web Services/scripts that do all the processing and output. If you went down this route you'd need to identify/authenticate each request so that you returned the corresponding data for the given CMS user.