WordPress is a great tool for creating websites. Some people believe that they do not need to keep their scripts updated.
The most common reasons for this are:
When people’s websites have security issues there is one cause of the problem which I see more than any other. Scripts that are not updated. When I ask people why they do not keep the scripts updated to the newest version I am told a few different reasons. In general they boil down to the site being abandoned, or to people using custom coding. Sometimes I’ve heard that people want to wait for a certain period of time until the scripts are “Mature enough.” The problem is that while this strategy can work for software, and operating systems scripts are a little different. First programs and operating systems are compiled. Compiling means that the code is changed into code that the computer natively understands. A script, like the many that are used to run websites are not compiled. Each time it is loaded the software that is compiled is the result of constant coding, and as it matures bugs, and other problems are removed and it functions better. Scripts also have bugs, every time a script releases an update it contains fixes for the previous bugs that hackers may be able to use to place malicious code into the web hosting account. Keeping your scripts updated is a way to make sure that hackers do not have as much of a chance to compromise your account. Many scripts in use today are mature products, and are not prone to major changes, which cause performance to degrade.
In my job doing technical support for web hosting I have assisted many people in getting their WordPress websites going. There tend to be people with two sets of issues that call.
I want to discuss these problems with some information to aid in getting your WordPress site started, and to help you secure it.
WordPress is a great “Personal Publishing” platform. It started life a just another blogging platform, but has evolved into a very powerful CMS (Content Management System) capable of being used by sites that do not have a blog.
One of the advantages of WordPress are the resources in themes, plugins, and documentation.
These are the plugins I use in all of my sites. I believe they give the best bang for the resources.
Occasionally when your site gets a large number of simultaneous visitors the site could appear down due to the overwhelming number of php processes running on the server. There are a couple of ways that you can combat this. You can install a caching plugin, like W3 Total Cache, or Super Cache. I have found these to sometimes slow a WordPress Site down even more, and when I have gone to remove them I have found that I had to rebuild my websites. Another option is to make use of a service like CloudFlare. My sites have access to CloudFlare through my hosting at HostMonster. CloudFlare provides the same type of caching as the caching plugins.
Securing a WordPress site can be complicated, but there are two items which can help dramatically each day:
This is one of the first things I do when I make a brand new site, but if you have an established WordPress site you can make use of Better WP Security to do this.
WordPress like all database driven websites is vulnerable to attack through vulnerabilities in the code. Since WordPress will always have vulnerabilities it is important to keep WordPress, the plugins you use, and themes updated, and your passwords secure. One part of securing a password is to use a strong password (8-12 characters long with at least 1 uppercase letter, lowercase letter, number, and symbol).
Remember to confirm all user inputs. Items on Forms, in URLS and so on. Remember to make use of access Control. Keep users away from admin areas, and other places they do not need to be.
Make use of .htaccess to block known bad users, or the IP ranges of countries that you do not want accessing your website. Better WP Security is able to add some black list ips to your .htaccess. You can also make use of some free services Like this one to block access to certain countries. This may be useful if you see attacks coming mostly from certain countries and you do not need traffic from those countries this can be a useful tool to protect your site.
WordPress is a great resource for creating and administering many types of websites. With WordPress you get a highly polished system to create content with. Thousands of free themes, and plugins to expand your sites functionality and to get that look that is perfect.
WordPress is great at
Along with all that also comes some issues, which often get people into trouble:
The biggest problem I have seen is WordPress, it’s plugins, and themes are not updated regularly. When new code is released one of the first things that bad people do is look for ways to compromise WordPress, plugins, or themes.
Fortunately good people also notice these issues and correct them. After the code is corrected an update is prepared, and sent out. After the updates people who wish to be malicious look for these out of date scripts to make use of the known vulnerabilities.
Another problem that can be found is that plugins and themes are used without verifying their source. It is possible to slip malicious code into themes and plugins. There is no checking of the code which is submitted to these plugins and theme directories.
While checking the code directly is the only way to be absolutely sure what a plugin is doing. If you examine the number of downloads and ratings of the plugins will help you find high quality plugins.
The last item that I see where people have problems is not specific to WordPress, but when you forget you have installed stuff on your web server, and then forget about it you will have problems from outdated scripts,which may lead to all sorts of issues.
Keep your scrips updated, and you will see fewer issues with compromised scripts, because as soon as the compromises are found they are fixed. Watching how often and how highly rated a plugin will help in always using reputable code in your WordPress site. Lastly, don’t forget about your code; keep your hosting account clean.
I recently made the effort to upgrade multiple sites from WordPress 3.4.2 to WordPress 3.5. Unfortunately, along the way I encountered some difficulties.
I use Hostmonster as my web host. Hostmonster has integrated with the SimpleScripts service, which is similar to Fantastico. SimpleScripts usually does a great job of keeping things up to date, but it does not update plugins. The problem is WordPress 3.5 is incompatible with the version of the Jetpack plugin installed with version 3.4.2.
My solution is to go in and delete the old Jetpack plugin from the plugins directory, and then log into my dashboard and reinstall the Jetpack plugin.
The second major problem was that I had some sites using the W3Total Cache plugin, and I kept having problems getting the sites up again. I have seen the caching plugins on my WordPress sites cause these kinds of problems before. They seem to cause the performance of the site to become fickle. A little change in the settings can crash the site.
My solution is to install a new WordPress, and configure it to match the old one, which had been using the caching plugin. The next step is to link ye new site to the old database. Finally I move the new WordPress install into the old URL and I have generally removed unused plugins, and streamlined the site along the way.
I have read about optimizing WordPress to make www.excalibursheath.com load faster. My goals are:
The site was not scored very badly for not optimization having been done.
The jump from the caching plugin, and Cloudflare was remarkable.
Optimizing the images resulted in a nice bump in performance.
In summary:
If you follow the steps below your site will see a huge decrease in loading time. There are more advanced features you can do, but I think these few steps are where you see the most bang for the buck.
To migrate a site from WordPress to Drupal is a fairly straight forward process.
You can roll back the import if it does not go well,
I have put together a list of useful commands for Unixes and Linux. These are Linux variants of the commands.
ls -alh – list directory
history – lists a history of commands run
cat – Display file on screen
grep – keyword search
less – read a file and format for pages
host – displays server name
clear – clears the terminal screen
exit – exits terminal log in
kill – kills processes
rm – remove file
cp – copy a file
mv – move a file
vi – advanced text editor
nano – text editor
strings – Interprets Binary files and shows what can be printed on the screen
cd – change working directory
pwd – print working directory
tail – displays the last 10 lines of the file unless -n is used to tell it how many lines to go up -c is how many bytes you want. -f to follow the log.
touch – creates an empty text file and updates the modified
date – outputs the current date of the system
which – gives full binary path to commands
Web servers return many codes. Some mean everything is working, and some are errors. I am going to go over some of the common codes. Some of these codes you see and some you don’t.
In general there are five blocks of codes. There are 100, 200, 300, 400, and 500 codes.
100 codes respond with a request for the process of loading a web-page to continue.
200 codes respond that the server completed its process.
300 codes indicate that the web-page has been moved.
400 codes indicate file errors.
500 codes indicate server errors.
I want to call your attention to two codes in particular:
404 – Not Found
500 – Internal Server Error
The 404 and 500 errors are the most common errors encountered. The 404 error occurs for a few reasons: the file does not exist, the link is wrong, or the server is case-sensitive and the case of the filename is different. Here is an example of a link which produces a 404 error. One reason why there may be 404 errors in an established site is if the links changed radically, or if an old domain is rebooted, with a new topic. The 500 error is an error in web applications. It means that the server can not function as intended. It can be tricky to solve a 500 error.
A 500 error is usually:
To track down the cause of the 500 error:
A way to search your error logs is to use a SSH terminal to your web-server:
tail -f [path to logs]/[log file].log | grep [Your IP Address]
Take the code above and fill in the path to your log files, and the filenames of your logs. Then add your IP Address. When you are done push enter and you will see the most recent errors for your server logs. Use the information to help diagonse your server errors.
Every so often you need to move a WordPress site to another server, or folder. All it takes is a few steps:
Copyright © 2006-2013 Excalibur's Sheath is licensed under a Creative Commons Attribution-ShareAlike 3.0 United States License. 