Blog of Leonid Mamchenkov

When talking about what else WordPress could be used for except blogs, classified ads directories come up high on the list.  It’s one of those examples which illustrate the scenario nicely and doesn’t require a lot of work.

So, how can WordPress be used to build a classified ads directory?  Here is a list of a few ways you might go:

1. Buy and install ClassiPress – a theme and plugin to do just that – build a classified ads directory.  This is probably the fastest, cheapest, and simplest option.  If you want one of those directories up and running within a few minutes, that’s the way to go.
2. Install wp-classified plugin and tweak it until you are happy.  You’ll pay with your time, not your money.  And you won’t have to start from scratch.
3. Build your own, from scratch.  This is suitable for those who want to have 100% understanding of how their directory works, and for those who want learn how WordPress can be customized beyond blogging.

In this post, I’ll focus only on the third option.

[Read the rest of this entry...]

There are a numerous blog posts and forum discussion about WordPress.  However you can read all of them back and forward and still not know how the system works.  If you seek the real understanding of WordPress, there are two and two things only that you need to go through : its database scheme and its source code files.  And it’s not as hard as it might seem.

While you can download WordPress source code and go through each file using your preferred text editor or programming IDE, that might not be the best of fastest way to learn it.  Instead, I’d recommend a web-based interface available at PHPXref.com .  It might not necessarily have the latest version of WordPress, but usually it’s not that far behind.  For example, it currently features WordPress 2.7, with WordPress 2.8.1 being the latest version available for download.

WordPress at PHPXref.com

The coolest things about such an interface are syntax highlighting and cross-reference within WordPress source code, as well as links to PHP manual for native functions.

WordPress database scheme (ERD)

As for the database, you have three things going for you here.  Firstly, WordPress database scheme is very small, simple and straightforward. It’s only 10 tables with just a few fields each.  Secondly, it’s very well documented.  And thirdly, when you do a fresh installation of WordPress, you have some sample data in your database, which helps to understand what goes where.  You’ll find one post and one page (to see the difference), one comment (to see how those are linked to posts), one category, one user, and a few links in the blogroll.  Just inspecting that fresh database will clear up your head and sort things out.

Spending a few minutes going through the source code and understanding the database scheme is very worth it.  Firstly, you’ll better understand what WordPress can and cannot do.  Secondly, you’ll get inspired (that I can pretty much guarantee you).  Thirdly, you will automatically get the understanding of how almost each and every WordPress plugin works.  Not in details, but you’ll be able to reverse engineer them in your head easily.  And fourthly, you’ll become much more efficient with WordPress customizations – you’ll just know where to put things and how to better change stuff.

Check out this poll for media-related features for the upcoming WordPress 2.9.  This is your chance to influence the priorities.  Features on the menu are:

• Additional Media Filters, which would help you pick media that was used recently, or more often, or is your favourite, etc.  I don’t find it very important for my usage scenarios, because I rarely re-use media files in other posts.
• Basic Image Editing, which will allow things like crop, rotate, and resize.  Even though I can use standalone image editors, I know of quite a few non-technical people who would appreciate basic image controls.
• Better Media Settings, which will provide more defaults and more options to change for each upload.  I have enough options for my media usage already, so I don’t find this to be of high importance.
• Bulk Media Import API, which will be appreciated by web development companies and such.  Anything that helps automation and bulk processing is A Good Thing.  Also, with more attention to media functionality in WordPress, I suspect some people would prefer to host their own images and videos, rather than to use third-party services (YouTube, Flickr, and such).  Moving all that content into WordPress with API is a dream come true.
• Custom Image Sizes, which will allow for more and truly customized image sizes.  While I can understand the importance of this for some people, I suspect that most are satisfied with what is there now.   Plus there is a range of plugins, and workarounds available that make this problem of less importance.
• Easier Embeds, for content coming from third-party services like Flickr, YouTube, and such.  This is something I’d really love to see done.  Currently, there are plugins to cover most cases, but I believe a built-in way is in order.  Plus plugins often miss important parts of the site, such as feeds.  And plugins rarely work well with other plugins.  If this functionality is in the core, or in a plugin, which is a part of main download, extending and re-using such functionality would be easier.
• Media albums, as in standalone galleries, rather than media galleries attached to a post.  That’s something that a lot of people would find useful.  For example, bringing all YouTube videos from all your posts into a single gallery would be awesome.
• Media metadata, which is adding categories and tags to media files.  Well, while it sounds cool, I think it will add more confusion to people.  With such functionality, WordPress will become more of a generic content management system.  For example, together with media albums, you’d be able to use WordPress as a pure image gallery application.
• Post thumbnails, which would associate an image with your post.  I think this functionality is only useful to a small bunch of people, and it is currently available via plugins.  I don’t think it’s worth putting it in the core.
• Revised Media User Interface, which would improve the experience in the media editor.  I don’t know how many people find it difficult to use actually, because it works like a charm for me, and I find it easy to explain to non-technical users as well.  But if there are ideas on how it could be much improved, then why not.

