Part II – The Issues with WordPress Architecture
Wordpress is definitely superior to Word for most of our
clients’ needs. The architecture is secure, popular and highly customizable. So
when we picked a platform that would allow us to import, create, track, export and
isolate content for our clients, WordPress Multisite was the obvious winner. It
would allow us to create unique URLs for our clients to access their specific
copy assets. User management was baked in, and when we were done it was a
simple export and import process for the development team. It seemed like a
perfect setup.
Issue 1: Absolute URLs are absolutely evil
They are the root of all evil when it comes to content
portability. WordPress is built on the notion that absolute URLs are a
requirement of the Internet. And the design decision permeates every aspect of
its core with dire consequences. In a very painful and lengthy discussion with
several members of the core development team I tried to determine where this
fallacy originated, or at the very least, why it still persists.
As a preface I'll note that there are four different types
of URLs, relative, root relative, schemeless and absolute.
- Absolute
URLs are the fully qualified URL that includes the scheme (http/https/ftp
etc,) domain name (google.com) and path (/ig). They look like
'http://www.google.com/ig'.
- Schemeless
URLs drop the scheme portion of a URI - they look like this:
'//www.google.com/' and they are good to use when you are importing a
third party library on a page that is served over http and https. The
browser will just prepend the current document's scheme to the URL thus
avoiding Unsecured
Content warnings.
- Relative
URLs start with a directory name, a dot (.) or two dots (..) and are
generally frowned upon because if you move a page to a different folder in
your webserver all of the links will point to invalid locations since they
were relative to that particular directory.
- Root
Relative URLs always start with a forward slash (/) and
are the most common form of URL on the Internet. They indicate that a
document exists from the root directory of the server. You can move a page
that contains root relative links anywhere you want and they will always
link to the appropriate content. For example '/logos/classicplus.png' is
the root relative URL Google uses for their homepage 'Google' logo image.
97 of the top 100 Alexa websites use root relative URLs extensively
including http://www.wordpress.org.
So if Root Relative URLs are so common, and if they have
been supported since 1991, and if wordpress.org uses them, and if they make web
development easier then why doesn't the WordPress CMS use them? The current
core development staff will give you a dozen inane reasons why absolute URLs
are better. And unfortunately this architecture mistake has turned into a
religion to justify its existence so pointing out the easier solutions to the
"problems that haven't been problems since 1997" are simply
dismissed. And anyone who disagrees is a heretic - seriously, don't mention to
them that wordpress.org and the rest of the Internet uses root relative URLs.
The real reason WordPress CMS uses absolute URLs is because
it was an intrinsic design flaw from its early precursor project called
b2/cafelog. And the original developer of WordPress said that if he could go back in time and
change it he would, but as it stands it's too complex of a problem to solve on
a platform that serves 70+ million websites. Doing so would risk breaking a lot
of plugins let alone entire websites. Fair enough Ryan, I appreciate the honest
answer.
The consequence of this design is that there are a number of
hacks required to work with WordPress in a mature development life cycle. For a
personal blogger, it is quite OK to make changes to your website on the live
website. But for companies who are concerned about downtime and outages this is
unacceptable. At Springbox we have a development server where we make our
changes and debug issues. A QA server where our QA staff validates those
changes. A staging server where product owners and other departments confirm
the end result. A client review server where clients are able to view their
site outside of our office. And finally our production servers that host the
end result. With absolute URLs every time we migrate content from one server to
the next we have to globally search and replace all of the URLs to prevent the
links from sending a user to different servers. And that global search and
replace is not
full proof either.
But the WordPress architecture goes one step further on the
admin interface and compares the URL that you are browsing against the URL it
stores in the database. If they don't match it will redirect you to the URL
that is in the database. This means if you access your website by IP address,
say from your iPhone to test out a new feature, you will be redirected to the
public website instead of the development server you need to test.
WordPress core members will tell you a number of different
hacks to solve the problem, but they don't actually solve the entire problem,
only one aspect of it under limited conditions. And when your client wants to
review the staging server they expect you to show them how to modify low level
OS files to trick their browser into navigating to a different server. And if
you work with an enterprise level client or government agency that employs
security measures like networks with DMZ's one WordPress core developer expects
you to tell the client to change their entire network infrastructure because
they're idiots for using a DMZ... seriously.
In reality the rest of the Internet switched to root
relative URLs over a decade ago to solve these problems amongst many others.
And migrating content between our in-house CMS to our clients CMS would have to
overcome this issue to be a viable platform.
Issue 2: WordPress Is Either User-Friendly Or
Developer-Friendly, But Not Both
The second major concern we had with WordPress was the
content editor used to create blog posts and pages. It uses a product called
TinyMCE which does an amazing job of allowing you to edit the HTML directly or
provide users the option of editing content via a Microsoft Word like interface
called WYSIWYG (pronounced: wizzy-wig.) Unfortunately the way WordPress
implemented the feature you have to pick and choose which mode you want.
If you create content in HTML mode you can create any
content you want, and preview it on the front end of the website. But if
someone without HTML experience edits the content in the Visual WYSIWYG mode it
will clobber the HTML source in spectacular ways - often restructuring the
document altogether. Worse yet, if the HTML developer accidentally clicks the
Visual tab, and clicks back, the same result occurs and their progress is lost.
This is not TinyMCE's fault, though the core development
staff was convinced otherwise. Their recommendation is to disable either the HTML
or the Visual tab and only work with one of them. This might work for some
people, but as a reliable platform designed to work for everyone in our company
and all of our clients it was simply unacceptable. There are a number of
plugins available to alleviate this issue to some degree, but none of them
truly resolved the problem.
Issue 3: Menus In WordPress Are Not As They Appear
Editing menus in WordPress appears to be a beautifully
designed feature of the WordPress administration panel. You can drag and drop
entire branches, quickly add key pages, categories or external links. You can
have as many menus as you like, which is great for testing out different layout
options. And each menu item is fully customizable all within a well designed
interface.
Seems perfect, until you want to edit the options of each
menu item or delete multiple items altogether. And where everything else is a
simple drag and drop motion, this feature comes crashing down into a slow,
multi-click endeavor. For some reason everything else about the interface
operates on AJAX communication with the server, except for the menu details
pane which requires page posts to the server. This has three terrible
consequences:
- You
can only edit one menu item's details at a time. Worse yet, you can only
view the details of one menu item at a time. And even worse still, editing
or deleting a menu item requires reloading the menu manager page twice,
first to expand the menu item details pane, and again to save the changes
you just made. Two full page reloads per menu item on sites that may have
100 menu items or more results in a very painful user experience. With
lots of menu items a single page reload can be pretty slow, doubly so with
the two-step nature of the interface.
- Secondly,
menus create a separate hierarchy that cannot be synchronized with the
page heirarchy in the Page Management section of the administration panel.
This means you have to manually keep them in sync. So that whole
drag-n-drop feature is pretty much useless if it means you also have to
edit the 'Parent Page' setting of every page just to keep your bread
crumbs and your sitemap in sync.
These problems went unnoticed on other projects because we
had siloed the sitemap phase when it was managed by hand in a Word document.
Ironically managing this aspect of the project in WordPress proved to be slower
and more error prone. And due to the crazy method WordPress stores the menu
information in the database, there aren't many plugins available because the
architecture is just too difficult for most developers to bother with it.
Issue 4: Not All Content Lives In Blog Posts And Pages
This is less of a WordPress problem and more of a 'Nobody
Has Solved This Yet' problem. Typically when we create a WordPress site for our
clients, we have to hard-code some content in certain places. Headers and
footers typically have a callout or two that just get translated to html in our
custom theme. Our clients don't mind because they care mostly about the page
content, and the cost of having us or some independent contractor tweak a bit
of static copy is trivial. But it doesn't have to be static by definition and
such an approach is less than ideal if a user-friendly solution exists.
Since the WordPress framework does not solve this problem
out of the box, it was worth noting here, lastly of course because it is the
weakest issue surrounding the platform. And in the end it proved to be the
easiest problem to solve.