7 ms·

WordPress 3.6 arrives with better post locking, built-in HTML5 media player

71 points by Lightning 13y ago

uladzislau 13y ago
I tried to submit the official Wordpress.org announcement and got "stop spamming us". http://wordpress.org/news/2013/08/oscar/ http://wordpress.org/news/2013/08/oscar/ Is Wordpress.org domain banned on HN?
- ck2 13y ago
  Yeah all wordpress links here get immediately blocked as article submissions, I do not understand why. Maybe some wordpress.com blogs were being used for spam but wordpress.com != wordpress.org
  - deleted 13y ago
    [deleted]
  - bl00djack 13y ago
    I've also been wondering for a while now, what's the difference between those two sites ( wordpress.com and wordpress.org) ??
    - ck2 13y ago
      wordpress.org is the open source support site wordpress.com is the blog hosting site There are some worthy blogs that could be linked here from wordpress.com, but even if it had to be blacklisted, wordpress.org should not be, there shouldn't be third-party content on it except for maybe the forums.
jacques_chester 13y ago
And now begins the wait for 3.6.1 before I let it get anywhere near the blogs I host.
- hillbillyjack 13y ago
  Have you ever had an intrusion on your blog network because you updated to quickly? Just curious whether or not your fear is from a previous experience. Will you upgrade to new releases day 1 when WordPress implements auto-updating on the security updates?
  - anu_gupta 13y ago
    It's not necessarily about security issues. It's a fairly standard practice across a lot of different software products to not jump on the .0 release of something. For all the testing that gets done prior to release, inevitably some bugs will be shaken out after release.
    - rubinelli 13y ago
      Some plug-in and theme compatibility issues are also almost inevitable. Nobody runs "vanilla" WordPress, after all.
  - jacques_chester 13y ago
    What I've had is multiple experiences of upgrades fucking with my data. Sometimes to the point of destroying posts and comments. Yes, I have backups. It pisses me off having to use them.
    - vacri 13y ago
      I agree - how many intrusions have you had on 'oldstable'? Not a problem? Then why rush off to 'newstable'? Let other people find the holes first.
      - jacques_chester 13y ago
        I've had Wordpress cracked thrice under my watch by automated exploits. That's why I pay Sucuri $400/yr, simply to tell me when it's happened. The first one used an admin flaw to edit articles directly. The latest used the theme upload capability to write themselves into every theme in the system. (Partly my fault for leaving that directory as writeable by the server). I don't recall what the 2nd one did. Wordpress bundles security patches and bugfixes with the releases. You can't have them separately. If you need a fix or security update the basic mechanism is "fuck you, upgrade". Otherwise I wouldn't have upgraded for the past dozen versions or so. Basically I have to split the risk between security improvements and data loss. As you can imagine ... I am not a fan of Wordpress.
dbarlett 13y ago
Changelog: http://codex.wordpress.org/Version_3.6 http://codex.wordpress.org/Version_3.6
sehrope 13y ago
I've never used WP but I've read about it quite a bit. Usually it'd be after site X on HN goes down for not enabling caching and not being able to handle the load. There's always links to "best practices for caching" or other tidbits. Out of everything I've read though nothing is as funny as wp-cron[1]. If you're not familiar with it then it's worth a read for a good laugh. See [2] for a nice article about it, in the meantime here's a summary: If you don't have a native cron installation (eg. shared hosting or Windows) you can config WP to act as a cron daemon (actually might be enabled by default). The catch though is since everything is WP is triggered by HTTP requests the way wp-cron works is to check if there is a job to run every time a WP page is hit. Yes you understood that correctly, every single page that is rendered also checks if it should fire off a cron job. The jobs get executed async in the background so it doesn't hold up the ongoing request but it has two interesting properties. 1. If your site gets a large influx in traffic the server runs wp-cron for every page hit and further slows things down. 2. If your site gets no traffic then it doesn't run at all. Funny eh? [1]: http://core.trac.wordpress.org/browser/tags/3.6/wp-cron.php http://core.trac.wordpress.org/browser/tags/3.6/wp-cron.php [2]: http://wp.tutsplus.com/articles/insights-into-wp-cron-an-introduction-to-scheduling-tasks-in-wordpress/ http://wp.tutsplus.com/articles/insights-into-wp-cron-an-int...
- toble 13y ago
  It's just a hack for people without access to cron. It was more of problem back in the day when hosting services didn't offer control panels and most wouldn't let you have command-line access. If you knew your hosting company well, you could maybe talk someone into setting up a cron job. I remember doing something similar for a stats script that would wipe old data every time it was viewed by an admin.
