Archive for the ‘Tips’ Category

WordPressGarage.com now on WPGarage.com, and how to move a domain with a 301 redirect on WordPress

Thursday, December 31st, 2009

About a year ago, a discussion arose in the WordPress community about third-party sites that use the word “WordPress” in their domain name. We posted our opinion on this issue since WP Garage has been running (until yesterday) on a domain with the word WordPress in it. We put WordPress in our domain to show our ever-growing love for WordPress,  but realized how important it is to the founders of WordPress that we take out their brand name, so yesterday we finally moved this blog to WPGarage.com instead. Come on over and take a look.

During the process, we had to do a 301 redirect from WordPressGarage.com to WPGarage.com in order to retain traffic from inbound links and search engines. It’s important in this type of situation to do a 301 permanent redirect so that all of the new pages on the new site are seen by the search engines as equivalent in terms of value and ranking as the old site.

We followed Yoast’s guide for how to Move your WordPress blog to a new domain in 10 steps! which was very helpful. However, along the way, we realized that there are a few things in his directions that might not be clear to readers (they weren’t so clear to us at times), so here are some things to pay attention to when doing a 301 redirect for a WordPress blog:

  1. Put the robots.txt on the new domain.
  2. Copy the database and files to the new domain.
  3. Edit wp-config.php on the new domain to have the right database settings as described by Yoast.
  4. Now set up your new blog install, with the same settings as on the old domain. If you import the database it will retain pretty much all of your settings from the old site.
  5. The Search and Replace plugin for replacing instances of your old URL with the new one across your database works great.
  6. This step is fine.
  7. Yoast says to remove the robots.txt file. We left it but removed the slash after the word Disallow.
  8. The code Joost gives to put in your .htaccess file refers to a site moving from a sub-directory on one domain to a the root directory on another domain. It might not be clear what you need to use if you’re moving from the root directory of one domain to the root directory of another. So, on your old blog, add one of the the following lines to your apache .htaccess or vhost-config:
    Redirect 301 /blog/ http://www.newdomain.com/
    This is if you're moving from domain.com/blog to domain.com
    OR
    Redirect 301 / http://www.newdomain.com/
    This is if you're moving from olddomain.com to newdomain.com
  9. IMPORTANT NOTE: Don’t underestimate the importance of the slash and spacing. In Yoast’s example, we took out the entire /blog/ part of the line and the old site would only forward to the homepage of the new site. Luckily, we found this article which showed the importance of the slash placement.

    WordPressGarage htaccess code

  10. Joost says to remove the old blog and database. I’m not sure if I would do that so quickly.
  11. Change your FeedBurner account, if you have one, to pick up the correct feed and continue delivering it to subscribers..
    Note: You can only change the Feed Title and Original Feed. You can’t change or “redirect” the Feed Address itself.Feedburner for WPGarage

Test it out and hope Google figures things out and displays your new site in the serps.

Update: After moving the site to the new domain, a few issues arose and were eventually solved, including issues related to Google Webmaster Tools, Google Analytics, and more. Read More on doing a 301 redirect of a WordPress site to a new domain for more info.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

New WordPress mailing list for asking and answering WordPress development questions

Tuesday, July 21st, 2009

Where can you go if you have questions about developing and managing a WordPress site? Well, we all know about the WordPress Forums, which can be a useful resource for getting experts and WordPress staff to answer your questions.

However, not everybody is a fan of the forum format – including me. You have to remember to check back (yes, I know there are RSS feeds, but I don’t even go into my RSS reader on a daily basis anymore), and only people who keep an eye on new topics see your questions.

My experience is that mailing lists work great since everybody on the list sees the emails, and good conversations can ensue. Also, users are encouraged to answer questions because it gives them the opportunity to showcase their expertise.

Apparently, there are quite a lot of people who prefer mailing lists, and over the last year or so the WP-Pro mailing list has been getting quite a lot of posts about how to do certain things with WordPress. That would be great if the purpose of the list was for community support – but it’s not! The WP-Pro list is for people who are searching for WordPress service providers to work with, i.e. if you want to pay someone to fix/build/advise your WordPress project, that’s the place to go. If you want to know what the best WordPress SEO plugin is…well, the only place to turn to was the forum.

