Hacker News Reader

Comment by mildweed | Hacker News Reader

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 is the URL-to-template mapping. But those are the parts that make it so flexible and easy to work with. MVC is a controller dictatorship, WP's code is a democracy.

View on HN

I think curation and code review should really be an important part of the theme and plugin repositories.

Perhaps they need 'approved' and 'Open' directories for the repositories?

There used to be this issue with people having issues distributing plugins; now with github, that is much much easier.

There is just so much bad code floating around, people not following best practices and loading JS libraries that core includes, conflicts with other plugins, etc. Its a mess.

Code review is a part of the theme repository, if you're talking about themes hosted on WordPress.org. Themes hosted elsewhere (ThemeForest, GitHub, etc) have no such oversight.

Themes hosted on WordPress.org (the official repository) have to pass through the Theme Review Team, which does enforce certain guidelines and standards: http://make.wordpress.org/themes/guidelines/

There's also a large group of people moving to add similar oversight for the official plugin repository; but when you have a repository with 24,000+ separate projects, managing a code review for each one - and for changes to each one - is a huge undertaking.

I had heard there was a Code review for the theme repository, my feeling (pure speculation) is that the review process is there to weed out truly bad coding or malware but there was no strict edicts on style or 'the right way to do things'.

I understand enforcing methods and whatnot is probably not in the best interest of Automattic, WordPress.org nor the community; if it is feasible at all. I'd just like to see some kind of curation based on 'the right way to do things', if anything just so I know when I'm doing things the right way.

The Codex and general documentation has become a bit muddled with new APIs and conflicting philosophies between developers. What used to be WordPress' greatest asset (its documentation) is starting to falter behind a bit. It's been hard for me since ~3.2 to figure out where I should be changing my boilerplates as WP updates.

I follow TRAC, I keep as updated as I can on future changes and point releases but without solid documentation sometimes I feel like I don't know if I'm doing things the way they were intended.

Savvy?

> * 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

Reply on news.ycombinator.com