announcment: microcontent, an attempt to make drupal basics simpler.
Various times, I heard Dries talking about tasks he wants to see done easier. Things he considers "basic stuff to do in Drupal". I stolea list from a mail to the documentation list, but some points, IMO should be made *simple* in Drupal. We can document how one does it, but the better way is to make code to do this. * 2. Setting up an about page.* * 3. Setting up a contact page.* * 6. Setting a mission statement and slogan.* * 9. Figuring out the difference between 'story' and 'page' (and grokking the node system).* My shot at this, for sympal/drupalCOM is a module called microcontent. I want to take this opportunity to get some input from the community on the workings of this module. * Every microcontent entry is a node. * Every microcontent entry is available as a block (so this is also a blocks-as-nodes module) * You can choose "special" microcontent types. For now: * site summary (site title, site body) * mission (mission title, short mission, long mission) * site details (footer) So the basic site setup is done trough our *content* areas. Blocks are made/moderared trough our famous *content* user interfaces. We could choose (we did so for sympal/drupalCOM) to prefill the database with dummy missions (edit mission <= link) and other dummy microcontent (about page etc), but that would mean that the contrib module ships with an install script. No longer deeply hidden admin pages to change the mission, but living withing the other content. About pages, and a contact page will be part of my microcontent v2. in that v2 I want to integrate 3rd party modules, such as that contact.module, or other modules that affect small pieces of user-end content on the site. Please give some feedback, or ideas, because i want to release this module before 4.7 ;) http://drupal.org/node/43839 --------- This, btw is Driess complete "what should be documented for noobs" list 1. Installing the Drupal database scheme and creating the first user account. 2. Setting up an about page. 3. Setting up a contact page. 4. Creating a navigation menu/structure. 5. Adding one or more roles and configuring their permissions (eg. allowing some users to create content, allowing some users to access content). 6. Setting a mission statement and slogan. 7. Installing a new or different theme. 8. Setting a block in the side bar. 9. Figuring out the difference between 'story' and 'page' (and grokking the node system). 10. Configuring cron.
Bèr Kessels wrote:
* Every microcontent entry is available as a block (so this is also a blocks-as-nodes module)
I'd like to see that done separately via nodeapi for future-proofing with CCK.
So the basic site setup is done trough our *content* areas. Blocks are made/moderared trough our famous *content* user interfaces.
I'm not sure if this is a good idea or not. Certainly is worth exploring.
No longer deeply hidden admin pages to change the mission, but living withing the other content.
I'd like to remove the mission since it seems like a bit of weird thing to me. I'd like some more powerful control of every page.
This, btw is Driess complete "what should be documented for noobs" list
Good list, have a url for this in the archives? -- Neil Drumm http://delocalizedham.com/
Good evening. I'm busy upgrading the one module I maintain (wishlist.module) to Drupal 4.7. It has been pretty straightforward, following http://drupal.org/node/33338 helped a lot. The forms api conversion was simple with the help of the http://www.lullabot.com/formupdater. Thanks for the work that went into both of these. I've gone through the upgrade steps and rummaged around drupal.org looking for some help with a problem. I can save, delete and edit a wishlist node with no problem. But my custom display for showing wishlist items in a table (http://mclewin.com/wishlist/2 [4.6 version]) spews SQL errors. Looking at the table schema, it appears that database structure was changed to remove the field "body" from the NODE table. A little digging found a "body" field in the NODE_REVISONS table. Before I rework my code to add another join between NODE and NODE_REVISIONS I thought I would double check that doing so is considered 'correct' - what is the intended way to retrieve the body text of the node in Druapl 4.7? Here is the error I'm getting: * user warning: Unknown column 'n.body' in 'field list' query: SELECT n.nid, n.title, n.uid, w.item_priority, w.item_est_cost, w.item_currency, n.body, n.changed, w.item_quantity_requested, w.item_url1, w.item_url2 FROM node n LEFT JOIN wishlist w ON n.nid = w.nid WHERE n.type='wishlist' AND n.uid=1 AND w.item_is_public ORDER BY n.title ASC LIMIT 0, 10 in /raid/home/www-drupaldev/drupal-4.7.0-beta2/includes/database.mysql.inc on line 108. Scott
You can of course do a node_load($nid). But if you need to manually load data (e.g., so you can do a custom select), then, yes, you need to do a join on {node_revisions}. Examples are in the core modules--searc for "{node_revisions}". I don't see this in the module update instructions--I'll add in a note (unless on second look I find it already there). ----- Original Message ----- From: "Scott McLewin" <drupal@mclewin.com> To: <development@drupal.org> Sent: Sunday, January 08, 2006 6:52 PM Subject: [development] Field "body" no longer part of node table in 4.7 - looking for guidance on what to change
Good evening.
I'm busy upgrading the one module I maintain (wishlist.module) to Drupal 4.7. It has been pretty straightforward, following http://drupal.org/node/33338 helped a lot. The forms api conversion was simple with the help of the http://www.lullabot.com/formupdater. Thanks for the work that went into both of these.
I've gone through the upgrade steps and rummaged around drupal.org looking for some help with a problem. I can save, delete and edit a wishlist node with no problem. But my custom display for showing wishlist items in a table (http://mclewin.com/wishlist/2 [4.6 version]) spews SQL errors. Looking at the table schema, it appears that database structure was changed to remove the field "body" from the NODE table. A little digging found a "body" field in the NODE_REVISONS table. Before I rework my code to add another join between NODE and NODE_REVISIONS I thought I would double check that doing so is considered 'correct' - what is the intended way to retrieve the body text of the node in Druapl 4.7?
Here is the error I'm getting:
* user warning: Unknown column 'n.body' in 'field list' query: SELECT n.nid, n.title, n.uid, w.item_priority, w.item_est_cost, w.item_currency, n.body, n.changed, w.item_quantity_requested, w.item_url1, w.item_url2 FROM node n LEFT JOIN wishlist w ON n.nid = w.nid WHERE n.type='wishlist' AND n.uid=1 AND w.item_is_public ORDER BY n.title ASC LIMIT 0, 10 in
/raid/home/www-drupaldev/drupal-4.7.0-beta2/includes/database.mysql.inc on line 108.
Scott
Nedjo Rogers wrote:
You can of course do a node_load($nid). But if you need to manually load data (e.g., so you can do a custom select), then, yes, you need to do a join on {node_revisions}. Examples are in the core modules--searc for "{node_revisions}". I don't see this in the module update instructions--I'll add in a note (unless on second look I find it already there).
there is a subpage of the upgrading page that covers the new revisions system.
Moshe, I realized that my fingers cut and paste the wrong link in my original message. The upgrade steps I followed were on http://drupal.org/node/22218. I didn't catch the revisions overhaul subtopic - it's clearly there now that you've pointed it out. Thanks. I should have seen that. I just clicked through the 23 steps on the parent page and presumed I was done - it seemed like such a through list! :) Scott Moshe Weitzman wrote:
Nedjo Rogers wrote:
You can of course do a node_load($nid). But if you need to manually load data (e.g., so you can do a custom select), then, yes, you need to do a join on {node_revisions}. Examples are in the core modules--searc for "{node_revisions}". I don't see this in the module update instructions--I'll add in a note (unless on second look I find it already there).
there is a subpage of the upgrading page that covers the new revisions system.
Thanks Nedjo. I think you've answered my question - that doing a join to the {node_revisions} table to get the body is the proper method in Drupal 4.7. Thanks for the prompt response. Scott Nedjo Rogers wrote:
You can of course do a node_load($nid). But if you need to manually load data (e.g., so you can do a custom select), then, yes, you need to do a join on {node_revisions}. Examples are in the core modules--searc for "{node_revisions}". I don't see this in the module update instructions--I'll add in a note (unless on second look I find it already there).
----- Original Message ----- From: "Scott McLewin" <drupal@mclewin.com> To: <development@drupal.org> Sent: Sunday, January 08, 2006 6:52 PM Subject: [development] Field "body" no longer part of node table in 4.7 - looking for guidance on what to change
Good evening.
I'm busy upgrading the one module I maintain (wishlist.module) to Drupal 4.7. It has been pretty straightforward, following http://drupal.org/node/33338 helped a lot. The forms api conversion was simple with the help of the http://www.lullabot.com/formupdater. Thanks for the work that went into both of these.
I've gone through the upgrade steps and rummaged around drupal.org looking for some help with a problem. I can save, delete and edit a wishlist node with no problem. But my custom display for showing wishlist items in a table (http://mclewin.com/wishlist/2 [4.6 version]) spews SQL errors. Looking at the table schema, it appears that database structure was changed to remove the field "body" from the NODE table. A little digging found a "body" field in the NODE_REVISONS table. Before I rework my code to add another join between NODE and NODE_REVISIONS I thought I would double check that doing so is considered 'correct' - what is the intended way to retrieve the body text of the node in Druapl 4.7?
Here is the error I'm getting:
* user warning: Unknown column 'n.body' in 'field list' query: SELECT n.nid, n.title, n.uid, w.item_priority, w.item_est_cost, w.item_currency, n.body, n.changed, w.item_quantity_requested, w.item_url1, w.item_url2 FROM node n LEFT JOIN wishlist w ON n.nid = w.nid WHERE n.type='wishlist' AND n.uid=1 AND w.item_is_public ORDER BY n.title ASC LIMIT 0, 10 in
/raid/home/www-drupaldev/drupal-4.7.0-beta2/includes/database.mysql.inc on line 108.
Scott
Op maandag 09 januari 2006 02:24, schreef Neil Drumm:
Bèr Kessels wrote:
* Every microcontent entry is available as a block (so this is also a blocks-as-nodes module)
I'd like to see that done separately via nodeapi for future-proofing with CCK.
This is what I initially had. But the whole point of the project got lost this way: Making stuff easier :) It then needed at least an additional checkbox, some other form elements etc. If i look at the node creation screen i almost start crying: The collapsible elements seem to have given us an excuse to litteraly dump the page full of forms. Just open thta page w/o javascript. Its worse then a nasa rocket cockpit. :)
So the basic site setup is done trough our *content* areas. Blocks are made/moderared trough our famous *content* user interfaces.
I'm not sure if this is a good idea or not. Certainly is worth exploring.
Which is what I am doing. Some pro's: * you can assign more rights to different roles. So finer grained permissions over block moderation * you can use filters in mission, footer and slogan (like PHP in a footer) * you can upload files with blocks, missions, and so. * You can place your mission in the menu structure. * Blocks can have readmore links pointing to a page with the longer text (teaser and body) * You can put the mission etc in a location in the handbook. Some cons: * Our content editing parts are not the most userfriendly pages :). Finding the mission nodes in there might prove a critical problem for this module * We have named some of the "parts" in Drupal quite clumsy (historical reasons). Mission, is really "about us", footer indicates a placement, yet it really is "site details". slogan is a very odd name too. So taking this into a non-dedicated admin ui (the nodes) might get people lost. * Overhead. Loading a variable is, IMO faster then loading a node. * Duplication. Since this is a contrib, the core methods are still there, But if we move this to core, we can drop the blocks table, for example.
I'd like to remove the mission since it seems like a bit of weird thing to me. I'd like some more powerful control of every page.
My ultimate plan is to rename "mission" to "About us". But since the word "mission" is hardcoded all trough Drupal, and mentioned all around drupal.org i decided to do this only in DrupalCOM in the locales.
This, btw is Driess complete "what should be documented for noobs" list
Good list, have a url for this in the archives?
It was on the documentation list. I cannot find it now (in the train, wo internet access). Bèr
participants (5)
-
Bèr Kessels -
Moshe Weitzman -
Nedjo Rogers -
Neil Drumm -
Scott McLewin