"For example, it makes sense to build student magazines, handbooks, FAQs, and blogs with WordPress. But it’s simply not possible to build an equipment checkout system, or a course evaluation system, or a student/faculty/staff directory with WordPress — not while trying to preserve your sanity. That’s because WordPress assumes so much about the structure of your data — it thinks every piece of content has a title, a summary, an author, etc. Start to veer away from that basic data structure and you find yourself quickly needing a platform that doesn’t make assumptions about how things should be done. For those kinds of problems, we use Django."
At least for me, this is the crux of my issues with URL routing; WordPress wants to force me to use a certain URL structure that doesn't fit many use cases when it would be so easy to have WordPress handle URL routing more generically. If the difficulty in URL routing could be fixed, most everything else would be easy to fix.
I can get behind the URL routing issues. I can get behind supporting slightly more abstraction to the data structure of WordPress for the sake of greater flexibility. But it *is* WORDpress, not PDFpress or EvaluationPress. The assumption has always been that WordPress is a blog - or if you prefer not to use that term, a "self publication tool." - not a CMS. For those willing to put a bunch of extra work into building a full-fledged CMS out of WP, I say good luck. But I prefer my tools to be good at what they do, not half-assed for the sake of being like other software that is already out there in an already saturated market.
WordPress installs easy, sets up fast and is hugely flexible for those looking to publish their words on the Internet. Those who think the same is true for Drupal have forgotten what it's like not to know how to do what we do here. This ease of use factor is what gives WP it's market share. Changing it will doubtless have the opposite effect.
On Sat, Nov 28, 2009 at 7:02 AM, Mike Schinkel <mikeschin...@newclarity.net>wrote:
> "For example, it makes sense to build student magazines, handbooks, FAQs, > and blogs with WordPress. But it’s simply not possible to build an equipment > checkout system, or a course evaluation system, or a student/faculty/staff > directory with WordPress — not while trying to preserve your sanity. That’s > because WordPress assumes so much about the structure of your data — it > thinks every piece of content has a title, a summary, an author, etc. Start > to veer away from that basic data structure and you find yourself quickly > needing a platform that doesn’t make assumptions about how things should be > done. For those kinds of problems, we use Django."
> At least for me, this is the crux of my issues with URL routing; WordPress > wants to force me to use a certain URL structure that doesn't fit many use > cases when it would be so easy to have WordPress handle URL routing more > generically. If the difficulty in URL routing could be fixed, most > everything else would be easy to fix.
On Nov 28, 2009, at 7:21 AM, Thomas Belknap wrote:
> I can get behind the URL routing issues. I can get behind supporting > slightly more abstraction to the data structure of WordPress for the sake of > greater flexibility. But it *is* WORDpress, not PDFpress or EvaluationPress. > The assumption has always been that WordPress is a blog - or if you prefer > not to use that term, a "self publication tool." - not a CMS.
But Wordpress has come so far and has so many benefits for those who use it that it's a shame so many in the community want to limit its vision to always being "only a blog." A damn shame, because it could easily be so much more.
> For those > willing to put a bunch of extra work into building a full-fledged CMS out of > WP, I say good luck. But I prefer my tools to be good at what they do, not > half-assed for the sake of being like other software that is already out > there in an already saturated market.
I don't see WordPress as being half-assed if it were to add URL routing and custom post types; I would see it as a platform that has over 3000 custom extensions and probably as many off-the-shelf custom themes. I see it as the platform most likely to succeed if it were not held back by a too-narrow vision.
> WordPress installs easy, sets up fast and is hugely flexible for those > looking to publish their words on the Internet. Those who think the same is > true for Drupal have forgotten what it's like not to know how to do what we > do here.
The irony is that you say "Wordpress is just a blog" and then criticize Drupal for being too complex. Wordpress could easily match Drupal's core differentiator (custom post types) and not be as complex as Drupal.
> This ease of use factor is what gives WP it's market share. > Changing it will doubtless have the opposite effect.
That changing Wordpress will cause it to loose market share or even ease of use is an assertion based in little more than an invalid assumption. I've developed both modules and plugins for Drupal and Wordpress respectively and it's their architectures that divide them, not their features.
Wordpress could easily add custom post types (and custom URLs to support) without increasing the architectural complexity. What's more, it could continue to be as easy to use for the average person, it would just have more headroom for those more advanced.
.... The irony is that you say "Wordpress is just a blog" and then criticize Drupal for being too complex. Wordpress could easily match Drupal's core differentiator (custom post types) and not be as complex as Drupal....
Not criticizing at all. Drupal rocks at what it does. But it's not the kind of thing that a person just wanting to publish their words on the Internet would necessarily want to toy with. And what makes Drupal good - and I personally think what makes WordPress good - is that Drupal is pure abstraction and WordPress isn't. Drupal can be used to do any number of different types of websites, with the caveat that it doesn't easily lend itself to any specific type of website. It's for pros who have a decent understanding of the core database concepts that drive web applications. WordPress is superlative at publishing, but if you want to create a Torrent site, you're probably not going to have much success. But you can get a publishing house setup in fifteen minutes. Why mess with that?
Anything that increases WP's flexibility without compromising its ease of use for the average pedestrian I would be fine with. _______________________________________________ wp-hackers mailing list wp-hack...@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-hackers
On Nov 28, 2009, at 8:27 AM, Thomas Belknap wrote:
> Not criticizing at all. Drupal rocks at what it does. But it's not the kind > of thing that a person just wanting to publish their words on the Internet > would necessarily want to toy with. And what makes Drupal good - and I > personally think what makes WordPress good - is that Drupal is pure > abstraction and WordPress isn't. Drupal can be used to do any number of > different types of websites, with the caveat that it doesn't easily lend > itself to any specific type of website.
Well, I'll criticize Drupal then. It's far too abstract; it's architecture is highly coupled and that makes if very difficult to get simple things done if those simple things were not envisioned by the people who wrote Drupal core. Moderation in all things yet their abstraction is not moderate. In addition, it runs an incredible amount of code to load even the simplest page which adds server load on a high volume site and makes debugging a chore. Worse, the admin console is incredibly sluggish compared to Wordpress making admin tasks tedious at best, and the theming is so coupled with the core that it's very hard to theme.
The irony for me is that abstraction is what originally attracted me to Drupal over Wordpress. After living with it for 2 years I realized that it was a nightmare and not a blessing and switched to Wordpress instead.
> It's for pros who have a decent understanding of the core database > concepts that drive web applications.
I disagree. I taught database programming as early as 1987 and have seen the pendulum swing many times. Drupal on the surface appears to be well architected; once you use it you realize it is far too coupled for it's own good.
> WordPress is superlative at publishing, but if you want to create a Torrent > site, you're probably not going to have much success. But you can get a > publishing house setup in fifteen minutes. Why mess with that?
If "messing" is adding a thin layer to support custom post types and custom URLs then why not?
Besides, how many business people want to create Torrent sites? Most want to build business-related sites. Wordpress would be all 80% would need if it had custom post types and URLs to support.
> Anything that increases WP's flexibility without compromising its ease of > use for the average pedestrian I would be fine with.
Someone recently commented on a blog post of mine about the Pods plugin, which I described as basically "turning Wordpress into Drupal".
What I replied to him goes the same here: use the right tool for the right job. It depends on the requirements of the project. A website based on custom data-types will not work well in Wordpress, but if you're building a blog or info site, Drupal is overkill.
They are very different tools intended for very different jobs. However, Wordpress is so flexible and extensible that with the help of plugins like Pods it can move in to solve problems that would normally fall into Drupal's area. But I don't think the Wordpress core should be modified with this purpose in mind.
Wordpress is so very good at what it does, and with the additions coming in 2.9 for media management I think it's market is clear. The problem developers have is that Drupal is quite hard to setup and nowhere near as intuitive as Wordpress for clients to manage. We're missing the middle ground - a custom data-type based CMS that is intuitive and flexible. _______________________________________________ wp-hackers mailing list wp-hack...@lists.automattic.com http://lists.automattic.com/mailman/listinfo/wp-hackers
> What I replied to him goes the same here: use the right tool for the right > job. It depends on the requirements of the project. A website based on > custom data-types will not work well in Wordpress, but if you're building a > blog or info site, Drupal is overkill.
> They are very different tools intended for very different jobs. However, > Wordpress is so flexible and extensible that with the help of plugins like > Pods it can move in to solve problems that would normally fall into Drupal's > area. But I don't think the Wordpress core should be modified with this > purpose in mind.
Sigh. Drupal is such a PITA that I'm at the point I'd never recommend it for anything.
And Wordpress has almost all the core components it needs. It's almost there.
> We're missing the middle ground - a custom data-type based CMS that is > intuitive and flexible.
Wordpress can be that middle ground, if people will just see it.
On Sat, Nov 28, 2009 at 08:49:18AM -0500, Mike Schinkel wrote:
> If "messing" is adding a thin layer to support custom post types and custom > URLs then why not?
> Besides, how many business people want to create Torrent sites? Most want > to build business-related sites. Wordpress would be all 80% would need if > it had custom post types and URLs to support.
> > Anything that increases WP's flexibility without compromising its ease of > > use for the average pedestrian I would be fine with.
> That's all I'm suggesting.
Speaking for a small web shop that builds using Wordpress, Drupal and Zend Framework, I couldn't agree with Mike more on all points. While Drupal "does more", its heavy, bloated and convoluted by comparison. For those of us that often are happily and productively using Wordpress to do non-traditional Wordpress types of things, custom post types and more flexible url handling would be really welcomed.
On Nov 28, 2009, at 6:21 AM, Thomas Belknap wrote:
> I can get behind the URL routing issues. I can get behind supporting > slightly more abstraction to the data structure of WordPress for the sake of > greater flexibility. But it *is* WORDpress, not PDFpress or EvaluationPress. > The assumption has always been that WordPress is a blog - or if you prefer > not to use that term, a "self publication tool." - not a CMS.
See, the problem is that whenever a discussion like this comes up-- e.g. "how can we make WordPress more like a CMS?"-- we get a lot of snarky remarks back along the lines of "It's already a CMS, dummy". Then for other discussions we get "It's not a CMS and shouldn't be."
Well which is it? You can't argue against changes with both "it's not one" and "it's already one".
Personally, I stand behind Mike's post 100%. WordPress should work on the API for custom post types. I'm glad to see that this has gotten some progress in 2.9, but definitely want to see it continue.
Here's the thing: We don't need custom post type capabilities in the default Admin, but it would be wonderful to have to ability in the code so that *plugins* can easily add them and admin sections for them. It would be cool, for example, to make edit pages modular and abstracted, so Plugins could readily make custom edit pages for Post Types by adding in edit sections -- almost like widgets. For Post Type X I need the Text box, Parent, Categories, and nothing else. Boom. Done.
In a way it's a shame that in Admin we moved away from "Action" ("Write". "Edit") menus toward "Thing" ("Posts", "Pages") menus, as this makes it more difficult -- or at least more bulky -- to incorporate custom post types. Where previously it would have been intuitive to add a new item or two under "Edit", now to follow the existing structure it would be a case of adding a whole new top menu for each new Post Type, which would get big pretty quickly.
Well, that's just my two bits.
Again, I'm glad to see work on Custom Post types in 2.9. Let's keep going! :-)
> Here's the thing: We don't need custom post type capabilities in the default Admin, but it would be wonderful to have to ability in the code so that *plugins* can easily add them and admin sections for them. It would be cool, for example, to make edit pages modular and abstracted, so Plugins could readily make custom edit pages for Post Types by adding in edit sections -- almost like widgets. For Post Type X I need the Text box, Parent, Categories, and nothing else. Boom. Done.
That sounds like an extremely good plan.
What's more, I'd really like to see the artificial distinction between Posts and Pages minimized, i.e. Currently Posts can have tags and categories, but not Pages while Pages can be part of a menu but not Posts. etc. It would be nice to have each of these features decoupled and allowed to be assigned in the admin. The default configure would be to have Posts and Pages the way they are now but if I wanted to add tagging to Pages then it would be great if I could just add it.
> On Nov 28, 2009, at 3:24 PM, Stephen Rider wrote: >> It would be cool, for example, to make edit pages modular and abstracted, so Plugins could readily make custom edit pages for Post Types by adding in edit sections -- almost like widgets. For Post Type X I need the Text box, Parent, Categories, and nothing else. Boom. Done.
[...] > That sounds like an extremely good plan.
> What's more, I'd really like to see the artificial distinction between Posts and Pages minimized, i.e. Currently Posts can have tags and categories, but not Pages while Pages can be part of a menu but not Posts. etc. It would be nice to have each of these features decoupled and allowed to be assigned in the admin.
I actually have no problem with the way it is, as it's designed to work well, by default, for the way most people do blogs. That's fine.
The point is that plugins should be able to easily add such things to Pages (for example). I currently use a (tiny) plugin that adds the Description field to Edit Pages.
> The default configure would be to have Posts and Pages the way they are now but if I wanted to add tagging to Pages then it would be great if I could just add it.
No distinct need for it to be in core if it can readily be done with a plugin. Let's leave the default as is, and make it *easy* for plugins to do all this as needed.
> On Nov 28, 2009, at 3:00 PM, Mike Schinkel wrote: >> What's more, I'd really like to see the artificial distinction between Posts and Pages minimized, i.e. Currently Posts can have tags and categories, but not Pages while Pages can be part of a menu but not Posts. etc. It would be nice to have each of these features decoupled and allowed to be assigned in the admin.
> I actually have no problem with the way it is, as it's designed to work well, by default, for the way most people do blogs. That's fine.
> The point is that plugins should be able to easily add such things to Pages (for example). I currently use a (tiny) plugin that adds the Description field to Edit Pages.
>> The default configure would be to have Posts and Pages the way they are now but if I wanted to add tagging to Pages then it would be great if I could just add it.
> No distinct need for it to be in core if it can readily be done with a plugin. Let's leave the default as is, and make it *easy* for plugins to do all this as needed.
There's two concerns; how it's architected and what's in the admin console. I was proposing it to be architected so that the functionality is plugin and play rather than hardcoded.
OTOH I would prefer it to be surfaced in the admin as an advanced option too although I'll willingly cede that concern as long as the architecture is in place for a plugin to leverage it.
I personally think that if it were in the admin the majority of WordPress sites would be using it within 18 months (note: when I say majority I refer to many sites which haven't been launched yet but would be if the functionality were in the core admin. There is just far too much value that this would create for people who want to launch sites to ignore it.)
> I personally think that if it were in the admin the majority of WordPress sites would be using it within 18 months (note: when I say majority I refer to many sites which haven't been launched yet but would be if the functionality were in the core admin. There is just far too much value that this would create for people who want to launch sites to ignore it.)
Being in the Admin would be nice, but not going to happen soon methinks. Get the infrastructure in there, and *after* it has proved its undeniable worth, then we go back and consider the merits of making the customization GUI part of Core. Baby steps. ;-)
> On Nov 29, 2009, at 8:19 PM, Mike Schinkel wrote:
>> I personally think that if it were in the admin the majority of WordPress sites would be using it within 18 months (note: when I say majority I refer to many sites which haven't been launched yet but would be if the functionality were in the core admin. There is just far too much value that this would create for people who want to launch sites to ignore it.)
> Being in the Admin would be nice, but not going to happen soon methinks. Get the infrastructure in there, and *after* it has proved its undeniable worth, then we go back and consider the merits of making the customization GUI part of Core. Baby steps. ;-)
On Sat, Nov 28, 2009 at 9:25 AM, Mike Schinkel <mikeschin...@newclarity.net>wrote:
> Sounds like then that my issue with custom URLs will need to (mostly) be > addressed in order to make custom post types usable, right?
> FYI, I'd say that 80% of what I've needed custom URLs for has been custom > post types.
In WP 2.9, register_post_type() adds a post type of foo.
Using WP_Rewrite::add_rewrite_tag() allows you to add a new custom permalink structure, say, /%foo%/
Add these things to a fuction hooked on init with a low priority and you should be good to go. I don't see the problem with a little ingenuity and a few lines of code.
Aaron Brazell CEO, Emmense Technologies Lead Editor, Technosailor.com Author, The WordPress Bible
> In WP 2.9, register_post_type() adds a post type of foo.
> Using WP_Rewrite::add_rewrite_tag() allows you to add a new custom permalink > structure, say, /%foo%/
> Add these things to a fuction hooked on init with a low priority and you > should be good to go. I don't see the problem with a little ingenuity and a > few lines of code.
Thanks. I've stayed aware from non-released versions so I'll be anxious to try that when 2.9 is released.
<wp-hack...@striderweb.com> wrote: > No distinct need for it to be in core if it can readily be done with a plugin. Let's leave the default as is, and make it *easy* for plugins to do all this as needed.
I think this is definitely the right way to go. In the original linked article they said Django was the winner. In talking to Django devs my sense is that what they love is how one line of API driven code accomplishes what takes a dozen slow-loading clicks in Drupal, and that 90% of the time that one line should never change for the life of the site, so having it outside the admin is good for business, cause clients can't mess it up etc.
Things like adding categories to posts or setting up a custom post type should work that way. Simple bits of API code you can add in functions.php for a theme that set up the admin with little friction. It makes sense for them to be in functions.php because without the theme that supports the custom content type why have the admin? This is exactly how the current widgets/sidebars system works in WP and its awesome as anyone who has used it has probably noticed.
Once these options are accessible via short bits of code it becomes easy for a plugin to step in and offer a lightweight UI to make things accessible via the admin, like the role/capability plugins do now.
WP is already on its way to being as configurable as Django behind the scenes without becoming painfully bloated like Drupal on the frontend. IMHO its just a matter of continuing on the same path of keeping it simple for self-installers while offering robust API for developers.
