Live data from Hacker News

WordPress on .NET

peachpie.io

151–160 of 174 posts

Re: WordPress on .NET

#151

Earlier quoted context omitted.

PDO is disabled by default, and was even on default installs of 5.6 last I checked.

What "default"? Compiled from source? Debian package? 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.

I don't really understand your point. WordPress is ubiquitous. Until today I've never heard of MODX Revolution.

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.

Re: WordPress on .NET

#152
post #66

Earlier quoted context omitted.

Most of my work in the past few years has been migrating .NET projects to PHP for enterprise clients. Especially with PHP 7, the performance is good, it's easier to hire for, and the total cost of ownership is lower. The doomsayers predicting poor security are wrong - it is just as possible to build a secure PHP system as a secure .NET system, and just as easy to build an insecure one. Of course, it depends on the pr…

Not sure that's true. Out of the box ASP.NET has request validation enabled by default that screens out lots of opportunities for XSS https://www.owasp.org/index.php/ASP.NET_Request_Validation PHP doesn't have that for example.

> PHP doesn't have that for example.

Bare PHP, sure, but pick basically any framework that any modern PHP-based web app is built on and then it does, no?

Re: WordPress on .NET

#153
post #152

Earlier quoted context omitted.

Not sure that's true. Out of the box ASP.NET has request validation enabled by default that screens out lots of opportunities for XSS https://www.owasp.org/index.php/ASP.NET_Request_Validation PHP doesn't have that for example.

> PHP doesn't have that for example. Bare PHP, sure, but pick basically any framework that any modern PHP-based web app is built on and then it does, no?

Symfony certainly offers it.

Re: WordPress on .NET

#154
I can't file an issue on GitHub but the project is missing the license and the WordPress standard copy seems to have been removed.

Re: WordPress on .NET

#155

Earlier quoted context omitted.

I'll do you one better. 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 r…

How are you handling all the rendering that WP needs to do on a post (e.g. shortcodes, special HTML formatting, etc)? ... or are you just forcing your users to write Kramdown and leaving out things like shortcodes? IMO, the worst parts about Wordpress are: 1) complete coupling of data to PHP and 2) the absurdly terrible DB schema.

I disabled the default toolbar with shortcodes and replaced it with my own with Kramdown versions. I hooked the Add Media button to output Kramdown instead of HTML as well. Also we're having our editors write Kramdown.

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 '' first to preserve paragraphs.

Re: WordPress on .NET

#156
post #149

Earlier quoted context omitted.

I'll do you one better. 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 r…

I'd love to hear what problems you've had with the WP REST API. Always looking at ways to make it better.

Some of them are just bizarre. We have like 14 different WordPress sites with varying degrees of customization. Oddly, some of our most basic WordPress sites (basically zero plugins) would return _no results_ when querying for Posts. Especially in our Multisite instances. Especially in our sites that hook parse_request. Some others would return inconsistent results for the same queries. Custom post types would most-consistently not return sensible results. Entries in the wp_postmeta table stored via ACF Pro seemed essentially inaccessible.

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_") really should be replaced with a GUID.

Re: WordPress on .NET

#157

Earlier quoted context omitted.

Except… you don't? > 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.

PDO is disabled by default, and was even on default installs of 5.6 last I checked.

Most Linux/BSD distributions seem to separate out "core" PHP extensions (those that are distributed with php source, not via peel) into individual packages.

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/

Re: WordPress on .NET

#158

Earlier quoted context omitted.

What "default"? Compiled from source? Debian package? 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.

I don't really understand your point. WordPress is ubiquitous. Until today I've never heard of MODX Revolution. 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.

His/Her point was that if someone is still using shared hosting (where they can't change the extensions available) it would be very rare to find one that doesn't have PDO enabled.

> 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

Re: WordPress on .NET

#159
post #51

Earlier quoted context omitted.

The benchmarks http://www.peachpie.io/benchmarks show peachpie outperforming PHP7 easily by 100x.

Unfortunately those benchmarks don't compare against HHVM :/.

a few comments above said php7 was running without opcode cache, hhvm is even more about caching setups than php7...

Re: WordPress on .NET

#160
post #89

Several years ago I used to run a WordPress blog on IIS 7 using FastCGI. The performance wasn't great but acceptable for a small blog. Wonder how this compares.

It is faster
Post reply on HN