WP Garage Mailing List – An Online/Email WordPress Community

Not any more! I have set up a mailing list/email group called WP Garage (well, I couldn’t think of another name!), for just these types of questions – if you are looking for plugins, code hacks, tips or just plain ol’ WordPress advice, this new list is for you! The goal is to provide an open and accepting place for WordPress users of all levels to ask and answer WordPress related questions. In the beginning, I will be moderating the posts to make sure no garbage gets through, but if I see that things are pretty clean I’ll ease up on the moderation.

So please come join us, either by clicking on this link or by entering your email address in the field below:

Subscribe to WP Garage Mailing List

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

How to set up Wordpress on a Wampserver

Monday, October 6th, 2008

Recently, someone asked me how to set up a local Wamp server on their computer so they can test Wordpress sites locally before uploading and editing online. MakeUseOf nicely explained what a Wamp server is and how to set it up. I wanted to expand their explanation to include setting up Wordpress.

What is this Wamp business?

According to MakeUseOf, WAMP stands for Windows Apache, MySQL and PHP.

A great majority of websites are run by a trio of services – Apache, MySQL and PHP. Apache is the web server, which handles browser requests and sends the information across the internet to your browser. PHP is the programming language that many sites are written in – this creates dynamic content which in turn is sent to Apache, which sends the data to your browser. And finally, MySQL is the database which stores the information for programs. PHP is used to access this database.

How to Set up a Wamp Server

Step 1

Download the WampServer.

Step 2

Run the installer, using the default options provided.

Step 3

Double click the Wamp icon on your desktop .

On your taskbar, near the time in the bottom right corner of your desktop, left click on the semicircle button and Click “Put online”.

How to set up Wordpress on your Wamp

Step 1

Download Wordpress. Extract the files.

Left click on the semicircle on your taskbar.

Open up the www directory.

Drag the Wordpress folder into the www directory.

Step 2

1.  Open PHPmyadmin from your wamp menu

2. Create a new Database (‘wordpress‘ or ‘blog‘ are good). Leave Collation. Click Create.

3.  Click the Home icon in the upper left to return to the main page, then click Privileges. If a user relating to WordPress does not already exist in the list of users, create one:

  1. Click Add a new User.
  2. Chose a username for WordPress (‘admin’ is good) and enter it in the User name field. (Be sure Use text field: is selected from the dropdown.)
  3. For Host, select Local and type in localhost
  4. Choose a difficult-to-guess password and enter it in the Password field. (Be sure Use text field: is selected from the dropdown.) Re-enter the password in the Re-type field.
  5. Write down the username and password you chose.
  6. Leave all options under Global privileges at their defaults.
  7. Click Go.

4. Return to the Privileges screen and click the Check privileges icon on the user you’ve just created for WordPress. In the Database-specific privileges section, select the database you’ve just created for WordPress under the Add privileges to the following database dropdown. The page will refresh with privileges for that database. Click Check All to select all privileges, and click Go.

5. On the resulting page, make note of the host name listed after Server: at the top of the page. (This will usually be localhost.)

6. Returning to where you extracted the WordPress package, rename the file wp-config-sample.php to wp-config.php.

7. Open the renamed wp-config.php file in your favorite text editor. Here’s a screenshot of how the wp-config.php is set up.

8. Fill in the following information

DB_NAME
The name of the database you created for WordPress. (ex. Wordpress)
DB_USER
The username you created for WordPress (ex. admin)
DB_PASSWORD
The password you chose for the WordPress username.
DB_HOST
The hostname you determined  (usually localhost)

9. Save the file.

10.  Run the install scrip by copying and pasting this URL into your browser http://localhost/wordpress/wp-admin/install.php

Step 3

Hooray! Hopefully all went according to plan.

Treat yourself to a nice cold beer.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

6 things to remember when moving WordPress blogs to a different host

Tuesday, July 8th, 2008

