Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The dire state of WordPress

jshakespeare.com

Post reply on HN
Print view View original

121–130 of 162 posts

Re: The dire state of WordPress

#121

Post by stephen_mcd »

FilterJoe wrote: post #74
JVIDEL wrote: post #59

Earlier quoted context omitted.

Some cloud providers have auto-installers, its all paid though.

Can you name 1 or more cloud providers that have auto installers for Mezzanine? I'm not aware of any. Here's a post from 4 months ago comparing installing Mezzanine on a number of PaaS providers. None seemed anywhere close to as simple as installing Wordpress on Bluehost: http://appsembler.com/blog/paas-bakeoff-comparing-stackato-o... Read the comments and you'll find out that Mezzanine isn't yet compatible with Djan…

Mezzanine lead developer here.

We'd been tracking Django 1.5 changes during the release candidates and were mostly compatibile with it up until its release. When it was released, a few issues cropped up - those were resolved within a day or two, so there was a brief period where it was incompatible with 1.5, but that's no longer true.

So it was incompatible with 1.5 for less than 48 hours. Latest version works fine against 1.5, enjoy :-)

Re: The dire state of WordPress

#122

Post by stephen_mcd »

FilterJoe wrote: post #46
jsdalton wrote: post #7

To paraphrase Churchill, Wordpress is the worst CMS -- except for all the others. I'd love to find an open-source CMS (preferably in Python or Ruby) with clean, secure, elegant code and a well-organized framework that comes with a friendly admin and active, responsive development community like Wordpress, but so far I've got nothing. (If anyone has any suggestions, please do feel free to share them!)

Mezzanine is quite nice: http://mezzanine.jupo.org/ It's Python (a Django app). BSD license. It has many advantages over Wordpress that I won't get into here, but all this is offset by one massive disadvantage: It rests on the Django framework. Django is a nice framework for web development but it takes at least a few months to learn for someone starting from scratch. The installation process for Mezzanine requires s…

Mezzanine contains a fabric installation that can take a vanilla ubuntu install, and have a production server up and running with Postgres, memcached, et al, in a single command:

http://mezzanine.jupo.org/docs/deployment.html#fabric

I believe this is actually easier than deploying Wordpress to production.

Re: The dire state of WordPress

#123

Post by brandondghill »

mildweed wrote: post #62

Wordpress is making big steps in the right direction. * Their wild pile of oddly-named functions are being deprecated and moved into well-designed classes. * Better templating options are being promoted. * Yes, the global $wp_query leaves some to be desired, but at its core, wpdb's WP_Query is a decently powerful database abstraction, and if used right can perform well at scale. No, the hooks aren't going away, nor i…

> * Their wild pile of oddly-named functions are being deprecated and moved into well-designed classes.

> * Better templating options are being promoted.

Highly debatable. Ever made an admin page? There's a laughable number of callbacks required just for a single input.

Re: The dire state of WordPress

#124

Post by chrisguitarguy »

mikepurvis wrote: post #89
EwanToo wrote: post #8

Earlier quoted context omitted.

And don't forget the amazing amount of functionality that's available for free using the plugin system. It's a classic software development problem - Wordpress's complexity is both it's strength and weakness, and will probably be it's downfall one day (but not just yet)

I've found plugins to be extremely hit-and-miss, though. I was helping a photographer friend who bought a commercial theme, which broke admin-side Javascript when he did the 3.4 -> 3.5.1 update. We still haven't figured out exactly what happened, but it just reinforced for me again that a) Wordpress hasn't adequately documented which APIs are stable and not, b) Authors, even of paid add-ons, don't keep their stuff up…

The theme replaced jQuery bundled with WordPress with some external version (eg. Google hosted or otherwise) and did it so on both the admin and front end. That's usually the cause of those sort of issues. 3.4 -> 3.5 brought up a lot of JS compatibility.

Look in the theme's directory for `wp_deregister_script` and see if anything was deregistered and re-registered (`wp_register_script`).

> Wordpress hasn't adequately documented which APIs are stable and not

If it's it in a major release, it's stable. When you buy any piece of software you're relying on its author knowing "the right thing to do (tm)". The author of the commercial theme thought it was okay to replace some bit of core javascript and din't bother to check on it. Or they didn't bother to be specific about it -- only do custom JS stuff on their theme's options page or on the front end. It's easy to do that, but you have to know how to do it (it's not documented in the Codex).

Re: The dire state of WordPress

#125

Post by ErikGelderblom »

To ease out some of the pains James writes about, I created a bare Wordpress repo that is designed to separate content, media and wordpress' own files so it works better with git, git submodules and deployment with ie. capistrano.

https://github.com/ErikFontanel/Wordpress-Corpse

please fork and adjust it to your own likings!

Re: The dire state of WordPress

#126

Post by pjbrunet »

Most people using WordPress are not developers. So naming conventions that might make sense to you don't apply to the average user.

