
WordPress 3.6 arrives with better post locking, built-in HTML5 media player - Lightning
http://thenextweb.com/apps/2013/08/02/wordpress-3-6-arrives-with-new-blog-centric-theme-better-post-locking-built-in-html5-media-player-and-more/
======
8ig8
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/)

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

~~~
bl00djack
I've also been wondering for a while now, what's the difference between those
two sites ( wordpress.com and wordpress.org) ??

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

------
sehrope
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-
int...](http://wp.tutsplus.com/articles/insights-into-wp-cron-an-introduction-
to-scheduling-tasks-in-wordpress/)

~~~
colinsidoti
The glory of this system is that WP retains their stupid easy install.

I suspect they pull down the data for whether a cron needs to be run in an
initializing query that also pulls down a ton of other data (site name, for
example). So in theory, they're only doing a few time comparisons of extra
work per request.

Also - I haven't looked too deep into WP's implementation, but are they
actually doing it on page load? I've seen it in other php software (I believe
phpBB) as a 1px image. This kinda solves the caching issues others are talking
about...your server might still get hung up, and that picture might never
load, but if you're cached properly I _think_ it won't stop anyone from
reading.

Ignoring the bugs though...I've had my shared hostgator plan handle a couple
of top page HN post with no additional caching installed, which makes me think
it's probably not a problem for most people running WP. (I just double checked
to make sure that's actually true, and it is.)

~~~
jacques_chester
> _So in theory, they 're only doing a few time comparisons of extra work per
> request._

And if a plugin has registered a long-running function, you're kinda screwed.

> _Also - I haven 't looked too deep into WP's implementation, but are they
> actually doing it on page load?_

Yep.

> _I 've had my shared hostgator plan handle a couple of top page HN post with
> no additional caching installed, which makes me think it's probably not a
> problem for most people running WP._

HostGator install WP Supercache by default.

------
dbarlett
Changelog:
[http://codex.wordpress.org/Version_3.6](http://codex.wordpress.org/Version_3.6)

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

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

~~~
hillbillyjack
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
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
Some plug-in and theme compatibility issues are also almost inevitable. Nobody
runs "vanilla" WordPress, after all.

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

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

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

~~~
rmccue
What serious exploits have popped up in WordPress lately?

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

~~~
jacques_chester
I hate Wordpress as much as the next fellow, but I'm wary of blaming them for
architectural constraints they can't control.

Plugins run in the same process, with the same privileges, because there is
basically no other way to do it.

OK, sure, you can do a kind of kabuki theatre where you present an API and
insist plugin authors use it. But then they can access everything anyway and
can find the MySQL login details by introspection. So it's pointless.

Another reason why I think apps should target virtual machines and be designed
from the OS up. In such a design you can isolate plugins as standalone users
and standalone processes.

~~~
stephenr
Plugins can only access "everything" because of the complete lack of
architecture or design. Wordpress is a series of ill thought out hacks,
extended by other hacks, extended by yet more hacks.

Every time one of our WP developers asks me to help with something (usually
they assume its a server config issue) I'm astounded at the shit I find when I
discover the source of the problem.

~~~
jacques_chester
Like I said, I don't like Wordpress either. But within the constraints of
shared hosting LAMP, guaranteed isolated processes are not possible. PHP adds
a lot of introspection, so anything declared anywhere can be read or changed.

Wordpress is not alone in this. It's the platform.

~~~
stephenr
You don't need isolated processes to have _better_ architecture and a sane
plugin model.

~~~
jacques_chester
We're still talking about different things. Yes, WP could be better. This is
demonstrable from other, better-designed engines within the LAMP/shared
constraints.

But no such system can prevent any plugins from doing whatever they want to
do.

~~~
stephenr
Introspection & Reflection in PHP _don 't_ expose everything, and frankly even
if they did, it would be quite easy to analyse plugins and have an approved
list of "safe" plugins that is used either as an advisory or as a basis for
the available plugins shown to a user.