I recently had to move all my WordPress sites and blogs to a new server because Bluehost sucks. My sites were going down on a near-daily basis for way too long, and they couldn’t care less. So I did what I really did not want to do, and moved six WordPress sites to a new hosting provider, which has proven itself with my clients’ sites: Hostgator. And along the way I’ve learned quite a few things about what to pay attention to when moving WordPress sites from one place to another, which I’d like to share.

Lesson 1: WordPress’ native XML export is not good enough

In WordPress, you can easily export a site by going to Manage > Export, which will create a unique XML file that you can import in any new site. This is fine for a very simple, single-user blog without heavy customizations. However, if your blog has multiple users, and if you have added info to their profiles, that info will be lost in this export. In addition, all users will be given a permission level of Subscriber, which is annoying if you need to go and change everyone back to their original permission level.

Also, if you have installed plugins that created new tables in your database, these will not be exported.

And, if you had any links saved, this will not save your links. See Lesson 6 below for more information on this, but the point is that the only way to save your links AND their categories is to export your entire database.

Therefore, in order to retain all settings and information that your site needs, the only way to do so is to export your entire database, and then import it to the new WordPress installation.

Exporting and Importing a WordPress blog

Here’s how you export and import your WordPress database. WARNING: Messing with databases in PHPMyAdmin can be hazardous to your health and to the health of your site. One wrong move and everything will be but a distant memory. So make sure to backup like crazy; and I take no responsibility for any harm you may come to by following my instructions. Now, let us begin:

  1. Log in to PHPMyAdmin via your control panel or however else you log in.
  2. If you have multiple WordPress blogs on one server, you may see a list of databases in the left-hand sidebar. Make sure you are dealing with the right database. The way that I check which database is the right one is by browsing the database and viewing the information there, whether it’s posts or even meta data like the blog name. To browse, click on the browse icon next to a table’s name (Note: your PHPMyAdmin interface may look a bit different, depending on the version you are using):
    Browse database tables in PHPMyAdmin
  3. Once you are sure you are in the right database, click on Export at the top of the PHPMyAdmin toolbar:
    Export database in PHPMyAdmin
  4. On the Export screen, I usually leave all the settings as is, but I do make sure to to 2 exports: a compressed (gzip) export, and a regular export, just in case. So export one while selecting None, as shown below, and one while selecting gzipped:
    Compress export file in PHPMyAdmin
  5. Now on to importing: install WordPress on your new server.
  6. Go in to PHPMyAdmin for your new server, and delete all your tables for your new WordPress installation (Yikes!). In PHPMyAdmin, to delete is called to “drop.” So on your main database page, select all your tables and click on Drop, or on the red Xs next to the table names:
    Drop tables in PHPMyAdmin
  7. Now, import your exported WordPress database into your new installation. To do that, stay in PHPMyAdmin for your new site, and click on the Import tab that is to the right of the Export tab on the toolbar (see image in step 3 above).
  8. Browse to find your exported database file. Leave the rest of the settings, and click Go.
  9. Now your old WordPress database is in your new installation. It may work at this point, so go check. If it does, great. If not, continue reading.
  10. You need to make sure that your database table names work with the new installation of WordPress. This means the following: if you installed your old database with Fantastico, all your database tables have a prefix of wp_. If you didn’t install it with Fantastico, the database tables probably don’t have a prefix. Your new database tables may have a different naming convention depending on how you installed it. So, take a look at your database table names, and note if they start with wp_ or not. Now it is time to open wp-config.php.
  11. Once you have opened wp-config.php, look at line 16, which says something like this:
    $table_prefix = ‘wp_’;
    If your database tables start with the wp_ prefix, leave the line as above. If they don’t have a prefix, change it to:
  12. $table_prefix = ”;

Now your blog should mostly work (I hope)! But there are a few more things that we need to take care of:

Lesson 2: Widgets are not preserved with an XML backup, even with a full database backup

If you are using widgets somewhere in your blog, you will have to redo them one by one on your new blog if you use the XML backup. So take out a pencil and paper, and write down exactly what widgets you are using, what order they’re in, and any modifications or customizations that you made to them. Ok, you can use Word or Notepad if you want, but that’s about as technologically friendly as you can get.

Lesson 3: In addition to backing up your theme and plugins folder, remember your Uploads folder!

