Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WordPress 3.5 “Elvin” Released

wordpress.org

Post reply on HN
Print view View original

31–40 of 69 posts

Re: WordPress 3.5 “Elvin” Released

#31

Post by bryancinman »

colinramsay wrote: post #28
ericingram wrote: post #26

Earlier quoted context omitted.

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.

Re: WordPress 3.5 “Elvin” Released

#32

Post by papsosouid »

chrisblackwell wrote: post #25
zaphoyd wrote: post #22

Earlier quoted context omitted.

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.

Re: WordPress 3.5 “Elvin” Released

#33

Post by jtreminio »

papsosouid wrote: post #32
chrisblackwell wrote: post #25

Earlier quoted context omitted.

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?

Re: WordPress 3.5 “Elvin” Released

#34

Post by ericingram »

colinramsay wrote: post #28
ericingram wrote: post #26

Earlier quoted context omitted.

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

Re: WordPress 3.5 “Elvin” Released

#35

Post by bdcravens »

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

Re: WordPress 3.5 “Elvin” Released

#36

Post by ericingram »

bryancinman wrote: post #31
colinramsay wrote: post #28

Earlier quoted context omitted.

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…

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.

Re: WordPress 3.5 “Elvin” Released

#37

Post by cheald »

zalew wrote: post #13
NathanKP wrote: post #5

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 som…

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

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.

Re: WordPress 3.5 “Elvin” Released

#38

Post by NathanKP »

diminish wrote: post #16
NathanKP wrote: post #8

Earlier quoted context omitted.

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…

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, javasc…

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.

Re: WordPress 3.5 “Elvin” Released

#39

Post by whalesalad »

bdcravens wrote: post #35

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.

Re: WordPress 3.5 “Elvin” Released

#40

Post by jblz »

bdcravens wrote: post #35

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

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/

Post reply on HN