If you have any opinions on the above, please vote in the poll first, and then share them in the comments second.

One of the coolest things about WordPress is a dynamic sidebar. Dynamic sidebar is a special are defined by a WordPress theme, where widgets (blogroll links, recent comments, related posts, etc.) can go.  The beauty of it is how simple it is for the theme author to define and style such an area, and how simple it is for the theme user to configure which widgets go where.  One line of code for the theme designer, and a user-friendly administration interface with drag-and-drop support for the end user.

As simple as it is, I’ve seen it abused by theme authors one too many times.  Consider an example (borrowed from a really nice theme in the wild, which I won’t name):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

 
 
 
 
 
 
        Categories
 
 
 
 
 
 
 

What happens here is the following: in line 3 we check if this version of WordPress supports dynamic sidebars (these were added in WordPress 2.2.0, if I remember correctly). If they are supported, we insert all widgets that were dragged and dropped into ‘east_sidebar’ dynamic sidebar, using WordPress administration.

Now for the tricky bit. If the function does not exist or something went wrong while displaying the widgets, we fall back onto some defaults. In this case we show the list of categories.

What’s so tricky about it? The trick bit about it is the return value of the dynamic_sidebar() function. It returns a boolean value. True if the sidebar was found and called, and false if sidebar was not found or was not called. This “was not called” actually means “failed to find at least one proper widget”.

What happens in practice is this. You find this nice theme that you want to use for your blog. You install and preview your site. Everything looks good. The sidebar looks good too, but you don’t particularly like the selection or the order of the widgets. So you go to the administration interface and what do you see there? An empty sidebar. Instinctively, you drag-and-drop a widget into the sidebar. Refresh your site and you see something totally unexpected. The sidebar that had a bunch of widgets now only has one – the one you drag-and-dropped. Weird.

That is because when you installed the theme, it registered a new sidebar, which is by default empty. When the sidebar of your site is displayed, dynamic_sidebar() function returns false and the theme falls back onto default widgets in the theme. Once you have at least one widget dropped into sidebar, that doesn’t happen any more and your lonely widget is displayed now.

That’s not a big problem with simple themes, which have only one or two dynamic sidebars. However, more complex themes with four, five, six, and more sidebars become annoying. Because there is usually some default pre-selection of widgets for each of those sidebars, and in case you don’t like it, you’ll need to do a lot of work in that administration.

Even worse, if you want to leave some of those sidebars empty. If there are defaults set in the theme, the only way for you to silence the sidebar is edit the theme source code. In the example above that would removing everything from line 4 to line 12. If you have more than one sidebar that you want to silent, you’ll need to repeat the procedure for every one of them.

So, what’s the solution? What’s the right way? To be honest, I don’t know. From the point of view of somewhat experienced end-user, I’d prefer no default widgets in the theme source code. Let them come up empty by default – I’ll drag-and-drop whatever I want using the user-friendly administration. On the other hand, from the point of view of non-experienced end-user, empty sidebars might confuse the heck out of me. I need to know about widgets to solve the problem, and unfortunately not all WordPress users do. Also, I guess it’s a bit harder for the theme authors to promote their themes if they come up with empty sidebars once installed.