In your blog under Settings > Miscellaneous, you have set where any uploaded files or images will be stored. Make sure to backup that folder, in addition to your theme and plugins folder, so that you will have all those files in your new blog. In your new blog, go to Settings > Miscellaneous and make sure it’s pointing to that re-uploaded Uploads folder.

Lesson 4: Make a note of your site’s permalink structure

You want to retain the same permalink structure for your new site so that you can continue to enjoy the same traffic you had before from search engines and incoming links. So make note of your permalink structure, and once your new blog is installed, make sure to go to Settings > Permalinks, and set the same structure there.

Lesson 5: Don’t forget your favicon

Your favicon can get lost in the shuffle. Make sure to back it up, and upload it to your new site.

Lesson 6: It is hard to preserve WordPress blogroll links and their categories

Here at WordPress Garage, I had a page until recently called “Links we Love.” I had painstakingly added, categorized and described many links that I thought were useful to my readers. Well, during the whole server move, the links got lost because we didn’t export them by going to http://wpgarage.com/wp-links-opml.php, and saving that OPML file as a text file for importing later. In any case, even if I had saved that and imported it here, I would have lost all my categories anyway. So just note that if you’re depending on the XML backup, you will lose all your links. If you back up your links with the OPML file, you will lose your categories.

——————-

To sum up: try not to ever have to move your WordPress blog from one server to another, and you will add years on to your life.

Happy blogging!

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Social Proof: Increase subscribers to your blog by displaying your feed stats

Thursday, June 12th, 2008

Last night I attended MashBash Tel Aviv, an intimate gathering of Mashable’s Adam Hirsch and 800 of his closest friends from the Israeli hi-tech industry. In between having fun and getting served free drinks for three hours, I managed to learn something new. I learned about “social proof.”

Social what?

I met a guy at the event who I “knew” through twitter. Harry runs a snazzy new website about Jerusalem attractions and other stuff. We were discussing the right steps to take to increase blog traffic, and how he’s managed to get really decent traffic to his site in a relatively short period of time. He mentioned one tip that I had never heard before in all my blogging years, and it struck me as so simple yet so smart.

Social Proof.

Harry said that once you have at least 50 RSS subscribers, you should display the number of subscribers on your blog to encourage others to subscribe as well. The reason is that people like to try out things that lots of other people like. Think of a restaurant or cafe – if you’re walking down a street of cafes, would you rather go into the empty cafe, or the one overflowing with patrons? When lots of people patronize something, by showing up, subscribing, or in other ways, it encourages others to join as well.

(Harry learned this tip from Yaro Starak’s Blog Mastermind Course, which actually sounds like it might be worth the investment from what he says.)

So take a look over to your right here. See that little feed reader thingy? As you can see, WordPress Garage has 781 subscribers. We’re a really cool crowd, having lots of fun. Doesn’t that make you want to subscribe too?

You can subscribe to the feed, or via email in the sidebar.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Get to know every line of your comments.php WordPress theme file

Tuesday, June 3rd, 2008

There is one WordPress theme file that I almost never touch when working on a theme: comments.php. I usually style WordPress comments via the CSS sheet, and that’s that.

Well, there’s a lot you can do to customize and extend WordPress comments if you just know how. Nettuts has published a comprehensive tutorial on how the comments.php file works, and what every line of code does. The tutorial also explains how to add extra goodies to your comments, like Gravatars, comment numbers, comment links, alternating colors (which we’ve discussed here), displaying the HTML tags users can use in the comments text box, and displaying a link to the comments RSS feed. The tutorial did not discuss how to give each comment its own link, a tip that I find particularly handy for referring to specific comments.

Check out this tutorial if you want to strengthen your relationship with your WordPress comments.

Unraveling the Secrets of WordPress’ Comments.php File

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

38 ways to optimize and speed up your WordPress blog

Wednesday, April 23rd, 2008

WordPress blogs and sites can be notoriously slow. But fear not – here are ways to make your WordPress blog super speedy and fun for your visitors to view with a few tweaks, hacks and plugins. Be sure to check back because I will be updating this post as I discover new and wonderful ways to optimize and speed up WordPress blogs.