It's called "wp-content" because that's where all personal, custom stuff goes--all your photos, plugins, etc. (Not including your MySQL data.) When you upgrade WordPress (which wasn't always automatic) your "content" is left untouched--because you want your own stuff apart from the rest of the application. The other directories, more or less, are owned by the core developers and Automattic.

Since 2004 when I started blogging, I've watched WordPress add so many bells and whistles. It's the opposite of what made it appealing in the first place, an elegant "poem" of an application. Now with so many developers working on it, it tries to be all things to all people.

What's interesting to me, to see websites outgrow WordPress. Sometimes your content expands such that WordPress can't deal with it. WordPress is a one-size-fits-all solution and that's ultimately limiting. At that point you can contact someone like me to create a custom application from scratch that just does what you want--not 1000 extra things you don't want, yet preserving your URLs for SEO, etc.

Re: The dire state of WordPress

#127

Post by chrisguitarguy »

brandondghill wrote: post #123
mildweed wrote: post #62

Wordpress is making big steps in the right direction. * Their wild pile of oddly-named functions are being deprecated and moved into well-designed classes. * Better templating options are being promoted. * Yes, the global $wp_query leaves some to be desired, but at its core, wpdb's WP_Query is a decently powerful database abstraction, and if used right can perform well at scale. No, the hooks aren't going away, nor i…

> * Their wild pile of oddly-named functions are being deprecated and moved into well-designed classes. > * Better templating options are being promoted. Highly debatable. Ever made an admin page? There's a laughable number of callbacks required just for a single input.

The settings API [0] is really bad. That said, you can still use parts of it without the `add_settings_field` and `add_settings_section` bits.

Or you can build reasonably powerful abstractions over top of it that let you get a lot of stuff done quickly.

The power of the settings API is users can go in and remove fields. This plugin I installed has a field I don't want to show to my client? Let's just remove it. And we can do that without editing the plugins files directly and keep it safe for upgrading.

0. http://codex.wordpress.org/Settings_API

Re: The dire state of WordPress

#128

Post by mtts »

MostAwesomeDude wrote: post #35
corresation wrote: post #16

"I’m not going to list all the things that make WP at odds with best practises, but here are the brass tacks" There is a strange paradox that an infatuation with best practices seldom yields a successful product...because it seldom yields a product at all. And those products that do scratch itches and grow and evolve tend to have widely criticized code bases. Wikipedia, Wordpress, Firefox, mySQL, Linux...there isn't…

These things are not all alike. Fx has had many man-hours put into it, attempting to reduce their technical debt and improve the efficiency of maintenance work. They know what's still wrong in the browser, and they're working on it, but progress is slow. There's a reason that Mozilla's working on Rust, and it's not just for S&G. MySQL is so bad that when MariaDB happened, several long-standing architectural issues we…

> WP and Wordpress picked the wrong implementation language.

No they didn't. PHP makes sure you can deploy them just about everywhere for very cheap and without really knowing what you're doing.

Re: The dire state of WordPress

#129

Post by FilterJoe »

stephen_mcd wrote: post #122
FilterJoe wrote: post #46

Earlier quoted context omitted.

Mezzanine is quite nice: http://mezzanine.jupo.org/ It's Python (a Django app). BSD license. It has many advantages over Wordpress that I won't get into here, but all this is offset by one massive disadvantage: It rests on the Django framework. Django is a nice framework for web development but it takes at least a few months to learn for someone starting from scratch. The installation process for Mezzanine requires s…

Mezzanine contains a fabric installation that can take a vanilla ubuntu install, and have a production server up and running with Postgres, memcached, et al, in a single command: http://mezzanine.jupo.org/docs/deployment.html#fabric I believe this is actually easier than deploying Wordpress to production.

Very cool - I didn't know about this. However, this still presupposes you have a local Python/Django/Mezzanine installation. Simple for a Django web developer, probably not too bad for a non-Django web developer - but it's a bit much to expect a non Developer to set up Python, Django, and Mezzanine on their local system.

On the other hand, I see a way to make this simple for a non developer. Set up a virtual machine with everything all set up. Then all the end user would have to do is download VMware or virtualbox. Then download the VM image with Ubuntu/Django/Mezzanine/Fabric. And then you'd be approaching the same level of simplicity of getting started with self-hosted Wordpress.

Re: The dire state of WordPress

#130

Post by FilterJoe »

stephen_mcd wrote: post #121
FilterJoe wrote: post #74

Earlier quoted context omitted.

Can you name 1 or more cloud providers that have auto installers for Mezzanine? I'm not aware of any. Here's a post from 4 months ago comparing installing Mezzanine on a number of PaaS providers. None seemed anywhere close to as simple as installing Wordpress on Bluehost: http://appsembler.com/blog/paas-bakeoff-comparing-stackato-o... Read the comments and you'll find out that Mezzanine isn't yet compatible with Djan…

Mezzanine lead developer here. We'd been tracking Django 1.5 changes during the release candidates and were mostly compatibile with it up until its release. When it was released, a few issues cropped up - those were resolved within a day or two, so there was a brief period where it was incompatible with 1.5, but that's no longer true. So it was incompatible with 1.5 for less than 48 hours. Latest version works fine a…

Thanks for piping in - unfortunately I'm too late to edit my 1.5 comment.

Can you describe the easiest way for non-developers to get started with Mezzanine? Is there a way to do it that doesn't involve installing Python, Django, virtualenv, Mezzanine, other apps, etc.?

Post reply on HN