3 ms·

i wrote drupal's form handling layer (and theme system, and big parts of drush and much more) I ultimately found that I was happier writing stuff closer to the

i wrote drupal's form handling layer (and theme system, and big parts of drush and much more) I ultimately found that I was happier writing stuff closer to the way wordpress does it. It really comes down to two things 1. depending on what tools you have available, what you are familiar with or what you are capable of understanding .. drupal or wordpress might be easier for you than the other. That's relative. 2. is the fact that the wordpress model is objectively simpler than the drupal model (at least last time I looked, around 4 years ago). So I'm not saying one is better than the other at all, just that this is how they are different. If you know, or are willing to learn, a bit of code, wordpress is most likely subjectively easier than drupal would be.

TylerE 13y ago
I'm probably a bit biased because I spent most of that 5 years pouring my heart and soul into a site that was, basically, right up Drupal's alley, a regional news portal that was very content heavy. We did use lots of various modules, some core, and some community - such as polls, forums, captcha stuff, comments, we had almost a terabyte of stuff served via ImageCache... We actually didn't use Drupal forms for much on the front end (The occasional webform for user submissions, etc, but very few actual drupal api forms), but on the admin backend we had lots of little things I threw together that worked well but were not used all the frequently (and then only by power users). Our frontend was primarily done through a system I called the Page module (Because it was the module that made...the pages - for instance http://www.reflector.com/news http://www.reflector.com/news). That was actually a really cool hack. It worked a lot like views - but could actually run on a high traffic site without bringing the whole thing to it's knees. The trick was that the really nasty join across about 8 tables (node, the content type data, related image data, story body (for teasers), and a couple others) was done only on node save and that was stored in an index table (not everything on the node, but just what I needed to build a page). So to generate each news block was a really super simple query of basically: select * from page_index where page_blockid = 12345 order by updated desc limit 5 instead of something like, and this is the super simplfied version select * from node left join content_type_story cts on cts.nid = node.nid left join taxonomy_data td on td.nid = node.nid left join uploads on uploads.nid = node.nid left join upload_files uf on uf.uid = uploads.uid left join node_content nc on nc.vid = node.vid where (td.termid = 1231 or td.termid = 1256) and node.published = 1 order by updated desc limit 5 (Field names ommitted because that query is way too long as it is). Of course, we were running multidomain so a lot of those tables where domain alises etc, again, all precomputed in my module. No, I don't miss it. But it was powerful, and I did develop, deploy, and serve 3 daily newspapers with 20k+ circ each with a dev and sysadmin staff of 1. There is no way I could have done that if I'd had to write everything from scratch.

TylerE 13y ago

I'm probably a bit biased because I spent most of that 5 years pouring my heart and soul into a site that was, basically, right up Drupal's alley, a regional news portal that was very content heavy. We did use lots of various modules, some core, and some community - such as polls, forums, captcha stuff, comments, we had almost a terabyte of stuff served via ImageCache... We actually didn't use Drupal forms for much on the front end (The occasional webform for user submissions, etc, but very few actual drupal api forms), but on the admin backend we had lots of little things I threw together that worked well but were not used all the frequently (and then only by power users). Our frontend was primarily done through a system I called the Page module (Because it was the module that made...the pages - for instance http://www.reflector.com/news http://www.reflector.com/news). That was actually a really cool hack. It worked a lot like views - but could actually run on a high traffic site without bringing the whole thing to it's knees. The trick was that the really nasty join across about 8 tables (node, the content type data, related image data, story body (for teasers), and a couple others) was done only on node save and that was stored in an index table (not everything on the node, but just what I needed to build a page). So to generate each news block was a really super simple query of basically: select * from page_index where page_blockid = 12345 order by updated desc limit 5 instead of something like, and this is the super simplfied version select * from node left join content_type_story cts on cts.nid = node.nid left join taxonomy_data td on td.nid = node.nid left join uploads on uploads.nid = node.nid left join upload_files uf on uf.uid = uploads.uid left join node_content nc on nc.vid = node.vid where (td.termid = 1231 or td.termid = 1256) and node.published = 1 order by updated desc limit 5 (Field names ommitted because that query is way too long as it is). Of course, we were running multidomain so a lot of those tables where domain alises etc, again, all precomputed in my module. No, I don't miss it. But it was powerful, and I did develop, deploy, and serve 3 daily newspapers with 20k+ circ each with a dev and sysadmin staff of 1. There is no way I could have done that if I'd had to write everything from scratch.