Matzah[This post is in honor of the current Pessach (Passover) season, a Jewish holiday where we clean our houses frantically in the hope that not one crumb of leavened bread (i.e. regular bread) be found during the 7 day holiday. This post is the WordPress version of Pessach cleaning, where cluttered databases are equivalent to leavened bread, etc. Happy Pessach!]

Define goals and create benchmarks:

  1. First, define a goal, such as reducing page load time from 8 seconds to 2 seconds.
  2. Measure your initial state and the results of each modification so that you can quantify any improvement. Test your site’s speed with the Website Speed Test, but do multiple tests since the results can be inaccurate due to fluctuations in your internet connection and other factors.
  3. Use Pingdom to get a detailed analysis of your blog’s loading time and performance.
  4. See what your browser is doing with tools like Firebug’s network tool, Charles Proxy or Wireshark, and review the server logs.
  5. YSlow – analyzes web pages and tells you why they’re slow based on the rules for high performance web sites. YSlow is a Firefox add-on integrated with Firebug. See this presentation from Yahoo! that covers their latest research results and performance breakthroughs. It covers their existing 14 rules, plus 20 new rules for faster web pages. They’ve categorized the optimizations into: server, content, cookie, JavaScript, CSS, images, and mobile.

     

    SlideShare | View | Upload your own

Reduce the number of dynamic PHP and http calls:

  1. “There is an inherent overhead in each HTTP request. It takes substantially less time to serve one 30K file than it does three 10K files.” So combine all files in a type into a library. Learn how here.
  2. Use different host names to increase the number of active download threads.
  3. Minimize PHP and database queries – Each time a page on your site loads, if your browser has to execute any PHP queries, it adds to the load time. If you replace the PHP queries with static HTML, every time a page loads, your browser just reads the HTML. An example from WP Candy:
    With PHP requests: <title><?php bloginfo(’name’); ?><?php bloginfo(’description’); ?></title>
    Without PHP requests: <title>WPCandy - The Best of WordPress</title>
    Joost de Valk says that you can remove 11 queries to the database by doing the following in your header.php and footer.php files:

    • making your stylesheet URL’s static
    • making your pingback URL static
    • making your feed URLs static
    • removing the blog’s WordPress version
    • making your blog’s name and tagline / description staticSee more examples of how you can replace code in your WordPress template files with static HTML here and here.
  4. Check if you have too many external calls to things like Amazon, eBay, MyBlogLog, etc. Try commenting them out one by one to see if it speeds things up.

Optimize your files: CSS, HTML, Javascript, images, video

  1. Optimize your image files for the web.
  2. Make sure that all images have height and width tags.
  3. Consider hosting your images on an external site like flickr that has huge servers and can handle the load.
  4. Use CSS sprites for static web images. CSS sprites are where the images are added to one larger image file, and laid out in a convenient way. Here’s a CSS Sprites generator.
  5. Do not host videos on your server. Upload them to YouTube, Google Video, or any other video sharing site and let them handle the server load.
  6. Compress your Javascript, using a tool or by removing formatting (and potentially by shortening function and variable names). This can reduce file size by 60%. Add gzip compression to that as well and you’re looking at a serious size reduction.
  7. Compress HTML and CSS by removing HTML formatting, white space (where you divide code among separate lines for easier readability), trimming class names, omitting unambiguous quotes around attributes, etc.
  8. Compress your CSS with the CSS Compress WordPress plugin – Automatically removes comments, new lines, tabs, and gzip compresses (GZIP) any CSS file called with “<?php bloginfo(’stylesheet_url’); ?>” Just activating the plugin with the default Kubrick theme will reduce the CSS file from 8k to 1.7k.
  9. Compress your CSS by using shorthand CSS. Here’s an example from WP Candy:
    Long: .test {margin-top: 7px; margin-right: 1px; margin-bottom: 5px; margin-left: 3px;}
    Short: .test {margin: 7px 1px 5px 3px;}
  10. Use external scripts – Instead of placing tons of code in your header.php file, use external scripts. This allows the browser to cache the script so it won’t have to read it for every other page.
  11. Validate your code at W3C to make sure you don’t have any major errors slowing down your page.
  12. Allow progressive rendering: Load CSS files at the top of the page, from within the head section; load JavaScript files at the bottom of the HTML. And/Or…
  13. Stop slow loading scripts from breaking your blog with IFrameWidgets v1.0 WordPress plugin. Slow widgets or snippets of Javascript can either time-out, or prevent the items below them from loading. The plugin creates WordPress sidebar widgets that run in an IFrame. Since IFrames load in parallel to the rest of the page, slow loading JavaScript widgets won’t affect the rest of the page.

Plugins

  1. Disable or delete unused plugins – some plugins have tons of script and code, and even create database tables in your WordPress database. Use only the plugins you really need, and delete the rest.
  2. Sometimes plugins require that you add a snippet of code to your theme’s template files to call the plugin. Usually, it looks something like this:
    < ?php refer_plugin(); ?>
    However, if for some reason you disable that plugin, you will get an error. Joost de Valk recommends using PHP’s special function called function_exists to prevent the blog from breaking if plugins are disabled or removed. Using it will make the code look like this:
    < ?php if (function_exists(‘refer_thanks’)) { refer_thanks(); } ?>
  3. Control when your WordPress plugins are loaded: WordPress processes all of the code for all active plugins, even if that plugin isn’t used on a particular page. If a particular resource heavy plugin isn’t used on certain pages, then you can tell WordPress not to load it on those pages by wrapping an if statement around the content of each function to check what page is being loaded. Learn more about how to do this here and here.

Database

  1. Use phpMyAdmin to optimize your database: Log in to phpMyAdmin, select all the tables, and then “repair” and “optimize.”
  2. Delete excess records in your WordPress database. All plugins use the wp_options table to store data, which is the same table used by WordPress to store all settings for your blog, and is accessed every time you open any page. When you deactivate a plugin, these records are left behind, bloating your database. To clean it up you can use the WordPress Clean Options Plugin, which finds orphaned options left after you have removed plugins and removes them from the wp_options table, or manually as follows: Back up your database, login to phpMyAdmin, open your blog’s database, and click on browser for the wp_options table. Go through this table record by record to identify any records left behind by old plugins. (from WordPress Web 2.0 Spot-Er).
  3. Use the Optimize DB plugin to optimize the tables of your database.
  4. Use WordPress Plugin: Fix Database to check all tables in your database and fix any errors.
  5. Lester “GaMerZ” Chan’s WP-DBManager 2.11 plugin sorts your database backup files by date in descending order, can repair databases, and allows automatic scheduling of database backups and optimization.

Caching and protecting for server overload

  1. WordPress has a built-in caching system. Learn how to enable the default WordPress object cache. This has apparently been disabled in version 2.5.
  2. WP-Cache 2 – caches Worpress pages and stores them in a static file for serving future requests directly from the file rather than loading and compiling the whole PHP code and then building the page from the database.
  3. WP Super Cache – This plugin is a fork of the WP-Cache 2 plugin, and generates html files which are served without ever invoking a single line of PHP.
  4. PHP Speedy – PHP Speedy is a script that you can install on your web server to automatically speed up the download time of your web pages.
  5. Use the Expires and cache-control max age headers for all pages; Make dynamic pages support the if-modified-since request header; Use far future expiry headers on static resources; Use the cacheability engine to test that you have caching and validation set up correctly. If you don’t know what all this means, don’t worry, neither do I, but you can find out more here.
  6. Digg Protector plugin – The Digg Protector will determine if a visitor is from Digg, and if the visitor is indeed from Digg, the plugin will serve them a remotely-hosted version of the image. Otherwise, the plugin will serve the locally-hosted (on that server) image.
  7. Some more caching possibilities: MySQL query cache, PHP Compiler Cache. Learn more here.
  8. Configure Apache for maximum performance.

Happy Optimization!

Sources:

Speed up your website: Part One

How-to: Optimize your site for speed – really excellent article with practical tips

How to Enable the Default WordPress Object Cache – talks about wp-cache, wp-cache 2, and built in wordpress caching.

Digg Protector

4 Simple Ways To Speed Up WordPress

Speed up and clean up your WordPress!

