WordPress 3.5 “Elvin” Released | Hacker News Reader

WordPress 3.5 “Elvin” Released

wordpress.org

84 pointsnosecreek66 comments

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.

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.

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

>> 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.

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.

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.

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

The media changes are a welcome addition, but I can't help but feel Wordpress is still lacking in the media department quite a lot. One feature I've been hoping for in terms of media management is folders to organise media instead of paginating pages of all images being displayed which usually involves duplicates being displayed. I love Wordpress, but it would be great to be able to upload specific images for example of dogs into a folder called, "Dogs" and then being able to browse and manage media in said folder.

It's great to see Wordpress is taking steps in the right direction with every release. Another wishlist feature would be the integration of the Advanced Custom Fields plugin straight into the core which allows you to add custom meta boxes and fields to posts in a tasteful and aesthetically pleasing way. I'm excited about the future of Wordpress, it's my bread and butter and I don't see it being beat any time soon.

Re: media, one step at a time. :)

Re: custom fields: This makes little to no sense to be in core, because custom fields are just that, "custom". There's no point in giving the end user the ability to make their own meta boxes hooked to custom post meta if there is no plugin or theme actually using that meta data. Creating a meta box is something that the theme/plugin should do, because it's actually going to use the data gained from that meta box.

In other words, the horse goes in front of the cart, not the other way 'round.

WordPress could really change their bad reputation by dropping support for PHP 5.2 in the next release, and requiring 5.3.

This would allow future WordPress developers to namespace their code, and out allow simple closures withint your code.

As of PHP 5.5, there is no support for a straight mySQL connection. There is no real downside in WordPress adopting the PDO standard.

Do you have a source for PHP 5.5 dropping straight MySQL support? I'd like to read more.

http://news.php.net/php.internals/53799

That doesn't support the claim of no support for straight mysql connection in 5.5. It says they are going to focus on documenting how to use mysql with the newer modules instead of the old one, and that they will look into possibly adding deprecation notices for the old module in 5.5. Which means it will obviously still be there, and still work.

mysql_* functions will still work, they will simply be marked as deprecated from 5.5 forward:

https://wiki.php.net/rfc/mysql_deprecation

As of 5.4, mysql_* were officially discouraged via the docs.

Maybe in > 5.5.* mysql_* functions will be officially removed from core?

Somehow I doubt that we'll decide to drop support for 65.5% of our users (roughly 26 million websites).

http://wordpress.org/about/stats/

It's funny how many people say WP should drop 5.2 compatibility. It's certainly possible to push the hosts towards using 5.3, but the fact is that the user base simply isn't there yet.

Wordpress has adopted the PDO standard. It will be in WP 3.6. http://core.trac.wordpress.org/ticket/21663

That's the aim. Whether we actually get land it in 3.6 or not is another issue, since 5.5 isn't stable yet, so it's not really an issue just yet.

(Personally, I want it, but I can see there being friction, given the possibility of breakage.)

Unfortunately there is still no reliable unattended upgrade process inluding rollback (aka migration) for wordpress. I looked into this a little bit, but there does not seem to be a reliable way to check if plugins have been executed successfully and with expected results or not, so you never know after an upgrade if your site is broken.

There are still many other issues with the code, but having a clearly defined error-handling / -signaling for plugins would be the one single change that would help in many problem areas of wordpress development - making rules and knowledge about successful plugin execution and error handling obligatory for plugin devs could be the one single change that could also help to reduce that annoying flood of unbelievable bad code to be found in WP plugins repo.

Twentytwelves mobile first approach for me is source of pain. They essentially dropped support for IE8 and below which means people in corporate environments like the company I work for who are stuck to windows xp due to other legacy software that requires it cannot view the desktop view of themes based on WordPress new default theme.

horrendous muffled voiceover on that video

He's not muffled. He actually sounds like that. :)

Does anyone know if / when WordPress may start using a modern PHP framework (eg zf2 / symfony2)?

I seriously doubt that will happen in the relatively near future, for values of near including anything less than 5 years.

Wordpress is its own PHP framework; in fact, PHP itself is a framework, provides everything frameworks do from database querying to templating.

Calling Wordpress a framework is like calling Symfony a programming language.

Much like Drupal, WordPress can be bent into something vaguely resembling a framework, if you're the type of person who enjoys that sort of thing. But being the type of person who likes using WordPress as a general-purpose framework is sort of like being the type of person who enjoys being tied up and beaten with a rubber hose. It's a weird, weird kink.

Of the 2 I very much prefer Drupal. It's a bad CMS, but a great CMF. Wordpress is in my opinion the exact opposite.

That said, I haven't checked out the last 2 versions or so.

It wouldn't really be WordPress anymore at that point. You're likely talking about a rewrite of virtually every bit of code.

I propose that we sail there in the Ship of Theseus.

Highly doubtful, their structure is pretty set in place and they have a large ecosystem of plugin and template developers that tie into this structure. Changing that would be a bad move on their part.

Drupal and eZpublish did adopt Symfony, and TYPO3 built their own modern framework (Flow3). Out of these, Drupal and TYPO3 Neos also went with my Create.js library for inline editing.

So yeah, there is some precedent at popular CMSs using a modern framework on server, client, or both. We'll see when and if WordPress follows the example...

Despite what other people are saying, it is quite possible that we'll be taking parts of Symfony: http://core.trac.wordpress.org/ticket/22325

At the moment, we're not considering dropping support for PHP 5.2, so we'll likely take the best ideas and implementation from various frameworks and combine them. I'm fairly committed to reiterating wherever possible that WP isn't a silo and we need to be looking at what other PHP projects are doing. We're getting better at that.

I wish they'd put some serious resources into dealing with comment spam. I realize it'll always be an issue, but they could at least:

1) not make comments enabled out of box with no anti-spam measures (moderating isn't anti-spam in my opinion: technical solutions should come before man-power)

2) not make me rely on third-party plugins to combat it

I think the issue is that good spam detection systems, at this point, require a server to do all of the processing. This is why they created Akismet and provide integration by way of a plugin.

Akismet, while a plugin, is included in the default WordPress install -- it just has to be activated. I'm not sure how a standalone install of WordPress would competently fight spam in the automated manner you're advocating. Since spam techniques are constantly evolving, it's a pretty challenging machine-learning problem to stay a step ahead. That's where services such as Akismet come in.

http://akismet.com/how/

Akismet does a great job dealing with comment spam. Activate it and input your API key and you're done. Even other applications like PHPbb and "insert PHP content management system here" have problems with spam, it's not as easy as you think to detect and deal with spam.

I've used other pieces of software, even some paid-for PHP features, so I agree as to the spam problem. I was thinking more along the lines of disabling comments by default, and making it a bit of a chore to enable, to make point-and-click installs less of an attack vector.

Reply on news.ycombinator.com