The use case may not seem immediately obvious, but consider the following example: Your client has a design that has, on a certain page, one or more blocks with information that can be considered “semi-static;” that is, likely to change at some point in the future, but not enough to really be considered a dynamic piece of the site. The eventual administrators of the site will want to be able to have access to edit this content in some form or fashion.
There are a number of possible solutions, each with their own strengths and weaknesses:
*You can create a node with a specific taxononmy, or perhaps even a totally new content type for the content, then use Views to find the specific piece of content and display it as a block. In many cases, using a full node for a small bit of content will be overkill.
*Create a custom block and use regular html markup to create the content. Perhaps the most common way of solving this problem, but suffers from a potential lack of supportability when someone later tries to edit the markup with a WYSIWYG editor, ruining your hand-coded markup and breaking styling. You could also create a module to create the block, which may also be overkill for the small amount of content they’re wanting to display.
*Embed the markup directly in the page.tpl.php - safer than the block, but obviously not nearly as supportable by the end-user.
*Use Panels and it’s Custom Content Panes. If your site already utilizes Panels, this is an option, but one would hate to implement Panels just to solve this problem. In addition, Custom Content panes are still just blocks of html markup that your users may not feel able to manage.
The Arbitrary Content module attempts to solve this problem by giving you the ability to create these blocks with any number of fields in a manner that is easy for an end user to manage while still giving you the power of individual templating and theming for each block. The module is very light-weight in comparison to using full nodes with Views or Panels. With the theming ability, you can safely entrust the management of the content to non-developers while keeping the display attributes of your custom content safely in code. It plays nicely with the Drupal Block System, Context and Panels.
While Block creation may be the most obvious use, it can also generate entire pages of content, registered with the menu system. Again, sometimes a node might seem to be inadequate (or too heavy handed) for generating some semi-static page specified in an IA document. One could even conceivably use Arbitrary Content to build a site’s homepage.
Additions coming in the near future include exportability and/or Features compatibility, field weights and token support.
Arbitrary Content has a public git repo that can be accessed at:
git://git.7sudos.com/arbitrary_content.git
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | arbitrary_content-6.x-1.x-dev.zip | 11.52 KB | fadeddata |
| #6 | arbitrary_content.zip | 17.44 KB | fadeddata |
| #1 | arbitrary_content.zip | 9.85 KB | fadeddata |
Comments
Comment #1
fadeddata commentedHere is the module attached as a zip file for review.
Comment #2
fadeddata commentedSorry didn't mean to set the status incorrect when posting the upload.
Comment #3
avpadernoComment #4
fadeddata commentedHey all, latest version on the Git repo should support Ctools import/export. Would love to get a project page for this. The D7 version will be entities and will use the fieldable functionality provided.
Comment #5
fadeddata commentedOk, I've reorganized the public git repo to reflect the recommendations in the Prototype Git Book. There is now a 6.x-1.x branch and 7.x-1.x branch. The D7 version is pretty neat. Basically Arbitrary Content provides fieldable pages and fieldable blocks. I'm still going to see if I can get the D6 version to utilize CCK somehow so that I don't have to provide custom field creation/configuration. Oh and I haven't passed the D7 version through coder yet but will probably work on that next week.
Comment #6
fadeddata commentedAttached are the latest D7 and D6 versions.
Comment #7
avpadernoWe review a single module/theme per applicant; this means also a single version of the module/theme.
Comment #8
fadeddata commentedAttached is the latest D6 version for review.
Comment #9
zzolo commentedHi. Please read all the following and the links provided as this is very important information about your CVS Application:
Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:
Migrating from CVS Applications to (Git) Full Project Applications
Comment #10
fadeddata commentedhttp://drupal.org/sandbox/fadeddata/1074226
In the last few weeks a D7-dev branch has been added. The D6 version has been integrated with Ctools and numerous bug fixes have been applied by the maintainers on an external Git repo. I've moved all of our commits to the sandbox and have set up branches according to the Prototype Git Book recommendations.
Comment #11
berdirSome notes about the 7.x branch...
- The coding standard in D7 is "Implements hook_something()." now, instead of the longer "Implementation of ..."
- Instead of MENU_CALLBACK for some of the menu items, you could try MENU_VISIBLE_IN_BREADRUMB, that might give you a breadcrumb as the name says :)
- Creating a menu item for every piece of content isn't really a good Idea IMHO. Instead, you could define a single menu router item (similar to node/%node) and then create menu links to that, optionally with an alias.
Comment #12
fadeddata commentedOk, I've fixed those items. Honestly the horrid code that was creating multiple menu items was from sleep deprivation. I've changed it over to us ac/{ac_name} style path via an argument. Also if the path module is enabled the user can provide a path alias to set it to. I back ported that functionality to the D6 branch as well. Just went to the automated testing session and hope to start writing tests for both branches next.
Comment #13
logickal commentedI'd like to weigh in on the module. I have done a lot of code review on this module and have used it on production sites, but feel that I cannot actually mark it as 'Reviewed & Tested' because of possible conflict of interest: Fadeddata is my friend and co-worker. Even though I have been helping him with code review and implementing the suggestions here in the 7.x branch and doing the normal things expected by the review process, because of my closeness with the project I have felt that I am excluded from the community review process. All of the real functional code and design of the module was performed by fadeddata, my contributions have solely been from a review standpoint. To that end, even though I feel that the module and code is solid and should be marked as having been so, I have/will not do so myself.
Comment #14
logickal commentedAfter discussing these possible conflicts of interest on IRC, I take back the last bit of what I said - since I have reviewed this code and feel that it meets standards and is approval ready, I'm changing the status to reflect that.
Comment #15
pwolanin commentedI looked quickly through the 7.x code - I thought there might be a sec hole http://drupal.org/node/1119896
but I don't think it's a real vuln. In any case, it would be readily fixable. Overall the code looked reasonable - so carrying this out.
Comment #18
avpaderno