One solution that might work is a theme option. Show default widgets by default, but allow to silence them all from the theme controls. That would work as a compromise and avoid unnecessary source code editing. Also, I think it would be pretty straight forward to implement (check for the value of the theme option instead of the return value of the dynamic_sidebar()).

What do you think?

Almost two years ago I wrote a blog post titled “A look inside the WordPress database“.  While a lot of people enjoyed it (and, apparently still do, even though it’s a bit outdated), I think it could be greatly simplified.  And it will probably take you less time to understand WordPress database now than it would take you to read through that blog post back then.

For the simplified approach to the WordPress database, you’ll need three things and three things only.

1. Database description – WordPress Codex page.  The main thing to pay attention to on that page is the database diagram.  If you can’t grasp it all at once – DON’T PANIC – there is a description of each table further down the same page.  But trust me, you don’t need that just yet.
2. Fresh installation of WordPress.  And by fresh I mean the one that you just did, complete with database setup and all, but which you haven’t touched yet – no options changed, no posts or pages published, no comments moderated.  Virgin WordPress.
3. MySQL client.  And you can use whatever suits your fancy.  Command line, PHPMyAdmin, MySQL Query Browser, or anything else.  The more comfortable you are with it, the better.

Have you got everything?  OK.  Now you’ll just need to use that MySQL client to see the tables in your fresh WordPress installation, the structure of those tables, and the content that they have.  If your memory fails you, here is a quick guide to MySQL.

List all tables in the database:

mysql> show tables;
+-----------------------+
| Tables_in_xxxxxxx_com |
+-----------------------+
| wp_comments           |
| wp_links              |
| wp_options            |
| wp_postmeta           |
| wp_posts              |
| wp_term_relationships |
| wp_term_taxonomy      |
| wp_terms              |
| wp_usermeta           |
| wp_users              |
+-----------------------+
10 rows in set (0.00 sec)

Show structure of the table:

mysql> explain wp_postmeta;
+------------+---------------------+------+-----+---------+----------------+
| Field      | Type                | Null | Key | Default | Extra          |
+------------+---------------------+------+-----+---------+----------------+
| meta_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| post_id    | bigint(20) unsigned | NO   | MUL | 0       |                |
| meta_key   | varchar(255)        | YES  | MUL | NULL    |                |
| meta_value | longtext            | YES  |     | NULL    |                |
+------------+---------------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

Select all records from the table:

mysql> select * from wp_terms;
+---------+---------------+---------------+------------+
| term_id | name          | slug          | term_group |
+---------+---------------+---------------+------------+
|       1 | Uncategorized | uncategorized |          0 |
|       2 | Blogroll      | blogroll      |          0 |
+---------+---------------+---------------+------------+
2 rows in set (0.00 sec)

Select a single record with a lot of fields for a close-up look:

mysql> select * from wp_links where link_id = 1\G
*************************** 1. row ***************************
         link_id: 1
        link_url: http://codex.wordpress.org/
       link_name: Documentation
      link_image:
     link_target:
link_description:
    link_visible: Y
      link_owner: 1
     link_rating: 0
    link_updated: 0000-00-00 00:00:00
        link_rel:
      link_notes:
        link_rss:
1 row in set (0.00 sec)

While you have just installed a brand new WordPress, you’ll notice that there is already a bunch of data in the database. That data consists of your configuration options, one post, one page, one comment, and a few blogroll links. You might not need all those for your other blogs, but now all of that plays an important role – it shows you were things are and how they are related.

Look into every table. Then change something. Edit a post or add another comment. Tag something. But don’t do everything at once – one step at a time. Check the data in the database after each step, and see how is it different from what you had there before you made a step.

10 minutes later you’ll know everything there is to know about WordPress database structure. Enjoy!

Weblog Tools Collection lists a few things to check for whether you are a WordPress geek.  Here is the list with bold items indicating the ones that are true for me.

