Configurable content types in core
I committed the first part of Content Creation Kit, configurable content types, to core. Here are some next steps: - Test and find the bugs that we haven't found yet. - Make book, blog, and forum types work with only configurable content types. - Documentation (I've had a hard time explaining this). - Start moving fields module towards core, only 4 weeks left. On fields module, I haven't looked at it much recently, but I'm guessing I'll make the same request I did of content module, merge it into node module. I'm not 100% sure of this quite yet, since not as many people will have custom fields. If a feature is basic functionality which most people will use, prefer adding it to the most logical module (and conditionally including any appropriate code), instead of adding another module. If a computer can decide if code needs to be included or not, it will probably be smarter than a user. The real question is, should we have fields always be configurable or should the be a global switch (a module) to turn them off? -- Neil Drumm http://delocalizedham.com/
On Aug 6, 2006, at 5:36 PM, Neil Drumm wrote:
I committed the first part of Content Creation Kit, configurable content types, to core. Here are some next steps:
- Test and find the bugs that we haven't found yet.
Do you have some starter ideas for what to test?
- Make book, blog, and forum types work with only configurable content types.
Ok.
- Documentation (I've had a hard time explaining this).
I'll commit resources to do document this: http://drupal.org/node/62530 Kieran
- Start moving fields module towards core, only 4 weeks left.
On fields module, I haven't looked at it much recently, but I'm guessing I'll make the same request I did of content module, merge it into node module. I'm not 100% sure of this quite yet, since not as many people will have custom fields.
If a feature is basic functionality which most people will use, prefer adding it to the most logical module (and conditionally including any appropriate code), instead of adding another module. If a computer can decide if code needs to be included or not, it will probably be smarter than a user.
The real question is, should we have fields always be configurable or should the be a global switch (a module) to turn them off?
-- Neil Drumm http://delocalizedham.com/
Kieran Lal wrote:
On Aug 6, 2006, at 5:36 PM, Neil Drumm wrote:
I committed the first part of Content Creation Kit, configurable content types, to core. Here are some next steps:
- Test and find the bugs that we haven't found yet.
Do you have some starter ideas for what to test?
Anything that calls node_get_types() and the whole content type editing UI. Zacker even found one already http://drupal.org/node/77375. -- Neil Drumm http://delocalizedham.com/
Kieran Lal wrote:
On Aug 6, 2006, at 5:36 PM, Neil Drumm wrote:
- Documentation (I've had a hard time explaining this).
I'll commit resources to do document this: http://drupal.org/node/62530
I'm thinking the end result should be over at http://drupal.org/handbook/modules/node and in the node module's help texts. -- Neil Drumm http://delocalizedham.com/
On Aug 6, 2006, at 5:36 PM, Neil Drumm wrote:
- Start moving fields module towards core, only 4 weeks left.
sorry if i'm missing something, but it doesn't seem like the existing CCK (the 4.7 version i'm testing) exposes any of the fieldset functionality (title, weight, collaps(able|ed), etc). i think this is a critical feature, and i'd like to see it in 4.7 CCK as much as in core. if not, i'll probably write my own custom node module in 4.7 for the new project i'm working on, since fieldsets will be essential. is there already an issue/patch for this? i couldn't find anything searching the CCK issue queue, but advanced search doesn't always work. :(
If a feature is basic functionality which most people will use, prefer adding it to the most logical module (and conditionally including any appropriate code), instead of adding another module. If a computer can decide if code needs to be included or not, it will probably be smarter than a user.
+1. in general, this is a very wise approach. definitely all of the fields included in core should be in 1 module, along with the fieldset functionality. ;) however, why keep content.module and field.module separate at all? why not have 1 module for all custom- content-type code in core?
The real question is, should we have fields always be configurable or should the be a global switch (a module) to turn them off?
you could still have a global setting that wasn't a whole new module, which conditionally removed pages from the admin menu and UI elements. however, a separate module would probably be cleaner. i haven't studied the current iteration of the CCK schema, but i'm assuming it's still a fairly sizeable collection of tables. leaving it separate from node.module keeps all the DB install/update stuff out of the way for sites that don't need it. i'd vote for a single content module outside of node for everything CCK-esque going into core (with a bunch of .inc files in the same directory... ahh, i'm so glad we did that). ;) that said, i think CCK as it stands now is missing essential functionality, and there are still quite a few bugs. i'll do what i can, but i've got my hands full with way too many other drupal things. no one should mistake this for me complaining about any of the work anyone's already doing/done, but there's a lot to do, and i know i can't personally devote myself wholeheartedly to it in the next 4 weeks. so, i'd like to 2nd dries's plea for more help making this happen. ;) thanks, -derek (dww)
Derek Wright wrote:
fairly sizeable collection of tables. leaving it separate from node.module keeps all the DB install/update stuff out of the way for sites that don't need it. i'd vote for a single content module outside of node for everything CCK-esque going into core (with a bunch of .inc files in the same directory... ahh, i'm so glad we did that). ;)
I ranted about why I thought merging content module into node was the best way (this is how it works in core now) over at http://drupal.org/node/62340#comment-119859. -- Neil Drumm http://delocalizedham.com/
On Aug 6, 2006, at 10:30 PM, Neil Drumm wrote:
I ranted about why I thought merging content module into node was the best way (this is how it works in core now) over at http:// drupal.org/node/62340#comment-119859.
i'm convinced. ;) that's all i needed to read... congrats on committing http://drupal.org/node/62340! everything else i said is still true: i think we need fieldset functionality, and there are almost certainly still bugs. let's keep up the push to make custom content types (CCT?) worthy for a new stable release! thanks, everyone! -derek
Derek Wright schrieb:
On Aug 6, 2006, at 5:36 PM, Neil Drumm wrote:
- Start moving fields module towards core, only 4 weeks left.
sorry if i'm missing something, but it doesn't seem like the existing CCK (the 4.7 version i'm testing) exposes any of the fieldset functionality (title, weight, collaps(able|ed), etc). i think this is a critical feature, and i'd like to see it in 4.7 CCK as much as in core. if not, i'll probably write my own custom node module in 4.7 for the new project i'm working on, since fieldsets will be essential. is there already an issue/patch for this? i couldn't find anything searching the CCK issue queue, but advanced search doesn't always work. :(
There is already an issue for this (http://drupal.org/node/57483) and hopefully soon a working solution, too ;) -fago
Thanks Neil. On 07 Aug 2006, at 02:36, Neil Drumm wrote:
- Start moving fields module towards core, only 4 weeks left.
Historically, we decided not to use alter tables to add new fields. This results in many, many JOINs, combined with some node caching algorithm. People who can't alter tables, can't run the upgrade script so it is probably safe to assume that 99% of all Drupal sites can alter their tables. Therefore, I'd like to open up this discussion again. Let's come up with a list of advantages and disadvantages of both approaches? -- Dries Buytaert :: http://www.buytaert.net/
On 8/7/06, Dries Buytaert <dries.buytaert@gmail.com> wrote:
Thanks Neil.
On 07 Aug 2006, at 02:36, Neil Drumm wrote:
- Start moving fields module towards core, only 4 weeks left.
Historically, we decided not to use alter tables to add new fields. This results in many, many JOINs, combined with some node caching algorithm.
the cck i was testing created and altered tables.
-- Dries Buytaert :: http://www.buytaert.net/
- Start moving fields module towards core, only 4 weeks left.
Historically, we decided not to use alter tables to add new fields. This results in many, many JOINs, combined with some node caching
the cck i was testing created and altered tables.
Same here. The logic appears to be: * One table per content type. * One table column per content field that is NOT SHARED. * If a content type is SHARED, it becomes its own table. -- Morbus Iff ( insert pithy quote here ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
Hi all! I'm proud to present this patch, http://drupal.org/node/77514. It does some simple but yet very useful changes to the error reporting system. Basicly this is a version of Search404 (http://drupal.org/node/26010) on steroids, with some enchantments. All features from Search 404 are kept. It has been rewritten to be more stable, secure and fast than before. New features has been added: * The error message is now configurable * Three special paths has been added; o <blank> - It's the classic Drupal 404 page, just an error message o <front> - Invokes the frontpage - with an error message set to $message o <search> - This is what Search 404 accomplishes and is also the standard 404 page if nothing else is specified. It performs a search on the words from the requested URL. The options to configure Search 404 remains: + Display a link instead of the search results directly. This feature is particular useful when many bots is hitting the site. + Jump directly to the search result when there is only one result. + Use OR between keywords when searching. + A list of words that should be ignored (php, html etc) o Of course any Drupal path can still be specified * There's now an option to send "404 Not found" header or not * Brand new 403-handling: o Can use <blank> and <front>, but also <login> which will display a login form. o Configurable error message and option to send "403 Access denied" header Care has been taken to not create loops, such as the user don't have access to the 404 page, and the 403 page itself isn't found. One reason why this should be in core, is that error-handling surely is someting the CMS itself should take care of. *How to test:* 1a) Visit: http://forngren.com/fantastic40x/ 1b) Make a fresh Drupal HEAD install, and make sure that everything seems ok. Apply the patch attched 2) Fool around with the site 3) Report results back in this issue Links * http://drupal.org/node/26010 * Search 404 /Posted by geokker - November 7, 2004 - 11:56 * http://drupal.org/node/12668 */ I can't believe how many sites miss this trick. I was looking for a radio programme 'Loose Ends' on the BBC website. I tried www.bbc.co.uk/radio/looseends <http://www.bbc.co.uk/radio/looseends> and got a 404. Why? How difficult would it be to put the non-matching part of the URL into a search and bring up 'Sorry, we couldn't find an exact match - did you mean...' then list trip_search results or something. *If anyone can figure this out, it should go into core Drupal functionality.* A good CMS has an excellent search facility. A good site has this search facility on every page. When I'm looking for something on a site, as soon as it renders I instantly judge it. If I can't quickly see a search box - I hate it. If there is a ton of content on the front page - I'm not a fan. If the search is slow, or doesn't yield coherent results - I'm dissapointed. If it's Flash - I'm not impressed. * http://drupal.org/node/7570 * Diskussion about "Custom 404 Error Page" *Sideeffect* There is a tiny sideeffect, though. After using this for a few days on a test site with 6 nodes, I stopped using the navigation and just typed what I was looking for in the URL. I think that Bert Boerland can confirm this. *Final words, contact info and more* First of all, none of this would be possible if it wasn't for the work done by Lars Sehested Geisler/larssg, the maintainer of Search 404, and Bert Boerland, which has been a great support during the process of writing, testing and documenting this patch. Since I've summerholidays I can usually fix bugs/errors within a few hours (awake between 10-24 GTM +2). If you want to discuss this patch, please, do so. I'm in #drupal when I'm awake. You can also use my contact form (http://drupal.org/user/40238/contact) or skype me (forngren). Cheers!
Wow! How did you manage to enchant it? Is there any magic involved?
Op maandag 7 augustus 2006 12:18, schreef Dries Buytaert:
Let's come up with a list of advantages and disadvantages of both approaches?
And -for once- come up with a good database model (entity relation diagram) before the code/patch? If you want to do something this big good, your datamodel must be good. And to design a complex datamodel, simple PHP code won't cut it. Because of this, I have just put my initial thoughs online with the ERD. As I state in the small description, I am clueless when it comes t drawing such diagrams. :) http://webschuur.com/node/643 Antoher point I'd like to make is that we should not rush this in, but maybe should make this is a coding session at the DrupalCON? Where we can design the datastructure first then code it, and then create a nice future-proof patch from it. Thigs I'd liek to see, for example are * hooks to alter field_instances (hook form alter-simplified) * hooks to alter field behaviour (should GoldMember see field X) * hooks to add fields to the field_types (library) ... etc. Prolly we can think of a lot more. And coming up with a good power/flexibity/performance balance requires thought, and a good route. Not some rushed in patch. Bèr -- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com |
I agree with Ber here. A good Entity Relationship diagram for such a crucial part of the system is needed for an effective discussion.
On Wednesday 09 August 2006 07:23, Bèr Kessels wrote:
And -for once- come up with a good database model (entity relation diagram) before the code/patch?
If you want to do something this big good, your datamodel must be good. And to design a complex datamodel, simple PHP code won't cut it.
A big +1 from here! Code can be refactored or completely rewritten much more easily than a data model can be redesigned. Let's take the time to get it right from the start.
Because of this, I have just put my initial thoughs online with the ERD. As I state in the small description, I am clueless when it comes t drawing such diagrams. :)
I think this model (albeit an early draft, as you say) is fundamentally sound in its semantics. Just out of curiosity, what are the "node characteristics" to which you refer, and what is the "id" field in that entity? If this is the actual data for a node, then you may need the node ID plus the field ID as keys rather than just a single ID key. Or am I reading it wrong? Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
Thank you for the time! :) Op maandag 28 augustus 2006 20:32, schreef Syscrusher:
On Wednesday 09 August 2006 07:23, Bèr Kessels wrote:
And -for once- come up with a good database model (entity relation diagram) before the code/patch?
If you want to do something this big good, your datamodel must be good. And to design a complex datamodel, simple PHP code won't cut it.
A big +1 from here! Code can be refactored or completely rewritten much more easily than a data model can be redesigned. Let's take the time to get it right from the start.
I have upgraded the post, and tried to explain all the items a bit better. I also redrew the ERD in UML, so that I could share the drawing as SVG and as XMI. Feel free to take the erd and make it into something better. :)
Because of this, I have just put my initial thoughs online with the ERD. As I state in the small description, I am clueless when it comes t drawing such diagrams. :)
I think this model (albeit an early draft, as you say) is fundamentally sound in its semantics. Just out of curiosity, what are the "node characteristics" to which you refer, and what is the "id" field in that entity? If this is the actual data for a node, then you may need the node ID plus the field ID as keys rather than just a single ID key. Or am I reading it wrong?
I explained node_characteristics in the refactored ERD a bit better. It is, in essence what we now do in hook_node_info, it describes what code or "stuff" handles that node type. My ERD/model, however, allows us to let many modules handle a node. We currently have two mechanisms, both don't allow user_interaction: hook_insert/update/etc and hook_nodeapi. By refactoring the model a little and by pulling the relation node_type - node_handler into the database, we can allow a) a standard UI to handle the node (uploads, images, products, categories, taxonomy, etc management from one interface) b) many modules to act on the lifecycle of a node, while improving performance! (we know beforehand what modules want to interact on node_load, e.g.) Also note that a lot of "stuff" is still missing. My nodes don't know if they are published (table node_visibility) nor who authored and edited them (node_author table) they don't track dates (additional columns in node table). and they don't have revisions (node_revisions) etc. I also have no clue how to handle this in reality. Drupal's patch-system does not allow for such a great overhaul, so maybe we should first agree on a new theoretically/ideal ERD, then chop that up into mini-tasks? Bèr
participants (12)
-
Adrian Rossouw -
Bèr Kessels -
Derek Wright -
Dries Buytaert -
fago -
Johan Forngren -
Khalid B -
Kieran Lal -
Konstantin Käfer -
Morbus Iff -
Neil Drumm -
Syscrusher