- jacques_chester 13y ago
  I used wp-cron as one of the motivating examples for a different architecture; I talked about it on HN last week -- https://news.ycombinator.com/item?id=6106248 https://news.ycombinator.com/item?id=6106248 Essentially, given the constraints of the LAMP architecture, wp-cron is the only way to do it. You overlooked that wrapping WP in layers of caching restricts wp-cron's supply of triggering events. It's a mess.
capex 13y ago
Everything's great, but their text editor still can't accept markdown by default.
- jacques_chester 13y ago
  Shipping caching by default would be a better start. The Wordpress team have said that the hosting implications of writing to disk make it a non-starter; but for some reason that didn't stop them from shipping auto-update or one-click plugin/theme installation in mainline.
  - Viper007Bond 13y ago
    The WordPress leads speak from experience. Caching objects to disk was introduced in WordPress 2.0, released in 2005. Turns out it actually slowed down the vast majority of sites. Databases are really, really good at storing and retrieving data, much more than filesystems, especially when those filesystems are often remotely mounted drives. The functionality was pulled back out of WordPress in a later version, leaving all of the various hooks needed for a plugin to super-easily implement it on its own. I use a memcached powered one for example.
    - jacques_chester 13y ago
      Firstly, MySQL is actually terrible at the core task of Wordpress, which is joining tables with TEXT fields. If it finds a TEXT field it throws its hands in the air and joins on disk, taking great care to avoid any indexes you might have added to speed up those joins. Any time the query cache isn't there to save you, you wind up stomping around on disk anyway. Fun fact: the recent comments widget that ships in mainline blows the query cache. Secondly, file caching could still ship in mainline with a tickbox to enable it. Thirdly, I've never seen a site that wasn't improved by file caching. However I believe you that the Wordpress guys get a lot more reports than I do. Finally, 2005 was eight years ago.
- rmccue 13y ago
  This is exactly what plugins are for. Most people aren't going to need this, and for those that do, there's a tonne of plugins out there that will add this functionality for you.
mattkrea 13y ago
I have to admit I'm surprised a community like HN would upvote such a vulnerable package. Hell, even our sites that have been converted to static HTML still receive requests for /wp-admin/ by bots all the time. Thanks for allowing non-technies to set up their own site but no thanks--I'm good.
- smcnally 13y ago
  It's vulnerable because bots request resources in that subdirectory? If there's a request for cgi-bin should we throw apache away, too?