1. When the first thing you do at a new blog is scroll down to see who did the theme.
2. When you mention Dexter Gordon, you have to qualify that he is a saxophonist and not the WordPress release.
3. More than one of your Twitter saved searches includes the word “wordpress”. (I don’t use saved searches, but if I was, I would have a few about wordpress for sure).
4. You read Weblog Tools Collection daily and have withdrawal when we do not have a release post.
5. You visit a well known publisher and can instantly recognize the permalinks as created by WordPress. Heck, if you know what a permalink is.
6. If all your vacations are to WordCamps. (Not all, no, but I once was at Greek Blogger Camp, which was practically the same thing).
7. If the word “dashboard” reminds you of the WordPress admin panel.
8. If you have multiple Google Alerts setup with the word “WordPress” in it. (I used to have it for some time, but now it’s just way too much to handle for me).
9. If your toddler has a “W” t shirt. (My toddler grew up faster than I ordered one).
10. If your browser homepage is set to the WordPress Planet.  (No, I don’t have it as a homepage, however I am subscribed to RSS and read through all posts. And I mark this one bold for actually having of my blogs on WordPress Planet)
11. If you bitch when Matt writes about the Kindle and not about WordPress. (No, I don’t bitch, but I definitely prefer WordPress posts).
12. If you have tried to convert your day job’s website to WordPress. (Yes, I did. Heck, I even had a couple of day jobs around WordPress)
13. If you know of Kubrick but do not know who he was. (I know the Kubrick theme and who Kubrick was, but only because I am into movies)
14. If you spend more time on WordPress Extend looking for plugins and themes than writing posts.
15. If you have ever met Matt and had a picture taken with him. (Here it is)
16. If you know what Akismet is. (Who doesn’t?)
17. If you met most of your friends because of WordPress. (All? No, I’m much older than WordPress. But I met a few, yes.)
18. If you make your living from WordPress. (Not any more, but I had a period like this in my life)
19. If your significant other complains that WordPress gets more attention. (Not any more, but I had a period like this in my life)
20. If you have ever suggested WordPress to others. (Suggested?  I basically push it down their throats.  Every time.)

This can go on forever, indeed.  Have you ever developed a WordPress plugin?  How about a theme?  A widget?  Have you used WordPress for a non-blog web site?  Have you ever used WordPress Mu? Blah blah blah.

And how about you?  Are you a WordPress geek?

If you still haven’t heard of, or haven’t made yourself one Gravatar – you are missing out.  Gravatar is a globally recognized avatar.  And avatar is the little picture that shows up on all those blogs and forums that you comment on.

The thing is that you can get bored of uploading your picture to each forum and blog that you want to participate in.   What  you can do instead – is create yourself a Gravatar account and upload your picture there.

How does it work?  Very simple.  When you create your Gravatar account, you specify your email address (don’t worry, they won’t sign you up for tonnes of SPAM).  After that, when you comment at someone’s blog and you specify your email address in that comment form, you’ll have your Gravatar picture displayed by your comment once submitted.  Provided three things are true:

1. You use the same email address in the comment form as the one you specified in your Gravatar account.  Because that’s how the blog will find your picture – by your email address.
2. The blog or forum that you are commenting at utilizes the Gravatar service.  Of course, every blog and forum is free to choose their own avatar source, but more and more blogs are supporting Gravatar.  That has something to do with WordPress being one of the most popular blogging applications out there, and Automattic, the company behind WordPress, buying Gravatar service and integrating its support into WordPress out of the box some time ago.
3. The picture that you have uploaded satisfies the age rating that the blog or forum requires.  People are free to upload all sorts of inappropriate images to their Gravatar accounts.  And that’s not what blog owners want to have displayed at their sites often.  So, there is a rating system which is used to specify how appropriate is your picture.

As for the picture itself, I suggest to use your own photo.  This makes your Gravatar unique – nobody will ever pick your picture for their Gravatar unless you are a celebrity or someone is madly in love with you.  And you’ll also recognize your own picture much faster when scrolling through a long discussion which you participated in.

The cool things about Gravatar are:

• it’s free
• it supports multiple email addresses (so if you have several identities on the web, you can manage them all from the same Gravatar account)
• it verifies your email address to make sure it’s you and not somebody else
• it’s integrated with WordPress out of the box and available as plugin for many other content management systems

What else are you waiting for?  Go get it!