5 Tips to Help Your Slow or Sluggish Blog or Web Site (Wordpress Especially)

Deleting excess records in your WordPress database

WordPress on Speed: 17 Tweaks to Accelerate your WP

The 3 Easiest Ways to Speed Up WordPress

WordPress Theme Hacks

Diggproof & Speed up Your Wordpress Blog

WordPress Optimisation: Control When Plugins Are Loaded

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

4 reasons not to host your blog on WordPress.com

Tuesday, April 15th, 2008

When starting out, many bloggers seek out the cheap and easy route, either choosing to blog on Blogger, WordPress.com, or another free and hosted blogging platform. This approach makes sense, since a person can never know until they’ve started if they even like blogging, let alone whether they’ll be successful.I almost always suggest to beginner bloggers to set up a blog on WordPress.com, but the reason is not because I think this is ideal, but because it is easiest to migrate a blog from WordPress.com to a self-hosted WordPress.org site, which is ideal (as opposed to migrating from Blogger, which can be a nightmare). One of the reasons it’s so easy is because you can select the same permalink structure as in your original WP.com blog, and just change the main domain name part in a 301 redirect. Also, by using WP.com, you will become familiar with the WordPress system and interface, which is similar in the self-hosted WordPress.org version.

Why am I against WordPress.com?

I am not against WordPress.com. I think it’s a great service, and the quality of the features is unmatched in any of the other free hosted blogging platforms. In addition, people in the SEO industry have told me that due to the strength of the WordPress.com network, blogs that are hosted there do incredibly well in the SERPs. But if a person wants to take up blogging as a serious activity, or finds that their WordPress.com blog is growing, I suggest that they move their blog off of WP.com to their own self-hosted blog. Here is why:

  1. Limited blog design flexibility – whenever I’ve tried to use a WordPress.com blog, I’ve always found myself stuck at some point because I can’t add certain features. Users are limited on WP.com by the amount of customization they can do to the CSS, even if they pay for extra access to the CSS. They also can’t customize the loop, and the sidebars can only be modified to the extent that widgets allow. Also, WP.com users can’t add WordPress plugins, which is one of the keys to expanding your blog’s features.
  2. You don’t control your content – as soon as you are using a service that is hosted by someone else, you have lost partial ownership over your content. I’m not talking about what exactly it says in the WP.com terms of service (we’ll get to that soon), but I am talking about the issue of your content sitting on someone else’s servers. I personally prefer to try to keep my content under one roof – my own. As for the WP.com Terms of Service – you are at the mercy of their discretion as to whether your content is appropriate. When hosting your content on someone else’s servers, you are always at risk that someone may decide that your content is inappropriate, and they can easily shut you down.
  3. Hosting quality issues may haunt you – if the WP.com servers are having trouble, like the recent DoS attack on the WordPress.com servers, you will suffer. Of course, that is the case on all servers, but if you are really unhappy with a service provider, you can call them up, complain, and always change servers if need be. When your blog is on WP.com, it’s not as easy.
  4. You are at risk of being censored in certain countries – upon finding content that they don’t like on WP.com, certain countries with undemocratic tendencies will simply block the entire system. While it is possible for them to just block the individual WP.com blogs that they find offensive, these countries either don’t care enough to try, or are happy to block an entire blogging universe since blogging is all about free speech, and they are not. Countries that have blocked WordPress.com are Turkey, China and Brazil.

WordPress.com is a great service, and the people providing it are incredibly generous. However, like any other free hosted service, it has its drawbacks which should be taken into account when deciding on which path to take for your blog: free hosted or paid and self-hosted.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Stylish Firefox add-on plus Google Redesigned equals pretty Gmail

Wednesday, April 2nd, 2008

I know that Gmail and Firefox don’t really have anything to do with WordPress, but I decided to write about them anyways because:

  1. I have nothing earth-shattering to say about WordPress right now. Everyone else is talking about version 2.5, and I still haven’t installed it (my bad) so I don’t have anything to add to the conversation.
  2. I would guess that most WP users are Firefox fans and probably Gmail fans too, so…so nothing. That’s not a very good argument, so I’ll stop right here.