- rmccue 13y ago
  What serious exploits have popped up in WordPress lately?
  - nkuttler 13y ago
    I guess http://www.openwall.com/lists/oss-security/2013/06/11/3 http://www.openwall.com/lists/oss-security/2013/06/11/3 isn't serious enought? Oh, right, it's just in some third party code WordPress passes unsanitized data to. I also find it interesting that you as a core dev narrow down possible answers by using "serious" and "lately" in your question. Of course you specifically ask for "WordPress exploits" as well, maybe because themes and plugins run with the same privileges as WordPress core code, and there's no review process for official plugins hosted on wordpress.org? Not to mention from other sources..
    - rmccue 13y ago
      To clarify: I'm not part of the core team, I'm just a contributor. (I've also only briefly looked at this issue.) Keep in mind that while I'm an active contributor, I don't speak on behalf of the core/security teams. The aforementioned bug is in the phpass library used in WordPress. As fun as implementing our own cryptography is, we use the phpass library to abstract ourselves from this. Personally, I'd say this is something that phpass should be handling, as the use of crypt_private() is an implementation detail that we shouldn't need to know or worry about. (This is also an issue that affects a small portion of sites, as "Exploitation of this vulnerability is possible only when there is at least one password protected post on the blog.") As to the response from the security team (which is not exactly the core team), that's something I've called them out on before. Security is a serious issue that is usually handled very well on WP's behalf, but there have been a few notable instances lately where it's not. (Also, the reason I "narrow down" the answers is because there are smaller "security" issues that tend to boil down to "admins can do anything", which is intentional.)
jboynyc 13y ago
FWIW, I just tried to update my dev site, the install failed, and now the site fails to load. Yikes. In all fairness, I think that's because the admin has been playing around with file permissions on the server side. I can't even log in right now to read the errlog.
8ig8 13y ago
Might as well link to the source of TNW's regurgitation: http://wordpress.org/news/2013/08/oscar/ http://wordpress.org/news/2013/08/oscar/

71 points by Lightning 13y ago

I tried to submit the official Wordpress.org announcement and got "stop spamming us". http://wordpress.org/news/2013/08/oscar/ http://wordpress.org/news/2013/08/oscar/ Is Wordpress.org domain banned on HN?

ck2 13y ago
Yeah all wordpress links here get immediately blocked as article submissions, I do not understand why. Maybe some wordpress.com blogs were being used for spam but wordpress.com != wordpress.org
- deleted 13y ago
  [deleted]
- bl00djack 13y ago
  I've also been wondering for a while now, what's the difference between those two sites ( wordpress.com and wordpress.org) ??
  - ck2 13y ago
    wordpress.org is the open source support site wordpress.com is the blog hosting site There are some worthy blogs that could be linked here from wordpress.com, but even if it had to be blacklisted, wordpress.org should not be, there shouldn't be third-party content on it except for maybe the forums.

jacques_chester 13y ago

And now begins the wait for 3.6.1 before I let it get anywhere near the blogs I host.

hillbillyjack 13y ago
Have you ever had an intrusion on your blog network because you updated to quickly? Just curious whether or not your fear is from a previous experience. Will you upgrade to new releases day 1 when WordPress implements auto-updating on the security updates?
- anu_gupta 13y ago
  It's not necessarily about security issues. It's a fairly standard practice across a lot of different software products to not jump on the .0 release of something. For all the testing that gets done prior to release, inevitably some bugs will be shaken out after release.
  - rubinelli 13y ago
    Some plug-in and theme compatibility issues are also almost inevitable. Nobody runs "vanilla" WordPress, after all.
- jacques_chester 13y ago
  What I've had is multiple experiences of upgrades fucking with my data. Sometimes to the point of destroying posts and comments. Yes, I have backups. It pisses me off having to use them.
  - vacri 13y ago
    I agree - how many intrusions have you had on 'oldstable'? Not a problem? Then why rush off to 'newstable'? Let other people find the holes first.
    - jacques_chester 13y ago
      I've had Wordpress cracked thrice under my watch by automated exploits. That's why I pay Sucuri $400/yr, simply to tell me when it's happened. The first one used an admin flaw to edit articles directly. The latest used the theme upload capability to write themselves into every theme in the system. (Partly my fault for leaving that directory as writeable by the server). I don't recall what the 2nd one did. Wordpress bundles security patches and bugfixes with the releases. You can't have them separately. If you need a fix or security update the basic mechanism is "fuck you, upgrade". Otherwise I wouldn't have upgraded for the past dozen versions or so. Basically I have to split the risk between security improvements and data loss. As you can imagine ... I am not a fan of Wordpress.

dbarlett 13y ago

Changelog: http://codex.wordpress.org/Version_3.6 http://codex.wordpress.org/Version_3.6

sehrope 13y ago

I've never used WP but I've read about it quite a bit. Usually it'd be after site X on HN goes down for not enabling caching and not being able to handle the load. There's always links to "best practices for caching" or other tidbits. Out of everything I've read though nothing is as funny as wp-cron[1]. If you're not familiar with it then it's worth a read for a good laugh. See [2] for a nice article about it, in the meantime here's a summary: If you don't have a native cron installation (eg. shared hosting or Windows) you can config WP to act as a cron daemon (actually might be enabled by default). The catch though is since everything is WP is triggered by HTTP requests the way wp-cron works is to check if there is a job to run every time a WP page is hit. Yes you understood that correctly, every single page that is rendered also checks if it should fire off a cron job. The jobs get executed async in the background so it doesn't hold up the ongoing request but it has two interesting properties. 1. If your site gets a large influx in traffic the server runs wp-cron for every page hit and further slows things down. 2. If your site gets no traffic then it doesn't run at all. Funny eh? [1]: http://core.trac.wordpress.org/browser/tags/3.6/wp-cron.php http://core.trac.wordpress.org/browser/tags/3.6/wp-cron.php [2]: http://wp.tutsplus.com/articles/insights-into-wp-cron-an-introduction-to-scheduling-tasks-in-wordpress/ http://wp.tutsplus.com/articles/insights-into-wp-cron-an-int...

toble 13y ago
It's just a hack for people without access to cron. It was more of problem back in the day when hosting services didn't offer control panels and most wouldn't let you have command-line access. If you knew your hosting company well, you could maybe talk someone into setting up a cron job. I remember doing something similar for a stats script that would wipe old data every time it was viewed by an admin.
jacques_chester 13y ago
I used wp-cron as one of the motivating examples for a different architecture; I talked about it on HN last week -- https://news.ycombinator.com/item?id=6106248 https://news.ycombinator.com/item?id=6106248 Essentially, given the constraints of the LAMP architecture, wp-cron is the only way to do it. You overlooked that wrapping WP in layers of caching restricts wp-cron's supply of triggering events. It's a mess.

capex 13y ago

Everything's great, but their text editor still can't accept markdown by default.

jacques_chester 13y ago
Shipping caching by default would be a better start. The Wordpress team have said that the hosting implications of writing to disk make it a non-starter; but for some reason that didn't stop them from shipping auto-update or one-click plugin/theme installation in mainline.
- Viper007Bond 13y ago
  The WordPress leads speak from experience. Caching objects to disk was introduced in WordPress 2.0, released in 2005. Turns out it actually slowed down the vast majority of sites. Databases are really, really good at storing and retrieving data, much more than filesystems, especially when those filesystems are often remotely mounted drives. The functionality was pulled back out of WordPress in a later version, leaving all of the various hooks needed for a plugin to super-easily implement it on its own. I use a memcached powered one for example.
  - jacques_chester 13y ago
    Firstly, MySQL is actually terrible at the core task of Wordpress, which is joining tables with TEXT fields. If it finds a TEXT field it throws its hands in the air and joins on disk, taking great care to avoid any indexes you might have added to speed up those joins. Any time the query cache isn't there to save you, you wind up stomping around on disk anyway. Fun fact: the recent comments widget that ships in mainline blows the query cache. Secondly, file caching could still ship in mainline with a tickbox to enable it. Thirdly, I've never seen a site that wasn't improved by file caching. However I believe you that the Wordpress guys get a lot more reports than I do. Finally, 2005 was eight years ago.
rmccue 13y ago
This is exactly what plugins are for. Most people aren't going to need this, and for those that do, there's a tonne of plugins out there that will add this functionality for you.

mattkrea 13y ago

I have to admit I'm surprised a community like HN would upvote such a vulnerable package. Hell, even our sites that have been converted to static HTML still receive requests for /wp-admin/ by bots all the time. Thanks for allowing non-technies to set up their own site but no thanks--I'm good.

smcnally 13y ago
It's vulnerable because bots request resources in that subdirectory? If there's a request for cgi-bin should we throw apache away, too?
rmccue 13y ago
What serious exploits have popped up in WordPress lately?
- nkuttler 13y ago
  I guess http://www.openwall.com/lists/oss-security/2013/06/11/3 http://www.openwall.com/lists/oss-security/2013/06/11/3 isn't serious enought? Oh, right, it's just in some third party code WordPress passes unsanitized data to. I also find it interesting that you as a core dev narrow down possible answers by using "serious" and "lately" in your question. Of course you specifically ask for "WordPress exploits" as well, maybe because themes and plugins run with the same privileges as WordPress core code, and there's no review process for official plugins hosted on wordpress.org? Not to mention from other sources..
  - rmccue 13y ago
    To clarify: I'm not part of the core team, I'm just a contributor. (I've also only briefly looked at this issue.) Keep in mind that while I'm an active contributor, I don't speak on behalf of the core/security teams. The aforementioned bug is in the phpass library used in WordPress. As fun as implementing our own cryptography is, we use the phpass library to abstract ourselves from this. Personally, I'd say this is something that phpass should be handling, as the use of crypt_private() is an implementation detail that we shouldn't need to know or worry about. (This is also an issue that affects a small portion of sites, as "Exploitation of this vulnerability is possible only when there is at least one password protected post on the blog.") As to the response from the security team (which is not exactly the core team), that's something I've called them out on before. Security is a serious issue that is usually handled very well on WP's behalf, but there have been a few notable instances lately where it's not. (Also, the reason I "narrow down" the answers is because there are smaller "security" issues that tend to boil down to "admins can do anything", which is intentional.)

jboynyc 13y ago

FWIW, I just tried to update my dev site, the install failed, and now the site fails to load. Yikes. In all fairness, I think that's because the admin has been playing around with file permissions on the server side. I can't even log in right now to read the errlog.

8ig8 13y ago

Might as well link to the source of TNW's regurgitation: http://wordpress.org/news/2013/08/oscar/ http://wordpress.org/news/2013/08/oscar/