Once in a while, especially when trying to explain a widely used technology to a non-technical person, I get this feeling that things could be done better.  And that’s exactly what happened recently while I was explaining tag clouds.

I know that there are plenty of variations on displaying and generating tag clouds – most used, most popular, recent, etc, etc, etc.  But what I realized is that a relevant tag cloud plugin is missing in WordPress.  Or, at least, is hard to find.

Many WordPress blogs these days are serving a particular niche, covering a specific topic. So, for them relevant tag clouds are not a  problem.  All tags are relevant, since they all share the same topic.  However, there are plenty of blogs which cover a wide variety of topics.

Take my blog for example.  I write about technology (tools, concepts, trends, etc.), movies, Cyprus, personal life, and lots of random bits about this and that.  I tag all my posts.  But the tag cloud is totally useless, because it shows all tags from all my posts.  And what good are the technology tags for the reader who scrolls through movie posts?

So, I think there is a need for a relevant tag cloud plugin.  I don’t know exactly how it should work and if it will work at all, but my ideas are the following:

• When on the front page of the blog (is_home()), tag cloud can show anything at all – most used, most recent, most popular, etc.
• When in the post or page (is_page() or is_post()), tag cloud should display tags which are used in all posts, that share tags with the current one.
• When in the category (is_category()), tag cloud should display all tags which are used in all posts that belong to this category.
• When in the archives (is_archive()), tag cloud should display all tags which are used in all posts within the archive time period.
• When in search results (is_search()), search term should be checked against existing tags, and if found ,then show all tags used in all posts tagged by the search term.  Alternatively, maybe, show a tag cloud for all tags used in the posts matching the search criteria.

I think such a tag cloud would be way more useful, especially for blogs that cover multiple topics.  Especially, if the extra database load caused by generating such a tag cloud could be kept under control.

What do you think?  Is it going to work?  Is there something that I missed here?  Is there are a plugin that can do this?  Would you jump in and implement it or should I do everything myself?

Tip 0 in this list of tips for a fresh WordPress installation mentions how to configure a custom uploads directory.  By default, uploads go into wp-content/uploads/ folder, but you can easily change that in your administration.  The tip gives to benefits for moving your uploads somewhere else:

• Image URLs become shorter (http://img.mydomain.com/2009/06/system-crash.jpg vs. http://mydomain.com/wp-content/uploads/2009/06/system-crash.jpg).
• The size of your WordPress folder will remain small. (Backups will be easier, and you can install and update your WordPress from the Subversion repository too.)

These are good, but I think there are more:

• It’s easier to share the same uploads between several sites.  For example, if your site is multilingual and you use a separate WordPress installation for each language, then you can have a single uploads folder for all your translated sites. (However, there is still something that needs to be done with the database, so it has attachment data properly).
• In case you move your uploads into a sub-domain, you can save bandwidth.  Caching can be improved, and you don’t need to send cookies any more.   Static content, such as images, CSS and JavaScript files, often don’t need any cookies passed in the request, but if your site is using cookies for some pages, often cookies will be sent for static data as well.  This advantage of course applies more to sites with a lot of traffic and static content.

I came across this post, with a self explanatory title – “13 Most Important Things to do When Changing the Wordpress Theme“.  This is particularly relevant to me, since I am updating my theme right this moment.   And so, I thought, I’d just revisit the list items of that post with my own comments, since they are so fresh.

• Take a backup of your current theme folder. That is always a good advice.   Better even, take full backup of your blog, including the database dump.   Why is the dump relevant for theme upgrade?  No, not because I am obsessed with backups now that I lost all my archives.  But because most themes these days include dynamic sidebars, which you usually fill with widgets.  Widgets configuration is kept in the database.  And when you are moving to a new theme, your dynamic sidebars often get out of sync, and you try to fix it fast by re-arranging widgets again.  In case things go very wrong, it’ll help to have a database dump as well, which, when restored, will bring back your widget configuration.
• Check for broken links.  A new theme will hardly affect links in your content, but everything around it – headers, footers, sidebars, links to RSS feeds, etc – can easily get damaged.  This happens especially often when you use a testing or development environment which is separate from your main production blog.
• Look for possible security loopholes. Ideally, you should do this BEFORE you move your site to the new theme.  The best approach here is to combine manual and automatic checks. Manual checks include reading the theme source code, checking the site in different browsers, from different IP address, while logged in with different access levels, as well as logged out altogether, etc. Automatic checks are provided by a whole bunch of applications, including some security oriented WordPress plugins.
• Remove unnecessary code from your WordPress header. This has a lot to do with tightening up the security of your WordPress installation.  The less information you give out to potential attackers, the better.  I have no idea why this item is separated in that list from the previous one.
• Make sure your RSS subscription link is correct.  If you link to several feeds (posts, comments, category, etc) – check them all.  Also make sure that you have them in your header for RSS auto-discovery to work.  The best approach here is to use WordPress builtin functions for RSS links, not hardcode them by hand.
• Check if all your pages are listed properly.  Again, it’s not always possible to code your menus and navigation to work in every theme out there, but sticking to WordPress Codex ways you guarantee to minimize the troubles for yourself.
• Put back your stats tracking code.  I suggest to find and install the suitable plugin.  There are many available for practically any statistics package.  The plugin will usually take care of installing all the necessary codes, goal tracking, conversions, and the rest.  Plus you’ll keep you configuration in simple and easy way via administration interface, rather than editing theme source files directly.
• Check your website from different browsers.  That’s the second best advice after taking a backup before even starting.  Cross-browser issues are the most common to appear and the most nerve-breaking to fix.  Even if you don’t know how to fix them yourself, still check your new theme for any glitches in different browsers, to at least know that you have them.  Fixing them can be arranged separately.  If you don’t have different browser versions available at hand, ask your friends or readers to help, or use web tools, such as BrowserShots.
• Check if you sidebar content is correct.  Especially so, if you had custom sidebars for the front page, categories, posts, pages, search results, archives, etc.  Even more so, if you are using widgets (see above).
• Re-evaluate your plugin usage.  As the original post mentions, it’s a good time to see if you still need all those plugins you were using before.  And there is another side to this too.  Many heavily customized themes keep some functionality code in functions.php file.  When moving to another theme, the functions.php from the old theme might not necessarily work under the new one.  Maybe it’s a good time to move some of that code into more generic plugins and widgets.
• Put back your AdSense / other ads code.  This is somewhat similar to your statistics.  If you use AdSense or any other well-known advertising service, you’d be better of with installing and configuring an appropriate plugin.  If the ads are customized, than you should probably move them out of the theme code into separate files and then just include() where appropriate.  Definitely worth a check after the move is done.  While checking the site in different browsers, take a look at the ads as well, just to make sure all your visitors can see them properly.
• Check if your favicon is proper.  Ideally, this shouldn’t break by your theme change.  While there is a way to specify favicon’s location in your theme’s header, I find it better to drop the favicon into root folder of your site – most browsers will pick it up from their automatically.  And it will work even when your blog is horribly broken.  Additionally, I don’t think changing your favicon often (even if ever) is a good idea.  Favicon is like your site’s avatar.  It takes time for people to get used to it and recognize it.  Why change it when some of your visitors just got used to this one?  Unless, of course, your favicon doesn’t represent your site at all anymore.  Then – yes.
• Look how you can optimize your blog.  Yeah, well, true.  However, before you start optimizing anything, make sure that you have the full backup (try restoring from it to a test blog), make sure that everything works before you start optimization, and make sure that there is any need for optimization at all.  Premature optimization is evil.
• Put up a post about the new design.  This is a good idea.  Before you do a full blown post however, maybe you should post a short update to your Twitter account (you do have a Twitter account, don’t you?).  This way, your followers can point out any bugs in time to fix them before you notify the whole blogosphere, search engines, and RSS feeds.  Once you are completely sure that everything works – yes, indeed, blog about it.  Tell your readers why you changed the theme, if there are any new features, and how much effort it took you to put it up.  A post like this would usually inspire at least a few of your readers to do something with their blogs.  And that’s something that we definitely need – more and better blogs.

P.S.: even though the original post’s title says “13 things“, there are in fact 14 items on that list.  I guess the counting went off, because it started from 0 and not 1.