The Whole of WordPress Compiled to .NET Core and a NuGet Package with PeachPie
hanselman.comIt would be interesting if someone ripped out the php/js for the gutenberg editor from wordpress as a compiled .net core wysiwyg-block-based editor for use in other .net core projects.
now if they only made gutenberg stick to wcag 2.1 or Section 508, it could change the world. Otherwise, it's not too different from the Frontpages or NetObjects Fusions of the past
I'm a contributor to the WordPress A11y team, and trust us, we are trying. It's an a11y nightmare, and the majority of contributors to Gutenberg seem to not care. The goal is for it to meet WCAG 2.0 on merge, but that's running close. The majority of Gutenberg contributors think of the a11y issues as "low priority."
Because you sound like you know a bit about a11y, we could really use a hand. Accessibility meetings are weekly in the Make WordPress.org Slack instance. One of the problems is that Gutenberg's technology is very different than the rest of WordPress core, so some of the a11y contributors to WordPress Core are staying away from code-contributions to Gutenberg because of that (myself included). I've been playing around with node.js a bit to try and contribute, but it's very different than what I'm used to (PHP).
Thanks for the response. I think most web devs have always treated accessibility as "low priority". It's not top of mind until it becomes a part of your daily job. I've been there.
How close is it to 2.0 A, currently?
It's tricky to even tell now, unfortunately.
These are the issues that are remaining that we (the a11y team) want fixed prior to merge: https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is...
When these issues were added to the merge proposal, they were what were left for 2.0 level A. But accessibility regressions have gotten introduced many times now while other developers are working on things from other merge proposals. We were doing some tests with users of various assistive technologies, and these were also the problem areas for them.
Here are the open a11y issues for Gutenberg in general: https://github.com/WordPress/gutenberg/issues?page=1&q=is%3A...
A lot of these are still quite important. The UI is also super confusing, as it's an entirely new type of UI, and it's confusing to figure out where everything is if you can't see it. We are working on some documentation that describes it for assistive-technology users, as it's virtually impossible for them to infer how it works.
from earlier today "WordPress aims to make the WordPress Admin and bundled themes fully WCAG 2.0 AA compliant where possible."
https://wordpress.org/about/accessibility/
The jump from A to AA is difficult and to put the statement of AA out there, is bold (and probably naive).
Yes, that’s our new accessibility page!
I’ve heard the argument by many though that if someone needs WCAG AA, that they can just use the classic editor (which will be supported via a plugin maintained by wp.org). Will be interesting to see how it all plays out
I would like to see Beaver Builder do this, too.
So, what's the WordPress equivalent in Python?
Wagtail.
There's also a very nice library that can dump all the pages from Wagtail into a static site which you can then just copy to a CDN, giving you the best of both worlds: The ease of publishing of dynamic sites and the speed/ease of deployment of static sites.
Wagtail looks good. Wonder what's the learning curve from someone coming from WordPress development background.
Jekyll or Django, or a hybrid?
Not even close. That's like saying that the alternative to Photoshop is C++.
Agreed. Django gives you the tools to build applications, wordpress is a point and click setup for most people. The users are extremely different audiences.
That might be a bit harsh. Closer comparison might be photoshop to gimp?
Not really. Gimp is still an image editor.
Django is your GUI/imaging framework and libraries if you’re going to make that comparison.
Jekyll is closer to Wordpress but Django is a library / framework so Photoshop to C++ is kinda close, but a little too far.
I'm thinking "django cms", not just django - sorry. colleague of mine has been doing a lot of work in django cms the last year and I conflate the two sometimes :)
Huh. Django cms actually looks pretty nice.
Ah makes more sense.
CLR is really earning its name with this one.
To push the MS stack further, integrate with Project Nami (Wordpress on SQL Server)
That's an awesome idea. Will do!
Can this solve the Wordpress security nightmare ? are we going to see hosting services built on PeachPie in the near future ?
Saying Wordpress is a security nightmare is like saying Windows is a security nightmare. It has broad use, it has tons of people using it with outdated or unmanaged plugins on installs that haven't been updated in years...Some running near extinct PHP versions. If managed properly, put behind a firewall, etc it is quite safe. The hatred of Wordpress is laughable. It has its limits, but it meets most small-medium sized business needs when the project calls for minimal needs.
As a product you're right - Wordpress serves the needs of small business and non-coder users perfectly well, arguably better than any alternative outside of hosted services like Wix (or, obviously, hosted Wordpress.)
However, as software, Wordpress deserves the hate it gets. There is no real security or firewalling or permissions limiting of plugins, there is no hint of modern PHP practices like Composer integration, routing, or the use of a templating language (and no, PHP itself doesn't count) and the amount of cruft it carries with it for the sake of backwards compatibility makes it insanely complex and far more bloated than it needs to be.
Wordpress in principle is a wonderful, useful product, and anyone trying to compete with it needs to closely study what it gets right (ease of deployment, ease of extension, ease of configuration, auto-updates, plugins, etc.) as well as what it gets wrong. Wordpress in practice, though, needs to be tossed into a pit and burned.
> "(ease of deployment, ease of extension, ease of configuration, auto-updates, plugins, etc.)"
But those are The Right __and__ The Wrong.
For example, adding Composer to the WP "stack" makes sense. But now you've eliminated 90% (?) of the WP "developers."
That is, in the Universe of WordPress Composer is more friction, not less (i.e., ease of use).
Long to short, for better or worse, WP is Justin Bieber. It will never be Radiohead.
>But now you've eliminated 90% (?) of the WP "developers."
Maybe, but it wouldn't be impossible to rebuild plugins around Composer and PSR standards. And doing so would make them better organized, and make it easier to manage third party dependencies. If you were going to build Wordpress from scratch, today, that's probably what you would do - just make plugins a special case of Composer dependencies.
The only question is, whether you would still have as robust an ecosystem with a more restrictive framework? Probably not, but the quality of plugins would probably be higher.
I think before we worry about plugins and themes it would make much more sense to bring WP core itself up to date. What good is a nice, clean, properly organized plugin, if it's sitting on a foundation of sand.
I filed a core bug report once. Long to short, if I passed (I think it was) false to a core function, I got very unexpected results. The dev that replied to me said, "Well then don't do that." Huh?
The idea that the function should check, that it should be aware that humans (and their code) make unexpected mistakes, was completely foreign to her / him. I lost a lot of faith that day. I lose a bit more every time I go poking around in core code. I'm no Super DevMan. So when __I__ see bad patterns you know something is wrong.
p.s. Fwiw, even the lead dog (i.e., Automattic) has some nasty code habits. Simply dumbfounding.
The bulk of WP security issues stem from the 'writable file system' defaults that many plugins (and, to some extent) core either expect or encourage.
I can't say all, but the huge bulk of security issues I've seen revolve around some exploit which ends up writing a new file, or overwriting an existing file, which is then publicly accessible. If your file system is not writable, the large majority of WP exploits go away. However, you lose the "press here to upgrade your entire site and all the plugins in one easy step!" functionality, and the "upload files via the browser" ease-of-use.
If you're truly modifying public media files on regular basis, a non-writeable file system kinda stinks (either make the FS writeable or use an external media host, which adds complexity and cost). MOST systems I run in to aren't doing this often - it's "put up the site and updates some pages every few months" (or, blogging, which is often just text). For these, I recommend turning off write permissions to the whole of the WP system, and periodically turning it back on to do updates, then turning it off again.
Yes, this doesn't cover 100% of exploit cases, but nothing does, and I've found this to go a moderately long way to reduce the impact of various exploit attempts.
So, to answer the question, I would say "it depends". If the .net hosted version also by default allows for writeable media that is also executable, then there would be problems. However, I don't expect a .net-based system would allow you to get a ".aspx" file in a publicly accessible URL and have it just execute when accessed (unless there's some deployment mode that would allow for that?)
PeachPie doesn't allow this. We will enable the option once on-the-fly compilation will be implemented, but this is really really poor practice and we highly discourage the use of it.
if there's a way you can enable writeable file sytem, but not compilation of anything executable, that may end up being the best of both worlds.
WP could address some of this by requiring plugin media/js assets to be copied over to public folders during an 'init' process, while requiring the core PHP code to be outside of the document root/public area. But it would break on certain hosting platforms (I know that years ago, Plesk templates would enforce that nothing could live outside the document root - every upgrade they'd change all PHP permissions to only allow PHP execution inside the document root, perpetuating poor security practices for anyone who wanted to host on plesk-managed servers).
This can only be solved by a rewrite.
Which nightmare? Maybe we can fix it. To answer your second question - yes, that's exactly what we're planning :)
Wordpress core has very secure coding practices, and if you can find an 0-day in it, then you've done very, very well.
The problems with Wordpress are mostly:
1. WP installations are often not properly configured or maintained.
2. The plugin ecosystem is a mess of vulnerable and/or malicious code, or simply dead code that isn't maintained yet still deployed in the wild.
It took more than 7 months to fix https://blog.ripstech.com/2018/wordpress-file-delete-to-code... and at the time rips went public with it (after waiting for 7 months) it still was not fixed.
That a POST param even was used to as the path to a file to delete without sanitizing it is not usually indicative of "secure coding practices".
Writing your own userland implementation of prameterised queries is what you consider “very secure”?
I’d hate to see what you think is terrible then.
What exactly is your criticism here? Do you know of some issue with prepare()? The quality of the core Wordpress code is quite high. You could argue that the plugin system is a footgun, but it’s kinda an essential element if you want extensibility.
Parameterised queries done properly are sent to the database server specifically as a query with placeholders and values - the values are never evaluated as sql, there is no chance for a userland bug/attack to perform sql injection using them.
What wordpress does is basically glorified printf, substituting values into a string.
If you can’t see how this is a danger, you’re in no position to comment on the quality of the code.
Right, so you actually have absolutely nothing to say about the quality of wpdb.
My point stands. The worst problems in Wordpress are the plugin ecosystem and poorly maintained instances.
Just because you choose to ignore valid criticism, that doesnt mean there is no criticism.
Go read https://blog.ircmaxell.com/2017/10/disclosure-wordpress-wpdb...
A couple of little snippets to highlight the point I'm trying to make:
> The current system is insecure-by-design. That doesn’t mean it’s always hackable, but it means you have to actively work to make it not attackable. It’s better to switch to a design that’s secure-by-default and make the insecure the exceptional case.
> The best path forward would be to switch to PDO/MySQLi and use real prepared statements and not emulate them in PHP land. That’s the best path forward.
But given that the core wordpress team basically ignore this type of suggestion from PHP core contributors, why would I expect you to believe me about it here?
This seems like an interesting alternative direction like what HHVM was trying to accomplish.
PHP7 is faster than HHVM nowdays, and looking at the benchmarks for this .net version it's not a whole lot faster. It could even be that part of the win here comes from not needing to check all the php files on disk for changes.
It would be amazing if they rewrote wordpress in C# using modern design patterns.
You could take “C#” out of that sentence and still be accurate.
Wordpress is not and I imagine never will be anywhere close to “modern design patterns”.
It’s not even close to old design patterns, unless Heinz has a namesake software design pattern.
Wordpress uses practices that were considered a bad idea a decade or more ago, and still refuses to change.
You can also take "modern design patterns" out of that sentence and still be accurate. Its usually just a form of cargo-cult-programming that hasn't been found out to be terrible yet.
For clients and writing actual content nothing beats Wordpress. The editor is great and a lot of people have used it before so, from a developer point of view, I believe that with Wordpress you should give people what they want. The alternative of demanding they use some 'better' CMS means that the content never gets written or updated.
However, not to disrespect the work that has gone into Wordpress, how hard can it be to write something better for the frontend and get marketplace adoption?
I do not like the frontend 'coding standards' and mess of plugins. Starting straight from the raw wp_ mySQL tables is a less insurmountable task than hacking some theme and bloating it out with 'jQuery' plugins that should never have been plugins. It seems that it is the ecosystem of design agencies with their lorem-ipsum big-up-front-designs and allegedly 'agile' workflows that have made Wordpress into something I do not like working with. Particularly when the add-ins make the backend far removed from sensible, making it a nightmare CMS for clients.
Hasn't anyone written a decent frontend for it that is not a tacky theme with ten thousand lines of CSS of which 97% is not used and a megabyte of scripts to get the carousel and share links working?
> how hard can it be
Hard.
Very hard. Especially because you first have to pick something as well installed and supported on hosts as PHP to even get traction. Good luck there.
Then you need to be at least as good in most or all features on launch to get any mindshare. Hope you have a few years to work on this side project before you release...
There have been plenty of attempts and of them all Ghost is about the only one to be taken seriously it seems and it’s niche at best (and not yet at the same level of features or ease of use & configuration).
So yeah, the answer is hard. Harder than you think.
Just considering the wp text editing box in isolation, it's a hideous masterpiece of a thing, that, alone, would take forever to rebuild.
"refuse to change"? It's not easy to change something used by more than 50% of the internet.
Do you have any examples of the bad practices you are referring to?
Examples include: use of globals, inefficient queries, mixed templating, lack of namespacing, doesn't follow PSR standards.
They actively refuse to use parameterised sql queries, opting for their own home baked userland implementation instead.
Probably the use of globals etc. This might also be a backwards compatibility thing though.
Developing anything for wordpress is a nightmare, it's not only PHP-nightmare, but also plenty of bad practices, poor API, wired workarounds...
Then perhaps, in true open source fashion, you can put your time where your opinions are and either start another project or help the wordpress team to correct what you think is bad.
There are already lots of CMSes out there.
Changing WP to use more modern design patterns (whatever that would entail) probably means breaking all themes and plugins, which isn't acceptable (and even if that wasn't an issue, I doubt the WP maintainers would just accept a PR that completely rewrites everything). This isn't really a thing random contributors can help with.
In the sense that (IMO) most people don’t need Wordpress, I am, I am (slowly) working on (yes another) static site generator.
But, in response to your general theory: I can criticise a car as being fucking terrible without someone suggesting I “go build my own then”.
The first step should to be to rewrite in PHP 7 using modern design patterns. I don't think C# would add much there.
One of the major selling points of WordPress is its huge array of 3rd party plugins. You'd need to port the most popular ones before the C# version got any traction.
How's Linux for .NET hosting? Because Linux hosts are generally cheaper than Windows hosts.
> How's Linux for .NET hosting?
For .NET Core there are binary packages [1] for Debian/Ubuntu, Fedora, Red Hat and SUSE, so you can apt-get/rpm/yum hosting environment in a matter of minutes. I'd say it's easier to set up and run ASP.NET Core app with Apache or nginx as reverse proxy than with IIS. For "old" .NET you are stuck with Mono [2] which works okay-ish if you don't use Windows-only dependencies.
[1] https://www.microsoft.com/net/download/linux-package-manager...
I've been having great luck with ASP.NET core / nginx. Very stable, low overhead with 40k req/sec served in a ubuntu VM. I hate MVC, so I've been using Nancy (Sinatra based) as the web framework. I'm highly confident in .NET Core being production ready.
The avantage of php for a self hosted bloging website is that php is installed in almost every hosted server and that makes WordPress easy to install.
Decompile the resulting library and start refactoring and adding comments?
Why would you start with a decompiled binary when the source code is available?
Because then you don’t need to look at the source code
A fractal abomination.
This is great!
Alot if shitty attitudes about Wordpress here.
If it is so awful, why is it on over 25% of sites?
It has helped alot of people make alot of money, and continues to do so.
"If it is so awful, why is it on over 25% of sites?"
If McDonalds is so bad for you, why do they serve 550 million Big Macs every year?
WP is 'free', has a low barrier to entry, and for many years non-developers were able to relatively easily add custom functionality (sometimes done well, but often security and performance nightmares).
A lot of people make a lot of money from selling illegal drugs, or fatty foods, or bad investment/insurance products.
WP has its place, and in the right skilled hands, for the right projects, addresses many business needs decently well. Until it doesn't.
But this "right tool for the right job" argument has been beaten to death when it comes to WP. Biggest 'meta' issue I see with WP is that it doesn't do much to encourage most people "developing" on it to ever consider other tools; they just learn to fit more and more jobs in to the same ecosystem, whether it's a good fit or not. And due to the size of the ecosystem, it has enough gravity to keep attracting people to it.
> "I see with WP is that it doesn't do mauch to encourage most people "developing" on it to ever consider other tools; they just learn to fit more and more jobs in to the same ecosystem, whether it's a good fit or not."
Spot on. I do a fair amount of WP work. I'm a member of a number of WP groups on FB. I see this all the time. For most people WP is a hammer and everything is a nail.
Unfortunately, that's the Kool Aid served by Matt M all the way down. WP isn't an OSS application. It's a cult.
To the majority of the cult members there's nothing else. They know nothing other than WP. Truth be told, most of them don't even know WP.
> If McDonalds is so bad for you, why do they serve 550 million Big Macs every year?
This is an amazingly good comparison because in both cases the initial assumption is wrong.
Just like WP, McDonalds is not bad for you intrinsically. It’s poor discipline and usage that causes problems.
I might go further a bit because large fast food companies engineer the food to be ... addictive in some capacity. And the WP ecosystem is relatively addictive. "Just one more plugin and these 3 problems will be solved!" Per comment above - I inherited a site with around 60 active plugins. The team before just ... added a plugin for every single problem they encountered. Because... point and click? No experience with any other ways of solving problems?
People who've been raised on fast/processed foods, and may never have actually done any cooking themselves, honestly may not even understand the problems with the food they're eating, or what the alternatives are. Yeah, 'home cooking' is more initially expensive (need some basics tools, place to store ingredients, keep them fresh, etc), and certainly more time up front learning how to cook certain things. But... you know what's in the food you've prepared. And you have knowledge and skills that can serve you for a long time.
To be fair, even if you cook for yourself, you still don't know with 100% certainty unless you grow your own crops and animals. When I buy sausages, I'm not exactly sure what's in it, all I can do is pray and hope for the best.
Was thinking that when I was writing that. yeah, you can't always know, and sometimes, you actually do know that there will be pesticides/chemicals/etc that you can't avoid (even if you grow your own stuff, there's crap in the air/soil/water beyond our direct control). In some sense, that's, at very best, no worse than getting food from anywhere else, but it's problematic.
There is nothing good for you at McDonalds. Even thier “healthy” options are less healthy and over processed compared to local restaurants.
The apples are okay.
the coffee and water and juices aren't too bad either. :)
Juices are higher in sugar and calories than soda....
but they're not generally 'less healthy' than a glass of juice from a local restaurant.
A poor comparison. McDonalds is highly variable per location. Just because the one closest to you might be terrible doesn't say anything about the rest of the world.
food, not service. mcdonalds food is about as 'same' as you can get per location around the globe.
The point being, no it's not.
He said terrible for you, not terrible.
WP is really extensible. The way hooks and filters work and the way they are used trough the codebase allows you to completely alter and change virtually every aspect of the software. That includes everything from the admin UI to the processing and displaying of content. None of the modern alternatives are remotely as powerful and versatile as WP is.
if you're a developer, or have a development team, loads of options are even more extensible and versatile. and those options would all come with more flexible deployment, testing and scalability options.
if you're not big in to development, you're reliant on a plethora of plugins, and you need to hope that the dozens of plugins you tie together know how to play nicely together. I'd run in to multiple situations where poorly built plugins for plugins were hacked on and then conflicted with other plugins - everyone pointed the finger at someone else. and then the standard support line from a couple vendors (these were plugins with paid support, btw) - "disable 100% of all your plugins, then enable them one by one to see where the problem is". Sweet.
And when I tell people I inherited a wp site with just shy of 60 plugins, few people actually believe me. "I would never do that! I would never built anything with more than 4 (substitute with various numbers representing experience levels of people) plugins - that's all anyone ever needs!"
When it works well, it works well. When it doesn't, it's a bloody nightmare.
Speaking from experience in nation-wide digital media— you're dead spot on.
I have seen sites with 60+ WP plugins enabled. Many outdated, many hacked upon (and poorly, with no documentation). Even the WP instances were modified just slightly and had convoluted build processes that nobody on the current teams could explain (again, with no documentation. Or rather documentation was "TBD" circa 2010).
And all of those WP instances either shared configurations and root style sheets or ran as a multi-site on a single machine with Nginx in front of it only using a mix of Akamai, Cloudflare, and Brightcove to handle some, but not all, non-print media.
The sites were consistently being exploited and having porn uploaded. Issues like that were usually caught quickly enough, but that kind of operation kept the teams busy with patching holes rather than improving performance.
Last I checked their WP sites downloaded 20 Mb of scripts alone on a fresh load, and 6mb thereafter.
Bloody nightmare is right.
Wordpress is the Microsoft Access of content-driven Websites: it is amazing because the lowers all of the barriers to entry (time, cost, expertise), but it has bad practices and a bad programming language built-in, so stuff built with it is born bad, and will get worse, partly because the folks using that tool are frequently untrained.
Think of any modern development best practice that you like (e.g. version control, or automated tests): Wordpress will make it harder, and if you take over an existing Wordpress site, there's a non-zero chance that the previous developer wasn't doing it, making the hairball of code underneath the shiny interface even harder to work with.
Take a look at roots.io
The problem's normally not Wordpress itself (when kept updated), it's the trash fire of plugins that float around it, leaving all sorts of security issues in their wake.
if you actively encourage and enable an ecosystem, you have some kind of responsibility. maybe less that the person who installed it, but the whole WP thing is for non-technical people. it’s still ethically questionable and shameful
Holy mother of the pile of crap this thing must be...
We were so preoccupied with whether or not we could, we didn't stop to think if we should.
Reminds me of 'Phuby on Phails', Ruby on Rails in PHP...just because. I think the WTFF is about the same (off the charts).
Aaah, it's always nice to see a well-placed JP quote :)
I raise you another:
God help us; we're in the hands of engineers.As much as I love .NET I think, it is not the right thing to run PHP apps on it. PHP is good on its own.
However, Peachpie seems like an awesome showcase what is possible in modern environments and apps.