I have copied an existing drupal 6 site to a new host. I thought it was an easy task. Just change the mysql login credentials and run. But obviously not. Fist page is up and runing, but all links to existing pages doesn't work.
What am I missing here? Another configuration I've missed.
The Drupal 6 installation is a NodeStream distibution.
Link to site:
http://u0002002.fsdata.se
It is likely that you forgot to set up mod_rewrite so the nice urls don't work.
It is almost certain mod_rewrite is not turned on you can access pages like this
http://u0002002.fsdata.se/?q=yrke-karriar
To resolve quickly:
Turn off clean urls (don't know the exact url in Drupal 6)
Flush all caches
This will resolve until you can get mod_rewrite turned on or working.
A very common (and even easier to fix) problem that happens when moving hosts is that you forget to include the .htaccess file which can cause problems with clean URLs too.
Fix: Upload a fresh copy of the .htaccess file that comes with Drupal to your web root directory.
I have found out that sometimes I miss this file. This is because I installed Drupal by dragging all the files and folders over to my server, but since the .htaccess file starts with a period, OS X hides it. This means that the .htaccess file was never moved over. - Source DrupalDude.com
And from Drupal.org directly, Clean URLs not working? Check your .htaccess file
Check if the .htaccess file was actually uploaded. It should be in the directory where you uploaded Drupal (for example: /public_html/drupal/)
If the .htaccess file is missing, you need to upload it. If you accidentally deleted this file, just download Drupal again, and copy the new .htaccess file.
Make sure the file is only called .htaccess and not htaccess.txt or anything else. The .period .at .the .beginning is required.
This name usually means that the file will be invisible on folder listings on Unix-based systems so you might not always see it. If using an FTP client, you may have to configure it to 'show hidden files'. If listing on the commandline, you must ls -la to see it. This will be somewhat dependent on your OS.
Here are two tutorials which may help you:
How to move a Drupal site from one host to another
How to Move a Drupal Site to a New Host Without Going Crazy
Related
I've got a site that has been hacked for the fourth time now this month. With scripts hosted on autofaucet.org. (sloppy code even, found their names. Some Russian dudes. But that's off topic) I've taken some measurements to prevent a new hack, but alas...
I've installed a clean WP installation on the server, with clean files and a clean DB.
reinstalled the plugins clean
I have All In One WP Security & Firewall plugin for file scanning, firewall, hide inlog page, etc.
Changed all the wordpress passwords.
I've notices the encoded code is being placed in files called assets.php.
I'm curious how a hacker would inject/place the code on the server. How to prevent it better and what questions to ask the webhost company. I've asked them before and they just say it's my fault, update the wp installation and move on. What should they check if the code is injected from their side?
Your log files (of the web server) e.g. /var/log/nginx/access.log with the nginx web server will tell you who it was. Look for the change date/time of the assets.php file. Then check server access logs for IP addresses from that exact time. Then search logs for that IP address. You will find the first accesses by that IP address. That was likely the hack.
Usually Wordpress plugins are to blame as long as you keep the WP site updated. So, you could disable plugins not needed urgently, and disable the others one by one, or all for testing.
As a workaround, you can make the index.php (or other) file under attack read-only. In the past I have worked around particular attacks by chown root.root filetobeattacked.php which usually works (but may hinder updates, so it's a temporary solution). If you are not root on the server (shared hosting) perhaps chmod 444 filetobeattacked.php could work.
I had same issue before. It might be the wordpress core files.
Delete all files except wp-content, then download and replace it with the new wordpress files.
Search for 'autofaucet.org' inside wp-content, and remove if necessary.
Open wp-contents/themes/ then check functions.php - check if any additional code is there on top. Check the last updated files and time inside the theme and plugins.
Export database files and searcg for 'autofaucet.org' and remove if any item found.
I have two wordpress websites on my dedicated server, and the htaccess files of both websites keeps changing to default one and become 444 chmod.
Even after i fix it and put chmod 444 of mine few days later it changes again on both websites.
Could you please help me make the htaccess files impossible to be overwritten or edited no matter what?
I will appreciate any help,
Thank you
I find my infected file in one of the themes of wordpress, so you have two ways
LogIn to wordpress and delete all the new themes that you are not using.
Go to you your admin page go to folder: wp-content/themes/sydney/404.php
open it and if you see the virus code like if it has +xml or Rewrite wordpress etc delete it.
go through all the themes folder 404.php pages.
change your wp login user name and password.
delete all the infected .htaccess files/remove the infected code and monitor your website the regularly and check ur .htaccess file to make sure you don't get attacked again.
I have resolved this by scanning my ubuntu server using clamAv through SSH.
Here is the command line I used:
clamav -ril /home/user/clamav.txt
The results revealed a backdoor script embedded in one of my old themes which wasn't even activated. I deleted that old theme entirely and rebooted my server then the problem is gone.
Don't waste your time with a WordPress plugin to scan for malware or
backdoor because that is unlikely to locate any virus. Install ClamAV
into your server then scan. If nothing is detected yet?! Install
another anti similar to ClamAV until you succeed to locate the threat.
I'm struggling from an error on WordPress 3.8.1.
Whenever I try to upload a media to a post, it does not add, it says An error occurred in the upload. Please try again later..
But the weirder thing is that it is shown on dashboard/media/library even after this issue.
I also cannot see uploaded attached media to my posts (edit post / [add media button]) / media library / uploaded to this post, but in dashboard/media/library section , these old uploaded images are shown properly that which is uploaded to what post.
I have tried the followings:
Re-installed both my local version and en_US from both update manager and manually
Deleted wp-includes and wp-admin folders and replaced them manually.
I have checked chown and chmod of the wp-content/uploads folder. To make sure they are working, I have deleted wp-content/uploads/2014 folder, and after first upload that shows this error, the folder is created with right chown and chmod and files were there (wp-content/uploads/2014/01/26/file with resolutions.jpg)
I have deleted unneeded plugins, deactivated all plugins and themes, switched back to WordPress's default plugin, I have even reset active plugins json object at wp_options from SQL, did not help.
I have enabled php error logs, nothing related is shown
I have altered the WP_DEBUG definition to true, I have even defined WP_DEBUG_DISPLAY to true, no help.
When I try to add from wp-admin/media-new.php , using multi uploader, file is freezing at "Crunching…" step, but old browser upload works flawlessly.
I'm managing the VPS and hosting the blog myself with CentOS 6.5 x64. safe_mode is set as off. There is not a mod_security option in my php.ini. My upload_max_filesize in php.ini is set to 20M, memory_limit is 256M, only 3 sites are hosted and memory is quite empty while testing these. This also happens even with 50kb .jpg images, so this should not be related.
I have re-uploaded all wordpress files from a clean downloaded zip, no help.
I have tried adding AddType x-mapp-php5 .php .php4 to the end of .htaccess as suggested here, that did not help at all.
The thing is that, I have tried a clean installation to another domain on the same server, it is working as it should.
What could be the problem? How can I fix this?
Thanks in advance,
See if custom post type has any files that are in UTF-8. If you change it to ANSI, that should help, if thats an issue.
I had the same issue, and found that there is a problem with my theme itself... try doing the same action using the twentyten theme. if that works, then take a look and see if there is any conflicting code in the functions.php of the theme...
if you are using a child theme can I suggest making another child theme, or using an alternative them as in my experience not all themes "like" being used as a child...
If you are trying to upload into a custom post-type, change the capability_type setting in your functions.php file to 'post' and it should fix your problem.
Check permissions of your wp-content or wp-content/upload folders, If folder permission is not 755 then change it to 755 and re-upload again. I hope it will solve your problem.
If you are using a low scale server and added a plugin named "WP-SmushIt" then it will surely cause an error. Reason is simple this plugin uses CPU resources to minimize the size of images in process of optimizing it and so it crosses the server limited execution time. Solution is simple-> Go with higher plan servers or try changing server execution time listed in php config file.
Not directly related to this, but I have experienced the exact same issue after moving the very same site to a different server now. Only difference is now I've been using Nginx instead of Apache. I have checked the ownerships before and they were all correct (else the normal upload wouldn't work earlier either). I'm leaving this here just as a reference.
The fix on my newer case was simply changing the ownership of the web root and all the files inside.
Nginx and PHP5-FPM were running with same user: www-data, which is at the group with same name: www-data.
So changing of all the ownership of the files fixed in this case:
su
chown -R www-data:www-data /path/to/wordpress/root/
And the issue was gone.
I still don't know the original reason of my old issue, I had to wipe, start from clean and restore the posts, plugins etc. from scratch.
I was facing same issue in wordpress like media not loaded in popup. then i have resolved.
I think, Some times problem created by ajax response.Means ajax response comes with some additional content.
Wordpress media popup is loaded content by ajax(json Response) and ajax give response with some content like style and other.
For Example:-
<style>
.class{}
</style>
then json(ajax response).
So First check your ajax response in console.We have to disable all plugins then check it is work or not.If no then activate default theme. because content comes from plugin and theme.
check your folder permission, and mod_security settings, also try to increase max_execution_time and memory,
I have no access to my FTP but I'm able to edit the web through Wordpress. Is there any way I could perhaps generate the .htaccess file through the admin framework? I know there might be a plugin to do that, but bear in mind I have no FTP access and the plugins require it to be installed.
I need the .htaccess file to redirect the user to another site.
I know this might strike you as weird and stupid, but this is due to the company's central decision to keep the site hosted by, I guess, a "friendly" hosting company. There's no way of recovering the login/password for FTP, so this might be the only solution.
Please, try posting constructive comments only, no "contact the hosting company". If I could, I would.
If your hosting company has set up wordpress correctly, then there is no way to do this, because unix permissions should make .htaccess read-only to the owner of the web server.
If the company has not done this, and if you have a way to change the templates, you might have success by creating a template that contains php code to open and write the .htaccess file.
Sample code to be put at the top of the header.php:
echo 'Current dir: ',getcwd(),"<br>\n";
if ($handle=opendir('.')) {
while (($file=readdir($handle))!==false) {
$ok=(is_writable($file) ? "ok" : "can't write");
echo "file '$file': $ok<br>\n";
}
closedir($handle);
}
This is to test you're in the root directory of your wordpress installation. It should give you the current directory, a list of all files in that directory (expect .htaccess, index.php, and various wp-* files), and their writability.
Once you've checked everything is correct, add
file_put_contents('.test', "RewriteEngine On\nRewriteRule ^(.*)$ site.com$1 [R=301,QSA,L]\n");
echo("<code><pre>-------- included file starts here\n");
include(".test");
echo("-------- included file ends here</pre></code>\n");
to the php code. This writes to a test file and includes it so you can check if everything is ok. When you've checked the file contents, replace .test with .htaccess.
WARNING: You should be VERY sure about the content of .htaccess. file_put_contents doesn't append the new string, it overwrites the whole file. Once you've written a bad .htaccess file, you might not be able to ever change it again, because the web server will redirect you to the new site instead of executing the script on the old site.
I am sorry for your situation. What is the hosting company (will keep this in mind if I ever use them). To try to help:
Do you have access to CPanel? Most hosting providers give it out of the box. Cpanel has a file manager.
Research Wordpress file managers (http://wordpress.org/plugins/wp-filemanager/)
How to edit wordpress .htaccess file from hosting Cpanel: If you are currently unable to login in your wordpress dashboard, or facing 500 internal server error. There is 90% possibility that you were editing your .htaccess file from your wordpress dashboard. In this situation you can only fix your wordpress .htaccess file by editing it from cpanel. Editing .htaccess file from wordpress dashboard is little risky with .htaccess editor plugins. If you will implement any wrong code then you might face 500 internal server error and your site might crush. So first you should take a backup of your existing .htaccess file before editing it. If you have a backup of your wordpress .htaccess file then you can upload it through your hosting cpanel also.
https://howtoways.com/how-to-edit-wordpress-htaccess-file-from-hosting-cpanel/
I moved a Wordpress website from one server to another and I am now getting 404 errors on everything but the home page.
I also checked that the .htaccess file is there and the database contents. They are fine. Not sure what else could be causing this.
Any ideas from the community?
Assuming you have pretty permalinks enabled, are you sure that the new server has mod-rewrite enabled? You can also check to see if this is the problem by going to a pagelike yoursite.com/?p=1 where 1 is a page id.
Assuming the URL has changed
You need to update either the database or (if you're lucky) one of the .php files in the wordpress distro - see the wordpress article on this.
I had the same issue and ended up having to edit the database. You're seeing the 404's because wordpress thinks it's still hosted at the old URL and is therefore trying to retrieve files from it.
If the URL has not changed
Perhaps permissions need updating on the folders? The folders should be set at 755 and the files 644 (reference here).
Looks like you may have solved the problem - I had a similar problem where permalinks would not work, but the default links did work. I modified the .htaccess file to what Wordpress said to do. Twice I thought I had solved the problem, but didn't.
I had moved it to my local Ubuntu Karmic Koala system for testing, and found that the solution involved editing a file in /etc/apache2/sites-enabled. On my system, it was called 000-default.
This file had statements like the .htaccess file, and in two places had AllowOverride None, which I had to change to AllowOverride All. Apparently, this file overrides any local .htaccess files.
I also had to change the location of Wordpress in the main configuration, but that was obvious.
I hope this will help someone who has tried all the normal suggestions like me, and is still having problems.