Wordpress

Wordpress was developed around 2003, when Matt Mullenweg and Mike Little decided to develop their own tool to manage their blog site. They started by forking the B2/cafelog blog platform, but in the following years a lot of features where added, Wordpress grew, was offered under a GPL license and had a great success in a period in which most blog platforms where expensive.

The general Wordpress layout is simple; in the web page some regions are defined, as: an header ( with an image, a tagline, a title, a menu), a main content space, one or more sidebars, a footer. Wordpress is mostly used for blogs, with the main space containing posts, but also simple html pages, with a hierarchical structure, can be used. There is a keyword system (taxonomy) to classify posts and pages.

Little applications (widgets), as: calendar, search tool, list of recent content etc., can be placed in the different regions.

The site appearence is completely defined by a "theme", which is a separate component and is made by a main CSS file and a collection of html templates, which describe the different regions of the page.

There is a plugin system to add external software component to the system.

There is an authorization scheme and a workflow for publishing, a simple visual editor to insert text and pictures and all is managed by an easy web interface.

wordpress simple layout

A simple wordpress layout is shown in the first figure; we see the header at top, with the site name and the tagline, a big logo, then the menu, the main text with a figure, at bottom the footer. Here there are not sidebars.
A more complex layout is in the second figure, where we have also a sidebar with a contact widget, and, at bottom, a widget with figures and titles of recent posts; there is also a rich footer, not shown.

wordpress rich layout
Wordpress dashboard

The management interface is also very easy. with a limited number of configuration pages, which allow for the definition of the main features of the CMS. There is also a dashboard, shown in figure, with an header containing buttons for the choice of the language and some user options; at the left a general menu. The central zone links to common actions.

In the menu in the left sidebar there are terms as: Eventi, Pubblicazioni, Convegni that are not standard, but defined by the used theme as custom page types.


wordpress general settings

The general setting menu allow for the definition of the site title, the tagline, and few other parameters.

There are menus to add and manage users and their roles, menus to load and activate themes and plugins. Sometimes the themes have their own page for settings, defining size and placement of header, taskbar and footer, choice of colors and fonts.


pemalink page definition
In most CMS, pages and posts are identified by a number, corresponding to an entry in the database; but there is also an option to give simple names to the pages, these names are told: permalinks. The permalink setting page is shown in the figure

wordpress page configuration

To modify pages and posts, there is a menu with the list of existing content and an option to add new items.


wordpress editor
The editor used to add or modify content is also simple: there are very few button at top, HTML tags are inserted in an automated way and hidden in the interface. There are few option at the right to publish the content and define the position of the page in a hierarchical structure. There is also (not shown) an option to define a figure which represents the page in some indexes or summary.

wordpress image library

Images to be inserted in pages have to be loaded into the Wordpress site; this is also done thought a simple interface. There is an image library, corresponding to some folders in the Wordpress installation space, with all the images; the editor has an option to insert images from the library into the page.


Wordpress is the most used CMS in the world, it is it is simple, easy to deploy, manage and use; moreover many hosting providers offer semi-automated Wordpress installations. It is also preferred by many professionals, because selling Wordpress sites minimizes deploying times and maximizes income.

But there are many drawbacks in Wordpress usage; Wordpress suffers for a countless number of problems, it is not well conceived, is known for being vulnerable and had a long story of security flaws.

The Wordpress core is very limited, so, to extend Wordpress, a lot of plugins have been written by different authors; the wordpress.org site offers tens of thousand of plugins, to do everything: for contact forms, multi-language sites, point of sales, mail management, photo albums, sliders, media management, SEO... everything. Obviously not all the plugins work for every version of Wordpress, some are unmantained or obsoleted; many are commercial, sold by different software houses.

Wordpress has a simple layout, but it can be modified and enriched by complex themes; there are countless themes for Wordpress. Here also we have different quality, different versions, usually few documentation. Many commercial entities sell Wordpress themes for specific usage as blog, newspaper, sales etc.

This extreme diversity is an advantage, but also a source of problems and confusion, expecially when a plugin or a theme works only for a specific version of Wordpress.

One of the pillars of the Wordpress architecture is the concept of hook. Hooks are points, in the program, where external routines are called. These external routines are not always part of the Wordpress core, but can be part of a theme or a plugin: theme and plugin authors define an hook function, then register the function the Wordpress core, to be called in a particular point of the program; in this way people writing themes and plugins can integrate easily their work into Wordpress, whitout having to modify the Wordpress core.

This system can be seen as a good idea at first sight, but it breaks one the most naive rule of software engineering: "divide the components and cure the interfaces" . There are tons of hooks in Wordpress (some badly documented): hooks in themes, calling wordpress function, hooks in plugins; some hooks in themes and plugins are mandatory; the same Wordpress core use internally hooks, and to a same hook a full list of functions can be attached, each with its own execution priority.

When Wordpress is enriched with many plugins of different origin and a nice theme full of features (indeed a very common scenario), with theme and each plugin inserting each its own hooks regardless of others, the Wordpress site results in an entangled mess impossible to mantain and update.
The hook system is the interface of the Wordpress core used by themes and plugins, an interface complex, confused, partially undocumented and changing at each Wordpress version.

An other problem is how images and attachments are managed. They are shown as an unique archive, without a real structure, corresponding to some directories in the Wordpress installation (with files organized by date). This could be adequate when Wordpress was a simple tool to mantain personal blogs, but is unsuited for large sites, with a lot of images and media; finding an image means browsing a list of hundreds of items.

Also the CSS management is very involved, in the generated HTML code you can find things like:

<li class="menu-item menu-item-type-post_type menu-item-object-page current-menu-item page_item page-item-33 current_page_item menu-item-48" >
This menu item has seven CSS classes, but many other are inherited, and some of these classes are not defined, but simply put there, for an unknown future usage, all badly or no documented. To change something you have to dig into the theme, hoping that your changes will not conflict with some future theme release, defining previous undefined class in an inconsistent way. In this case the hierarchical structure of themes: with parent and child themes, redefining part of the parent, doesn't help, but brings additional complexity to the system.

Also the portability of a Wordpress site is a problem. Wordpress use everywhere absolute URL (addresses) for pages, media etc.; since the ancient times of HTML 3, a basic recipe was: "use relative paths"; but this recipe seems forgotten today. To move a Wordpress site from a computer to another is a nightmare; there are plugins to do that, sometime partially working, but sometimes not: because themes, plugins and Wordpress itself, hide absolute URL everywhere in the database, in an unpredictable way, so you have to dig into the database hunting for URLS, hoping to catch them all. I found a topic in a blog dealing with this problem; from some answers I concluded that not only the users, but also the Wordpress developers can't properly understand and manage file paths, and the hierarchical structure of an Unix file system; something that has been around for more then 40 years... Also, it should be easy to understand that presenting to the browser an absolute path should not means that you have to write absolute paths here and there in the database.

In conclusion: Wordpress is born as a tool to manage a personal blog, then grew, but the initial philosophy of a simple hack remained, resulting in a pile of tricky hacks than are really unsuited for a serious web site. But, if you need something for a simple blog, Wordpress, being very easy, can be the good choice; but avoid too many plugins and remember to update your installation: I see everyday tens of fake mails and attacks from hacked Wordpress sites 😊