
The Whole of WordPress Compiled to .NET Core and a NuGet Package with PeachPie - ihsw2
https://www.hanselman.com/blog/TheWholeOfWordPressCompiledToNETCoreAndANuGetPackageWithPeachPie.aspx
======
ckluis
It 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.

~~~
sodosopa
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

~~~
laken
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).

~~~
sodosopa
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?

~~~
laken
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...](https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+is%3Aissue+label%3AAccessibility+milestone%3A%22Merge+Proposal%3A+Accessibility%22)

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...](https://github.com/WordPress/gutenberg/issues?page=1&q=is%3Aopen+is%3Aissue+label%3AAccessibility&utf8=%E2%9C%93)

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.

~~~
sodosopa
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/](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).

~~~
laken
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

------
wordpressdev
So, what's the WordPress equivalent in Python?

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

~~~
wordpressdev
Wagtail looks good. Wonder what's the learning curve from someone coming from
WordPress development background.

------
Nelkins
CLR is really earning its name with this one.

------
petra
Can this solve the Wordpress security nightmare ? are we going to see hosting
services built on PeachPie in the near future ?

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

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

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

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

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

~~~
stephenr
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...](https://blog.ircmaxell.com/2017/10/disclosure-wordpress-wpdb-sql-
injection-technical.html#The-Correct-Fix)

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?

------
hbcondo714
To push the MS stack further, integrate with Project Nami (Wordpress on SQL
Server)

[https://projectnami.org](https://projectnami.org)

~~~
pchp
That's an awesome idea. Will do!

------
skunkworker
This seems like an interesting alternative direction like what HHVM was trying
to accomplish.

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

------
wpdev_63
It would be amazing if they rewrote wordpress in C# using modern design
patterns.

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

~~~
radium3d
Do you have any examples of the bad practices you are referring to?

~~~
sebazzz
Probably the use of globals etc. This might also be a backwards compatibility
thing though.

~~~
akerro
Developing anything for wordpress is a nightmare, it's not only PHP-nightmare,
but also plenty of bad practices, poor API, wired workarounds...

------
whatyoucantsay
A fractal abomination.

------
brian_herman
This is great!

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

~~~
mgkimsal
"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.

~~~
abritinthebay
> _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.

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

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

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

------
alexandernst
Holy mother of the pile of crap this thing must be...

~~~
ihsw2
We were so preoccupied with whether or not we could, we didn't stop to think
if we should.

~~~
dbwest
Reminds me of 'Phuby on Phails', Ruby on Rails in PHP...just because. I think
the WTFF is about the same (off the charts).

~~~
egypturnash
[http://adrianzandberg.pl/cobol-on-
wheelchair/](http://adrianzandberg.pl/cobol-on-wheelchair/)

