Hacker News Reader

Comment by NathanKP | Hacker News Reader

There is a more technical list, including the details on the improvements for developers here:

http://codex.wordpress.org/Version_3.5

The biggest thing I wish WordPress would add is a better built in system for real templates, using a something along the lines of Twig (http://twig.sensiolabs.org/).

That mixed PHP code and HTML in your standard WordPress template disgusts me every time I see it. I know there are some custom solutions for creating real templates in Twig, but this should be part of the mainstream WordPress branch.

View on HN

Yup, WordPress follows all bad practices of a typical PHP project: mixed PHP and HTML all over the place, lots of global functions instead of classes and direct calls to the MySQL functions instead of PDO so you can't use another database like Postgres.

Pity it's so widely used, and there's little competition...

Saying there's little competition is a huge stretch. WordPress is the dominant force by a large margin. But from small static site generators, hosted platforms, other open source alternatives, to enterprise-ready solutions there are a lot of competitors hitting nearly every segment of the market.

http://trends.builtwith.com/cms provides some good trends of the big players, but I wouldn't put too much stock in it.

That said, as a developer who has fallen into the WordPress business out of necessity, there are a lot of great products out there that are built much better than WordPress and I wish one of them were the dominant player. Still, WP manages to get the job done most of the time.

> there are a lot of great products out there that are built much better than WordPress and I wish one of them were the dominant player.

Honest question: Can you name one?

I'm seriously looking for a WordPress alternative, but I haven't found one that is truly BETTER.

What I mean by this is others have a better structured, more solid & easily extendable code base, better separation between presentation and logic, etc.. Obviously, this is somewhat of an opinion, and it only refers to the underlying structure. For the end user, WordPress is probably the best. A large part of this is due to its ecosystem of plugins and themes. You shouldn't need to build custom code on top of WordPress unless you are doing something very unique, building an application (as opposed to a "website"), or attempting to tie together several plugins.

Sticking with PHP, both http://modx.com/ and http://www.silverstripe.org/ are fairly popular and well-built. I've also heard good things of http://www.concrete5.org/ , http://www.movabletype.com/ , http://textpattern.com/ , and http://ellislab.com/expressionengine . http://habariproject.org/en/ has also been built specifically to address many of the faults in WordPress and other popular systems.

Isn't MoveableType in Perl?

Possibly - I've never done anything with it. The PHP statement was really only for the first two, sorry for the confusion!

depending on what type of project you are building you might want to have a look at yeager (http://www.yeager.cm). although the site states beta, the tool is stable and used in live environments since several years.

In fairness to the WordPress developers, the quality of the product has been pretty consistently getting better over the last few years.

There's still plenty of warts, of course, but that seems true of just about every widely used piece of software -- bad decisions early on in development become very hard to walk back later when any of millions of sites/themes/plugins/etc. could turn out to be depending on that bad decision being there...

So you're basically saying that following bad practices is inconsequential since - among the thousands of CMSes, WordPress is the most widely adopted, despite an abundant availability of alternatives that claim to be simpler, more powerful and prettier. Interesting thought.

Worse is better.

http://www.jwz.org/doc/worse-is-better.html

No one is forcing you (or anyone) to use WordPress.

Speaking of competition. A while ago I saw an announcement of the Habari project, set out to build a "WordPress done right". I checked just now and they're still around. Released v0.9, which is PHP 5.3 only. It may be worth a look for those who seek a more modern approach.

http://habariproject.org

I wasn't aware of this, but mildweed posted later that PDO is coming. http://news.ycombinator.com/item?id=4907099

As someone closely following (and contributing to) the progress of Wordpress over the last few years, I continue to believe they are heading in the right direction given their constraints.

I like the fact I can mix PHP and HTML together. Pseudo templating languages like Twig are nice, but implementing something like Twig or even Smarty would be pretty damaging to the Wordpress community considering it's always been PHP/HTML since the beginning and to be honest, there's hardly any advantage other than cleaner code. I'd rather the Wordpress developers spend their time removing legacy code and changing some of the procedural spaghetti into nice object oriented code and adding in cool new API hooks.

Forward (a new e-commerce platform) uses a template engine and routing layer that might be something like what you describe. It works with MongoDB, has a REST-like model system, plugin system similar to WordPress, and you can do stuff like this in a template:

    {get $blogs from "/channels/blogs/entries"}
    ...

Alpha version was released just yesterday, you can sign up and download it at http://getfwd.com

/shameless plug

You're querying from templates? Isn't that considered bad practise? Isn't there a potential problem with template designers querying for loads of data and issuing a slow query?

It could be considered bad practice in some cases. But having the template also act as a controller gives theme developers more freedom to make something outside the golden path.

I doubt Wordpress would be used for anything other than simple blogs if it weren't for querying from templates.

Obviously there is the risk of theme developers loading tons of queries from a template but I think trying to prevent that would be premature optimization. The benefit of greater customizability outweighs the potential performance hit IMO.

You said it better than I could have. Forcing template developers to maintain separate controller code prevents a lot of good work from getting done in my experience. If the project expands and the combined templates become a problem (usually due to the make up of skills in the team, i.e. heavy on back-end developers), separating them is pretty straight forward.

It can be abused, but I've seen controller heavy systems abused the same way. It depends on your goals. Some people prefer to write controllers, and the framework also contains a controller pattern for those cases. For example, you could write this...

    # controllers/BlogController.php
    class BlogController extends AppController
    {
        function index ()
        {
            $this->entries = get("/channels/blogs/entries");
        }
    }

    # templates/blog/index.html
    {foreach $entries as $blog}
        ...
    {/foreach}

Or, as in my example, this...

    # templates/blog.html
    {get $entries from "/channels/blogs/entries"}
    {foreach $entries as $blog}
        ...
    {/foreach}

I've written substantial apps both ways, and so far I have found that powerful templates are actually easier to write, read, and maintain, perhaps because the entire request flow happens in a single file.

weird how I feel in reverse. pseudo languages in templates and restrictive new template syatems annoy me in reverse. I prefer general languages for templating.

The very restrictive nature of a template pseudo language is one of its beneficial attributes. If, for example, you use PHP to create your templates then the very power and flexibility of PHP allows you to make a "quick fix" for a model issue in the template, or a function call from the template, and next thing you know your template is no longer just a view, but instead a messy hodgepodge of code along the lines of what you often see when you open up the typical WordPress template.

The template pseudo languages enforce a strict separation between model and view, and they typically do so with a much more concise syntax and legible format compared with embedding PHP in HTML, for example.

I used to prefer general languages for templating, but once I learned the pattern of using Twig to the full I found that I could create templates much faster than before, and I could also go back to a template after a couple months of not looking at it and quickly understand what I was looking at.

This is a very good point. Sometimes those "quick fixes" really aren't the best idea, I myself used to "hack" so much stuff in Wordpress when I was using it, and yes I solved whatever problem I was having at the time, but a few updates later it would come bite me in the you know what.

So much of programming is protecting the programmer from him or herself. By enforcing rules you protect yourself from bad habits. I think a separate template system and keeping the view separate would help keep everyone honest.

Eventually I started to do my modifications as plugins, which is one area where Wordpress really shines. Other systems could definitely take note of the way WP handles plugins.

Somehow I expected, the valid argument against business logic mixing inside templates, making the case for a template language. I agree, but that way we are progressing towards dozens of languages in implementing a simple user function. For example, why not a language for controllers, and another one for models too?

In contrary, I am in the pursuit for the one universal language to be used everyhere replacing, javascript, html, css, templating language, ruby/python/php, sql..

You'd probably like Clojure.

As an aside, though, part of the reason we have different languages for things like backend code, markup and styling is that they're commonly done by different people with different specialties. A general-purpose language will not offer much benefit to a designer, but it will trip them up more often. Having a language tailored to your specialist is a good thing. The only time you'd really want everything done in one language is when the same coders are doing everything. I admit I'm in that situation very often, but it's more maintainable if you just use CSS or similar so that normal front-end guys can work with it.

That makes sense. Ideally it would be nice to have one common elegant language which can do it all. But I doubt that any one language can do everything elegantly. The syntax of some languages make them much more elegant for certain purposes. For example compare XML and JSON. JSON is great as a lightweight way to represent simple objects, but XML is better for representing entire HTML documents. Likewise you can do all your CSS stuff by manipulating DOM properties in JavaScript, but pure CSS is a cleaner and more readable way to do things because it only does styling statements. (Unless you go out of your way to put logic into your CSS.)

The bigger the project is the more you have to favor readability and maintainability first, and using multiple specialized languages to accomplish different specific tasks is an effective way to keep the codebase readable and maintainable.

Just sandboxing what changes themes can make to the behavior of the system would be a win. As far as WordPress is concerned today, there's "themes" and there's "plugins", but there's no separation of what those two things can do -- plugins can change the site's look and feel, themes can change how the site (and WordPress itself!) works. As far as WP itself is concerned they're both just big bags of PHP code that can do anything PHP can do.

That leads to all sorts of debugging fun when something weird is happening, and opens up naïve users who assume that a "theme" is somehow safer than a "plugin" (because all themes do is change the look and feel, right?) to security risks from downloaded or hacked-up themes.

I'm no fan of PHP, but building a template engine inside a template engine strikes me as particularly perverse.

>> Twig (http://twig.sensiolabs.org/).

The syntax is very Django/Jinja alike. They took good inspiration.

Meanwhile, why the Wordpress team didn't switch to a template engine and orm after all those years is a true mystery to me.

Drupal 8 is talking about using Twig, which my guess is very likely. Twig is made by the same people that start Symfony 2, parts of which Drupal 8 is going to be using.

Backwards compatibility with their existing ecosystem, really. There are a lot of people who make a lot of money building and supporting themes, and breaking all of that would be a massive change that could lose them a lot of community support.

Is it just me who doesn't see the point of using a templating engine with a language like PHP?

As long as you use the MVC paradigm or at-least sperate views from business and data store logic it seems like PHP works fine to do the templating its self.

Yes I can see the argument that non coders have to learn PHP, but is PHP really much harder to learn then the template language?

Also templating add's performance overhead.

What you essentially end up with is a "hypertext preprocessor preprocessor"

Considering Wordpress isn't and probably will never be a true MVC application, I don't see the point of adding in a template parser like Twig and separating code. All it does is adds unnecessary overhead all at the cost of prettier code, there's no other advantage to be honest considering PHP itself is already somewhat a templating engine. If people want a CMS that separates code from the presentation layer, they probably shouldn't be using Wordpress and considering Drupal instead. I've used Drupal and Wordpress quite extensively and let me tell you, after building one site in Drupal you truly appreciate just how easy Wordpress makes it to get stuff done in half the time even if it is at the cost of prettier code (clients don't care about code cleanliness all they care about is results and Wordpress gets results).

That's because twig was originally created by Armin - the creator of jinja. It was part of a (now abandoned) blogging engine called chyrp. Later, twig was salvaged by Fabien and incorporated into symfony.

Reply on news.ycombinator.com