Does what it says, but in the most odd ways

  • As a developer, I was a little bit surprised when digging into the internals of the plugin. It creates custom database tables for things like Pages, Categories and Ads. As such, naturally, it creates custom admin UI for all of these.

    Best I can tell, there is no reason to do any of this – it makes for an incredibly janky admin UI, very unintuitive querying mechanisms, and surprises at every turn. Hoping that the developer of the plugin takes it in a forward facing direction, converting Ads to Custom Post Types, using a custom taxonomy for Ad Categories and stripping all the unnecessary admin UI code out in favor of core UI. It’s hard, but worthwhile.

Viewing 3 replies - 1 through 3 (of 3 total)

  • Hi Justin,

    The plugin dates back to 2007, which if you recall, predates all of the concepts and APIs you reference above–WP 3.0 wasn’t available until mid-2010 and widely adopted in 2011 with sweeping API changes when it happened. Given that is the case, this was the only way to implement the plugin (the original author’s choice, not mine) until custom post types came along.

    You’re evaluating the quality of the code not the functionality of the plugin, which isn’t very fair. Particularly since it’s hard to change a major code base with lots of customers very quickly without breaking a lot of things.

    We are working on migrating things actively and have been since the release of 3.0 when I took it over, but we have to balance that with bug fixes, feature enhancements and support as well. It’s easy to point a finger at the code and say “Bad!” when you don’t have to live with the consequences of changing it. ?? As a Plugin author, I’m sure you can appreciate that. If you look at AWPCP 2.2 compared with 1.0.6 (when I took it over), I believe you’ll see a huge change.

    I would hope you’d reconsider your review in light of these things.

    Thread Starter Justin Sainton

    (@justinsainton)

    Hi there,

    Thanks for writing back, I appreciate it. Please know that none of this is personal – it’s about the code, not about the people writing it.

    I very much understand the process you’re going through. I’m one of the lead developers of WP e-Commerce – have been since 2010. That plugin has been around since 2006 – so I know exactly the pain points you’re imagining, the pros and cons you’re balancing, the weight of a large project, etc. I get it. We have over 2.2 million downloads – I understand the weight of code + community ??

    Beyond that, I was the primary developer tasked with converting the admin area to utilizing custom post types for everything – we had custom tables for products, product categories, variations, etc. It’s all custom post types and taxonomies now. So rather that use the cop-out that “it’s not fair to evaluate the quality of the code” – let’s take some personal responsibility here, recognize that proper code is worth evaluating – and move forward. Saying that it’s hard to change a major code base with lots of customers – that’s true, but it’s just an excuse – not a valid reason for not doing it.

    And I’m the last to point the finger and call something garbage without good reason. Have you seen some of the reviews against WPeC? I’ve been on the receiving end of that enough times to know better. That said, certainly you know as well as I do that it’s beyond silly that here we are, in 2013, and you have custom tables for categories, pages and ads. Right?

    So, that all said – write your upgrade routines, move to custom post types and taxonomies, don’t break backwards compatibility – a tall order, but our history testifies to the feasibility – and I’ll happily change my rating. I should imagine you’d shave off thousands of lines of code, as we did – and have a much more performant and maintainable plugin.

    We’ll take that under advisement. Thanks for your feedback.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Does what it says, but in the most odd ways’ is closed to new replies.