WordPress on .NET
peachpie.io
peachpie.io
[edit] If the author is looking, a few nitpicks from the website:
- A blank page is shown if browser doesn't load 3rd party scripts by default
- After enabling them, the scroll wheel doesn't work
- Typo: "free completely to use" -> "completely free to use"
- "Run PHP apps on the most secure platform available, Microsoft .NET" -> I also admire the platform but most secure? Comes off a bit too strong.
There aren't a lot of .NET exploits for a variety of reasons. Its pretty much the Java of the MS world so a lot of issues more liberal languages have, it doesn't, especially in regards to buffer overflows. Its attack surface is also pretty low as it only really inter-operates, by default, with a limited number of MS applications and is frequently the most common setup, while PHP supports anything and everything. Http.sys also seems like a more secure product than openssl.
That said, its also the minority platform so it benefits from a lack of effort to target it. I also worry that the closed nature of the platform could lead to someone(s) building up an army of zero days while the more open stuff gets discovered and disclosed faster. I'm not sure how realistic that fear is.
At my job we're always scrambling with our FOSS architecture in regards to emergency patching. The MS stuff is more or less 'do monthly patches and forget.'
.Net Core is 100% open source.
How is a goddamn HTTP parser in THE KERNEL more secure than a crypto/TLS library?
http.sys is a fundamentally horrendous idea, see CVE-2015-1635 https://technet.microsoft.com/library/security/MS15-034 An exploited HTTP parser shouldn't lead to RCE "in the context of the System account".
Historically, the schannel infrastructure has been secure, especially as compared to openssl.
>How is a goddamn HTTP parser in THE KERNEL more secure than a crypto/TLS library?
Because, lets face it, openssl is a shit project of legacy code no one wants to fix and https a design by committee standard no one can work well?
"Disable IIS kernel caching"
That's definitely not client-side at all. IIS is the thing that uses http.sys, and classic ASP.NET apps (not the new Core stuff) are usually deployed with IIS.
The number of config permutations in openssl is staggering, and that has to have an effect on the overall test coverage - which probably affects the number of bug that pass through testing.
They choose to heavily modify the C#/VB compiler (Roslyn) to handle php syntax. Microsoft should be investing time into helping them succeed, it would be great to see the Roslyn compiler platform become more broadly used.
And .NET is as free as php?
Weird times, huh?
Dapper for data access is also fantastic for the same reasons.
Disclaimer, I work on the UX/UI side of a company that focuses solely on sitecore.
Just the overall replication of Windows desktop for the backend management UI seemed a bit extreme. :)
People who develop in MVC tend to be developers.
Of course, it depends on the project and the company, so this isn't a universal truth. But there are definitely a lot of companies out there spending a fortune on a .NET stack that are looking to move to a PHP open source stack for good reasons.
Bare PHP, sure, but pick basically any framework that any modern PHP-based web app is built on and then it does, no?
Yes, there are objectively better languages than PHP in terms of design and consistency, but even I'll admit it's difficult to match the shear volume of FOSS libraries, applications, and the huge number of people who know it if you're targeting the web.
Besides, if Peachpie expands the .NET ecosystem to include PHP's, isn't that a win for developers who may be stuck with that platform? I'm not a .NET developer, so I'm sure to be missing something here.
Also, why would php-on-net be updated more often than one of the most used runtimes on the web?
Otherwise the .NET version only remedies vulnerabilities in php and not those in WordPress or its plugins.
Haven't used PHP or WordPress since 2010 so I might have missed something but to me this looks more like a tech demo then something one would use in a production environment.
In the end it's not like they're actively trying to ruin languages other than C# on their servers? Especially since that would ruin it for a lot of customers?
This all being said they're pretty transparent with their benchmarks. They supply all the code that they've used and are even comparing it to another project which aims to do the same.
I guess I'm just a bit angry because people are just saying "It's unfair" while they can easily do the tests themselves and then call someone out for it.
The context of the parent to which I originally replied was suggesting that .NET was 100x faster than PHP 7. So I'm pointing out that claim is rather like saying "I'm faster than Usain Bolt". You're right that I don't think the original article was making such a claim.
WordPress doesn't run 100X faster on Peachpie, but it'd be very interesting to see "real" benchmarks. Even a 2X improvement (vs the latest PHP 7, of course) would be compelling.
(which in the case of Wordpress can't be that hard)
The core code is OK, security wise. Comparible to similar projects, I guess.
The two major issues are that typically PHP runs with permission to modify the WordPress directory, which is useful for automatic upgrades, but means any exploit in any plugin, theme, etc. instantly becomes, "can replace WordPress".
The other is that all themes and plugins are completely unsandboxed, and the quality is extremely variable.
The permissions thing can be fixed, by running a very stripped down wp-php user with only read access to the code, and only write access to wp-contents/uploads (and a logging dir). Then you do automatic upgrades with wp-cli and (real) cron from a user with write access.
The quality of plugins and themes is not easily fixed.
The API for writing plugins and themes doesn't help. It's archaic, spaghetti, and doesn't have any kind of coherenc. Global functions like wp_is_home(), the_loop(), get_sitename(), etc.
I've come across themes which bundle joomla inside them as they're really joomla themes with a shim.
Since when is implementing your own home-grown shitty replacement for parameterised queries "OK"?
> WordPress also works with PHP 5.2.4+ and MySQL 5.0+, but these versions have reached official End Of Life and as such may expose your site to security vulnerabilities
> PDO ships with PHP 5.1, and is available as a PECL extension for PHP 5.0
Unless you mean "hosts that disabled PDO"… I think they can safely be ignored.
Just checked, seems enabled by default on FreeBSD.
(Commented out in php.ini doesn't mean disabled — here it's enabled in separate files like /usr/local/etc/php/ext-30-pdo_mysql.ini)
MODX Revolution uses PDO exclusively, never had problems with it on any hosting service.
Commented out in php.ini does mean disabled - as in not enabled. PDO isn't enabled by default in FreeBSD you still need to install a separate package for PDO.
> Commented out in php.ini does mean disabled - as in not enabled.
Not necessarily, as I explained here: https://news.ycombinator.com/item?id=13761550
So while PDO may not be installed by a plain `apt-get install php5` or similar, I doubt the now deprecated `mysql` extension is installed by "default" in those scenarios either.
Edit: this approach also means that the PDO extension in php.ini will be commented, because its loaded by a package specific ini file e.g. /etc/php/7.0/fpm/conf.d/* which are generally symlinks to /etc/php/7.0/mods-available/
Here's a hint: Wordpress since v3.3 needs PHP 5.2+. MySQLi was added in PHP 5.0, PDO in 5.1
WordPress v3.3 was released in 2011.
This must be an oxymoron since complexity is the enemy of security.
I think what you meant to say was
> WordPress security is at best ad-hoc, and mostly non-existing
> show me if security is improved! > (which for Wordpress can't be that hard)
that is, to say that the concept of 'WordPress Security' isn't a single simple thing to 'improve'. Unfortunately. If you wrote a set of 10 jillion tests and proved that wordpress core has no possible security vulnerabilities (humour me), that still would not fix 'WordPress Security'.
From a theoretical point of view, you're absolutely right, and I agree with you.
From a practical point of view, WordPress is often 'good enough', and 'works well enough', and has 'few enough security issues', for many people.
Improving security is great, but it's a complex, perhaps impossible problem.
http://www.cvedetails.com/vulnerability-list/vendor_id-2337/...
WP security is like Whac-A-Mole, you patch one serious issue and two more pop up. It has been like this for years which shows that the developers don't have the correct mindset to write internet facing code.
I pointed you to a SQL injection / remote execution vulnerability in the WP core, in 2017 for gods sake.
We're hosting a private-facing WordPress with several custom post types and some custom fields using ACF Pro. Then we pull directly out of the database with some not-too-complex and fast SQL queries and build a static site with Jekyll. The whole thing is about 200 lines of Ruby + a bunch of configuration for each post type. I'm working on making this a little more generic, because this thing really smokes.
In migrating to this, I'm doing a similar process with our previous mess of a WordPress site by pulling from the DB and writing JSON. WP All Import + ACF plugin takes care of the rest.
All uploads are now served out of S3 buckets and our editors write Kramdown now instead of HTML and inline CSS. We can easily A/B test or Multi-Armed Bandit now too.
It would have been a lot easier if the Wordpress REST API weren't a piece of junk. SQL is consistent at least.
Lastly, when pulling all the data, I determine if the post is HTML or Kramdown and use the Kramdown library to parse the HTML.
Everything migrated from the old site was automatically converted to Kramdown this same way and had to have some minor cleanup work done on each post. Not a small task on our main WordPress site with 7000+ posts/pages.
The interesting part was that wp_autop() happens at render time, so to get Kramdown to parse the HTML correctly, you actually have to RegExp replace '\n\n' with '<br /><br />' first to preserve paragraphs.
Most annoying though is that the API returns paginated posts but without returning data about how many posts there are or what page you're on. IIRC, there was a hard limit on returning max 100 posts per query. Might have been higher but significantly less than the number of posts we have. It was a total nonstarter unless we could guarantee that we could make and return enough queries to return all the posts before anything changed. With a 40+ content team that's impossible.
Sorry that I can't be more accurate than that right now.
Side note: I don't know if this has been said before, but ACF Pro is like the single most essential WordPress plugin for dev teams who know what they're doing. That plugin combined with some dev time replaces the need for like 99% of anything else that we would need to install. Please consider doing whatever it takes to make that plugin part of WP Core. Installing it on any site is a really sensible thing to do. That said, their field labels ("field_<somedigits>") really should be replaced with a GUID.
That said, I was really impressed by the improvement on require performance. The requests/sec also seem to have big gains.
I also wonder what security improvements other are expecting from this? Isn't unsecure code unsecure regardless of language?
Thanks for clarifying!
Wow those are interesting.
SQL Injection is still an issue if there are string concats every where and calling the DB, so that is something, that can still happen.
PHP 7.2 will make libsodium a core extension, so if you use that, you can make use of SipHash-2-4.
It's a much more light-hearted comment than you seem to think it is.
FWIW the comment in the movie is also a negative one.
> John Hammond: I don't think you're giving us our due credit. Our scientists have done things which nobody's ever done before...
> Dr. Ian Malcolm: Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn't stop to think if they should.
> John Hammond: Condors. Condors are on the verge of extinction...
> Dr. Ian Malcolm: [shaking his head] No...
> John Hammond: If I was to create a flock of condors on this island, you wouldn't have anything to say.
> Dr. Ian Malcolm: No, hold on. This isn't some species that was obliterated by deforestation, or the building of a dam. Dinosaurs had their shot, and nature selected them for extinction.
> John Hammond: I simply don't understand this Luddite attitude, especially from a scientist. I mean, how can we stand in the light of discovery, and not act?
> Dr. Ian Malcolm: What's so great about discovery? It's a violent, penetrative act that scars what it explores. What you call discovery, I call the rape of the natural world.
Wordpress powers a vast chunk of the web[1], whether we like that or not, and frameworks such as Symphony a good bit of the remainder.
For the love that Clojure, Rust etc get on HN their over-representation should not lead you to believe that 'PHP has had it's shot', PHP hasn't had it's shot by a long shot...
The reasonably good news here is that PHP code tends to have a rather short life-span so the bulk of it should die off relatively fast once there is an actual alternative.
That's the puzzling bit: even Ruby, python and all the other 'better' languages still don't have the deploy situation worked out to the point that PHP has.
I actually stand by the sentiment. Wordpress is a virus, and like jQuery, it has negatively impacted the development scene of the language is lives in. PHP, on the cusp of becoming a more respectable language (I freely admit my love for PHP, to this day, even though I primarily work in Java and Python now), was taken over by WP "developers" who flooded the market and sell themselves as engineers when all they can do is copypasta a few wordpress idioms.
I don't hate on wordpress itself, its a fine, though early on troubled codebase. The predatory community it has created, the security issues it continues to create, and the low-barrier to entry that floods the market with a ton of really bad code isn't something I would want to bring into another language's world.
And here's where the light-hearted part comes in... I know that projects like these would NEVER actually cause that kind of effect on their language because nobody would take it seriously... but the analogy of what COULD happen (you know, fictional, like ridiculous unrealism of the base concept of the movie) was apt.
I fail to understand why in a world so caught up in negativity and rigidness, people chose to not allow themselves to enjoy or notice light-hearted humor, and actively defend their stance against it, as if somehow eliminating light hearted jest is a benefit to a world already buried in such negativity...
If everybody that railed on others creations would instead spend the time to provide better alternatives then we wouldn't be having this discussion. But cheap shots are cheap and work is hard.
By the way, does anyone know of a similar project where the JVM is targeted instead?
i remember in 2003 wondering if something to allow php to run on jvm would be useful/viable - couldn't convince too many folks in the local user group that the idea had any merit.
The last one is probably the most useful and impressive.
As mentioned by sibling, not WP-specific, and benchmarks often lie, but better than nothing.
The nuget thing is inefficient, MS should plot a path to make npm a first class citizen in all ms tools.
I should have been more clear. I mean MS should work with Node/LAMP people to invest in one package manager more than the other. Like they did with TypeScript, they didn't just build a tool that linux people never used, they made useful tooling and also spent a lot of time bringing Google and others into the fold.
It makes sense to back npm because (guessing) it's used more than nu-get is used by VS devs. However if nu-get has a stronger ecosystem, stronger user base, etc choose it.
Having competition is usually good, but sometimes it just means it's more work to have to learn more/work more to get the same thing done (if you work across environments). Take instant messaging protocols, lots of competition but not even having cooperation has made the result terrible. Incompatibility everywhere, reinventing the wheel, etc.
To be sure some things are better not unified. We have multiple, un-unified browser engines and implementations which is critical. It improves competition, innovation and quality while still allowing surface level standardization in html/css/etc.
I try to look at each set of competing projects independently and ask: Overall is this helping, or it is mostly just wasting time as clients are forced to learn multiple techs.