ANYWAYS, Gmail is ugly. The interface is so eye-poppingly cluttered and unimaginative that this is actually one of the reasons I haven’t really gotten into Gmail. I just found it hard to get my eyes used to.

Well, now there’s a solution! There is a cool Firefox add-on called Stylish, that lets you define custom styles for any page on the web. For example, if you didn’t like the brown on WordPress Garage and prefer a nice shade of magenta, you could use Stylish and define a new CSS style that will make all text on this site magenta. Basically, as they say on the Gmail Redesigned page, “Stylish is to CSS what Greasemonkey is to JavaScript.”

ANYWAYS, the people at Globex Designs have created a special Stylish style for Gmail – Gmail Redesigned. They have taken the over 1500 (!!) styles and very complicated structure of Gmail and redesigned it. They are updating the styles almost daily, and if you’ve already installed Gmail Redesigned and you visit their site, it will tell you if any updates have been made since your last install and you can update with one click.

I installed it, and I can tell you it makes a world of difference. Gmail is now…pretty. Pretty Gmail is no longer an oxymoron.

Gmail Redesigned says it currently only supports English, but Hebrew worked for me too, and is not supported with the “Better Gmail 2″ or the “Remember The Milk” extensions. Support for these extensions will be added in the future.

And now, a partial screenshot of my Gmail account with all incriminating evidence either archived or painted over (hopefully):

Redesigned Gmail makes Gmail pretty

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Plugins and hacks for improving the WordPress TinyMCE editor

Monday, March 24th, 2008

The WordPress TinyMCE editor mercilessly strips tags at will. Some will tell you that in order to avoid this problem you should disable the visual editor, but this is not a realistic solution since a. Many people feel more comfortable using a visual editor and b. The editor should not remove code from the coding editor, period.

This problem is becoming even more acute with the proliferation of embeddable services available on the web for easily sharing rich content like videos, slideshows, and documents. In order to display these services on your blog, you need to embed the code within your post, but doing so will often break your blog layout since the divs are stripped.

There are many topics on the WordPress forum related to this issue, none of which have been resolved satisfactorily. The question is – do the folks behind WordPress have any intention of fixing this problem?

How to fix it

A few days ago I wrote about a way to make the WordPress TinyMCE text editor stop stripping div tags. The original code that I wrote didn’t work, but I subsequently found a solution that I tested and did work, and have since corrected the original post.

While I was searching for a way to get the hack to work, I found a bunch of other hacks and plugins that help you force the WordPress editor to stop stripping tags, or show you how to customize the editor. So here are some other options you may find useful:

Plugins:

  1. TinyMCE Advanced – Among the many things this plugin does, it says it supports XHTML specific tags and (div based) layers. This may mean that it doesn’t strip div tags.
  2. Disable wpautop Plugin – This plugin disables the WordPress wpautop function. The wpautop function changes double line-breaks in the text into HTML paragraphs (<p>...</p>), and this plugin disables that annoying feature.

Hacks:

  1. To stop the WordPress editor from stripping out div tags, replace line 25 in the wp-includes/js/tinymce/plugins/tiny_mce_config.php file with the following: $valid_elements = ‘#p[*],-div[*],-strong/-b[*],-em/-i[*],-font[*],-ul[*],-ol[*],-li[*],*[*]‘;
    (This method was described in my previous post on this subject.)
  2. To stop the editor from removing line breaks, open wp-includes/formatting.php, and change line 402 to this: $content = str_replace('<br />', '<br clear="all" />', $content);. Alternately, you can use <br clear=”none”/>.
  3. To get the advanced toolbar functions to open by default, instead of needing to click on the Show/Hide Advanced Toolbar button, open wp-includes/js/tinymce/tiny_mce_config.php and change line 34 to read $mce_buttons_2 = apply_filters('mce_buttons_2', array('formatselect', 'underline', 'justifyfull', 'fontselect', 'separator', 'pastetext', 'pasteword', 'separator', 'removeformat', 'cleanup', 'separator', 'charmap', 'separator', 'undo', 'redo')); (via 1000 Miles or Bust)

That’s it for now. I’ll probably update this post as I find more information on hacking the TinyMCE editor.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]
Premium News Themes