4 Comments

  1. Li-An
    · Reply

    Sadly, the Github gives a wrong information : the theme is not on the depot.

    Report

  2. Gwyneth Llewelyn
    · Reply

    Back in 1997, a small company that I worked with had developed a first-generation CMS, when it was still fashionable to design every website from scratch, using some sort of handcrafted ‘backoffice’ which allowed end-users to add a bit of content here and there. This particular company had done this so often that they were getting tired of always reinventing the wheel, and so decided to develop a full-blown CMS instead. Version 1.0 was even open source (we had no GitHub back then!).

    Beyond being blindingly fast (these were the days when code was code, not endless declarations of abstract classes spread over a thousand library & framework files…), and including things that are considered absolutely indispensable today (such as an effective caching system that would work with Apache rewrite rules in order to avoid over 99% of all backend queries to the PHP + MySQL engine; or complex analytics built-in into the system, before Google even existed, much less Google Analytics; or full support for restricted areas and dealing with frontend user registration separately from backend users), one awesome feature it had that I always loved was the concept of layouts that were essentially different ‘blocks’, called ‘objects’. An object had its own mini-layout and there was a very simplified programming language that allowed end-users to instruct the CMS to display certain kinds of content; there was no limitation on the amount of ‘commands’ that could be added to a single object. Although simple enough (they would basically work as user-friendly SQL-like queries, but much, much simpler), this solution was immensely powerful and allowed you to design pretty much any type of website, because you were not limited to the concept of ‘one theme/template with slots for widgets’. Each ‘object’, while similar in concept to widgets, could be placed wherever needed, and effectively worked as a ‘mini-website’ embedded inside the overall look and feel of the page.
    When the first open-source CMSes (including WordPress) started to become not only available, but popular, I was impressed by their wonderful backoffices — but frustrated by its abilities to configure different kinds of websites. Joomla came closer than WordPress in this regard, but to accomplish similar results, you’d have to start a mega-project under Drupal and basically write everything from scratch.
    Over the years, this company went on to develop a version 2.0 and even a 3.0. These were not backwards compatible in the least, and were never released as open source. Although the backoffice was incredibly minimalist (even for developers) and these subsequent versions reflected more modern programming styles, they still built on the original concept, where ‘objects’ slowly became ‘building blocks’ of code that could be reused on different websites (not unlike what we’d call ‘plugins’ in WordPress — with the difference that they were stored in a completely different way). Last but not least, as it became clear over the years that the biggest bottleneck was the MySQL database, version 3.0 introduced the concept of a database-less, flat file CMS, before such a concept even had a name (although it was by far not the first CMS doing so).

    That’s past history. This is 2020. The company behind that CMS has essentially shut down — before the pandemic, at the height of the economy — for the simple reason that most of the team (including the owner) was ‘bought’ (not the company, though) to work for one of their former clients, full-time, earning tons of money.

    While I will always miss the simplicity and ingenuity of the 1.0 version — I’ve still copies of it stored somewhere; there are even a few companies out there still using it; it was a pain to get it working under PHP 5.6 and it barely works on 7.+, but it requires major code changes to keep up with current technology, way too much for me to waste more time with it. Possibly the first site I’ve migrated to WordPress was my own blog, back in 2005 or so — even by then, WordPress was way easier to maintain than a 8-year-old CMS which was officially unsupported. I missed a lot of its features, though, but of course WordPress was simply unbeatable in terms of ease of use, overall configuration, tons of plugins (even back in 2005), and frequent updates. It lagged behind in raw speed and performance by a wide margin, but sometimes performance is not everything. I moved on with times, and these days, except for the occasional Grav blog, I pretty much host everything on WordPress.

    Obviously, I still looked at other CMSs advantages that seemed ‘impossible’ in WordPress — such as the Gutenberg block editor. Strange at first, but a must these days. I’m plagued with old-generation WordPress websites which use shortcodes or their own ‘templating engine’ plugged into WordPress to, uh, ‘overcome its shortcomings’ by introducing Joomla-like features (ugh!) in a clunky way. And the next theme I’d buy would introduce a completely different way of doing the same things. And many things still seemed to be impossible; one of the first plugins I used, for instance, was to get a shortcode to publish a series of links to articles based on a specific query (i.e. just show the titles + excerpts of one category) — it seemed amazing that such functionality wasn’t part of the ‘core’ WP, and that it was so hard to implement. I used to tweak themes all the time because so many had the wrong approach to certain features I needed or wanted, or completely lacked support for other features. These days, fortunately, both WordPress and the theme designers and programmers are becoming more sensible in their approaches — I have been restricting my tweaks to the minimum, and, over time, with new features being introduced all the time, my own tweaks often become obsolete (thankfully so!), and I can rely more and more on what is provided directly from Auttomatic or any theme/plugin developer.

    I think that there is a revolution ahead, if the ‘new’ WordPress will work in the way you describe in this article. Fortunately for all in the WP community (do we call ourselves ‘wordies’ or ‘pressies’? ;-) ), Auttomatic didn’t relent the pace of development, even after WordPress becoming the #1 CMS in the whole world, contrary to all expectations from the Big Players back in 2005 or 2010. WP is still innovating — but, more important than that, it’s bringing whatever functionality is available on other CMSs and make those integral to WP’s core. Oh, sure, plugin developers will grumble about many of the changes — especially those who have spent aeons developing complex plugins to accomplish what used to be ‘simple’ tasks that were later introduced in WP, and made good money out of that development. It’s sad, but Auttomatic has no real choice but push harder and harder, to stay on top of current developments and fashionable features that CMS users ‘require’ from a modern CMS.

    I think that one of the most dramatic changes in the past was the move away from posts/pages/attachments towards taxonomy. The second, IMHO, was Gutenberg — replacing a gazillion plugins and themes that have tried to do something similar, with more or less success. Gutenberg still has lots of tiny, annoying issues, but it’s plodding along nicely. Themes with ‘template parts’ was also a must — considering that plugins such as Gantry have been doing that for years and years. And… well, the obvious next step was what they are now calling ‘patterns’. These will trigger the next revolution (even if I have no idea of how exactly these are going to be implemented!). But we need those revolutions.

    Almost twenty years after WP 1.0 was released, it’s a comfort to know that WP is still innovating, not only ‘catching up’ with whatever has been released by ‘other’ CMSs, but pointing towards the future.

    It’s always fun to read how it all started and evolved into the platform we use today.

    I’m looking forward to a database-less, flat-file ‘option’, one that does not even require Apache/nginx + PHP to be installed but is based upon a constellation of components/microservices that follow an SOA approach. Oh, we will be there one day with WordPress, I’m sure! :-)

    Report

  3. Raacho Trekkers
    · Reply

    I’m looking forward to the color palette feature. I can choose a color to express an emotion of a page/blog post.

    Report

Leave a Reply to Justin Tadlock Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: