An old (2.x) version of WordPress I worked on included an eval() statement that amounted to basically just doing variable assignment. I am sure there was some reason for this (probably not a good one), but it turned me off to the WordPress core. The fact that every WP release is quickly followed up with a patch for some critical remote code execution vulnerability tells me that there is something systematically wrong with its handling of user input and security.
Because of that, I moved off WordPress for personal blogging and onto Pelican [1]. You can't compromise static content.
IMO, if you're not going to enable comments or use hosted solutions like Disqus or Livefyre, static content generation really is the way to go and WP is massively overkill. I would say though, static content generators need to be far more user friendly - essentially idiot proof (at least idiot resistant?) - for them to see mass adoption.
It would be better for the overall health of the web if more independent publishers moved to static content.
I would also say, WP is not a blogging platform. It's ventured into the "Content Management Framework" realm with blogging "stuff" bolted on at this point. But PHP is still is the most ubiquitous and easiest environment for the novice (for better or for worse) so that's something to keep in mind as well.
> It would be better for the overall health of the web if more independent publishers moved to static content.
A CMS produces static content... Most sites use caching, serving static files... I think you are meaning that only static files should be put on the server because it's safer? I'd like to see that in action on anything other than a simple blog or site with more than a dozen pages.
> I would also say, WP is not a blogging platform
You're the first person I've heard say that, usually it is the opposite ("it's just a blogging platform"). Can you point to any development in the code base that has suddenly made WP less dedicated to blogging? WP is clearly very versatile, otherwise people wouldn't use it for everything. But there's nothing in the code base that has changed that de-emphasizes its blogging capabilities or focus.
The problem is that people that run 12 page websites are probably more likely to not keep up with upgrades, and to consequently have their sites broken, passwords gotten, etc.
The original comment is not quite right. It's not that WordPress is now a "CMS Framework" with blogging bolted onto it. It's actually the other way around: a CMS framework is bolted onto a simplistic and fairly faulty blogging platform.
If you use it as a blogging platform, or to run a mostly static site, sure it works. But try to actually build something on this "framework" and you'll run into all kinds of ugly. Things like BuddyPress, ecommerce plugins, etc. all are a mess because you can't turn a blog into a social network or an online store any easier than a Prius into an 18 wheeler.
And WP is not versatile. It's just that PHP has no rules. Anyone can do anything at any time. Don't want to wire proper plumbing into your framework to pass some variable to the right view? Just declare a global variable! Don't have access to the right set of posts? Query the database directly!
So my argument against WP is not that it's a bad blogging platform. It's that blogging is all that's it's good for, assuming you spend every minute of every day checking for security updates.
WordPress initial purpose was for blogging, later it grew along with demand and real world usage to become a more robust, capable versatile CMS. The blogging architecture is still front and center however. While there are definitely limitations to what WP should responsibly be used for, some folks like to hash out poorly constructed ones.
Take the security updates aspect - it doesn't matter software you use - it will need updating. A vigilant attitude toward security should be the default for serious sites, regardless of the software used.
Same with cars, they can suffer all kinds of problems if not properly maintained. You can't force the car owner to take the car into the shop to perform said maintenance. That doesn't make the car fundamentally bad.
When people say something to the effect 'WP isn't secure', it's often made as a blanket statement to make it sound like WP is fundamentally weak. There have been very little serious problems with WordPress core itself. Security concerns and exploits are the reality of any software that is widely used, WP is no exception, but it's to be expected. If anyone likes to share any powerful software in use that has millions of users and manages to evolve constantly and stay perfectly robust against any imaginable attack - I'd like to hear some examples.
Back in the real world, what counts is building useful products that matter to its end-users.
I've not your experience, neither never did go in deep with the core, but what I can tell: if the core is no good, then I'll will say nothing about the plugins.
Wordpress plugins, and the usage they get by (certain kind of) developers, have been my nightmare from the security and performance viewpoints, always I've been involved maintaining wordpress based solutions.
Anyway, wordpress is not the only web application affected by a this kind of bug (serialization, user input, eval, etc) in the late times.
Oh my god, the plugins!.. Yeah, those are even worse, since they are usually even less scrutinized, but run with the same privileges as the core WP code.
Pelican isn't exactly client-friendly and has far fewer features than WordPress. Pelican and the rest of the static-site generators might be great for developers or tech-savvy folks, but you'd be hard-pressed to sell the system to the average web client.
I think there's a decent opportunity for someone to build for a combination of a static site generator with a clean web administrative backend and API for dynamic content (forms, discussion, social network stuff, etc). Of course, the admin backend would be a target but would at least be a smaller attack surface.
I don't get the logic here. All major software suffers from exploits and code that needs patching. You can make the case that the browser itself is the weakest link in the chain to start with...yet nobody's abandoning their browser of choice and replacing it with something vastly less capable.
I'm not sure there is a single software package that is powerful and popular that doesn't receive post-release updates and patches. If you want to convince a person to get off the software on to an alternative, it would have to at least approximate its capabilities. Moving to Pelican from WordPress is like ditching a computer for a calculator. If all you want to do is add and subtract, that's fine...but come on.
I'm surprised that the fix in Wordpress wasn't explicitly marking fields that need to be serialized/unserialized, instead of second-guessing based on the broken promise by MySQL.
> MySQL replaces characters it doesn’t recognize (for the given character set), with a placeholder. MySQL will sometimes replace byte sequences with “?” or “�” (U+FFFD). Such replacements would not be harmful.
This is so wrong. A database must never change any data that it's asked to stored. Wordpress, and other applications, always make that assumption, and when it isn't true anymore all hell breaks loose.
PS: it blows my mind that it looks like strpos in PHP could return either boolean or integer [1].
Would you rather return it -1 or something else? You are gonna need a comparison in any case because you can get 0 offset. Return type doesn't matter as much because php has dynamic typing. Pretend it is Option[Int] if you will.
I would also like to use this moment to go on a tangent with my unwilling audience that, not wasting any remote opportunity to badmouth php, or any other language for that matter, just for its standard library or trying to not break as much legacy code as possible, is bad form. Sure language syntax itself may suck, semantics may suck, I am always up for a good PL flamewar. If you want to bash the library, don't blame the language itself for the poor choices of the library.
cryptbe, I would like to apologise in advance and humbly request you to not take this personally.
I'm always sort of flabbergasted when I see PHP programmers doing this "maybe_xyz" stuff. I recall there's a PHP api for escaping stuff that has weird options for either allowing "double escaping" or ignoring successive invocations. It screams amateur hour to say "uh, i have a string, and I don't know if it's escaped yet, so I'll just call this API that escapes it because it magically avoids 'double escaping' for me." There's no such thing as "double escaping" -- it's just "escaping". The fact that you might be escaping something that appears to be an already-escaped string is irrelevant. If you are dealing with user input strings and you don't know for sure whether a string is escaped or not (or how many times), you are probably writing a security hole somewhere.
Fair enough. It's funny how angry I get when I think of someone needing an "escape_once" function or "is_serialized". I think this discussion might have to become part of my interview process, because if someone doesn't understand the absolute undeniable terribleness of trying to determine if a string has been escaped or serialized by inspecting its contents, then I really don't want them in my code.
a lot of php functions are like this due to the fact that 0 evaluates to false. They need to return boolean false so you can do a strict comparison to determine between failure and a result of 0
Because of that, I moved off WordPress for personal blogging and onto Pelican [1]. You can't compromise static content.
[1] http://docs.getpelican.com/en/3.2/