I have fallen into a pattern which works well for me. But I would like your comments - warnings, advice, extras, etc. Please let me pick your wisdom.
My "contents" are all "Basic Page". I don't know any reason to use "Article" or "Blog entry".
My pages have no body. Always blank.
I define blocks. If my page has content, the content appears in a block. I have more control over blocks; I can move the block to different pages, copy the block on multiple pages, do lots of stuff that I can't seem to do if the block is built into the page.
Very often my block body is something like "RECENT NEWS BLOCK BODY" - not to be displayed. I modify block.tpl.php to search $content for that string. If found, my PHP code generates the actual block contents that I want.
The site is a double site; one for mobile devices and one for desktop devices. My PHP code is shared between the two sites, so the code that generates the block body for "Recent News" can be called from both sites.
Example: I have a block titled "Did you know?" which displays information about one item; a picture and a paragraph. I call this an "Info Bit". block.tpl.php calls my shared code which looks at $content for "INFO BIT BLOCK BODY" and, if it is found, replaces it with the <img...> and the text. Because it's shared code, the same works on both the pc and mobile sites.
Seems to me that my methodology has these main points:
[1] All pages are Basic pages
[2] No page has a body; all content is in blocks.
[3] Many blocks have no body, just a recognition string which, through block.tpl.php, is replaced by my generated content.
Advantages:
* I can generate content dynamically, not at site definition time.
* I can generate content any way I want to; random select, most recent first, in any sorted order, etc.
* I can feed the content into both sites.
* I have years of experience with PHP; I have months of experience with Drupal. And, frankly, PHP is much better documented than Drupal.
Disadvantatges:
* My content is not searchable, because it is not in the database.
* My procedure might be smashed by a core / module / theme upgrade.
Please, your comments? Thank you.
Comments
Well another disadvantage is
Well another disadvantage is that if you suddenly become unable to work on your sites anymore, your site is going to be fairly unmaintainable by other Drupal professionals, and as you say, your procedure might be invalidated by changes to code, or perhaps site enhancements which clients may want further down the line. If you're still involved, not so bad, but if you and the client have parted ways for whatever reason, someone else is likely going to be much more frustrated than if you stuck to Drupal best practices.
I'm not too knowledgable on the subject, but I plan to bury myself in the concept soon, which is the Panels module + Context module. At a glance, I'm pretty sure Panels + Context provides similar benefits as your current methodology, but is more recognizable, probably more flexible and interfaces with other modules, and infinitely more documented.
EDIT: I'd love for somebody else to chime in and confirm my recommendation and possibly explain in more depth what Panels + Context really accomplishes.
I'm not entirely sure I
I'm not entirely sure I understand what you're explaining - but would Panels and Views not achieve the same functionality?
Views allows you to pull content from anywhere in your DB, define how it looks, put it into blocks etc.
Panels allows you arrange blocks on a page.
Sorry if i've misunderstood your problem!
in doing the normal way,
in doing the normal way, content will be be arranged automatically. Your method need someone to arranged them to be displayed.
The reasons of using varies content types are for ease of content management, and also a custom layout for each content type, different cck fields etc etc
The choice heavily depends on your application and the workflow of your content, and how many work load you can put on arranging each piece of content. Your method is doing like building a site using a rich editor, like Dreamweaver.
Joetsui's blog
You will be missing out from
You will be missing out from many popular modules that enhances content types and fields. And further more, it would be a complete disaster for both you and your client if it were a client project. Imagine teaching a non-technical user how to operate your site in the block fashion.
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
I can confirm that Views +
I can confirm that Views + Panels can accomplish everything in your 'Avantages' column, along with considerably weirder, more powerful things. And it does it with a GUI and an export/backup function.
The real advantage to learning to 'do things the Drupal way' is that you get a huge and constantly growing toolbox. You have a community of developers and a library of code to back you up, and that makes you and your work modular, flexible and future-proof.
If your site needs to move to a new server, there's the Backup Migrate module. If your site becomes hugely popular and performance starts to lag, there's the Boost module. If you have more than 10,000 articles or forum posts to search through, there's Apache Solr. If the client decides they suddenly want the site in five languages, there's the i18n package. If the client wants SEO, you can dynamically generate page titles, URLs, Meta tags and an XML Sitemap.
Using your method, you're mostly bypassing the entire Node system, writing your website in PHP and using Drupal as a wrapper. if Drupal can't directly touch your content, none of those modules can see it. If you want any of those features, you'll either have to build them yourself, (and maintain them yourself, debug them yourself, document them yourself, and security-audit them yourself), or bend over backwards trying to get the established tools to work with your hacks.
If you want to keep using PHP, at least do yourself a favor and learn how to write a module that uses hook_block().
The meta-pattern
I told my pattern; I did not tell my meta-pattern. The meta-pattern is to search Drupal Modules for something that seems to be able to do the job, and then study the documentation. If it looks likely, download and install the module. Unfortunately, it rarely does the entire job. Often it does part of the job, and that part may or may not be worth the trouble of including it in the site.
I only have experience with one of the components you mentioned - the i18n package. But because i18n does not translate EVERYTHING, I had to build my own PHP code for translation, and therefore I probably could have used my own PHP code to do all the translations.
For example, I never found an i18n way to translate the site slogan. I read all the relevant documenation I could find, I read all the i18n documenation, I even posted the question on the Drupal forum (http://drupal.org/node/1117892). But no answer, no way to translate site slogan.
That's why my version of page.tpl.php contains the lines:
require_once( "../ajc_tools.php" );
$site_slogan = ajc_translate( $site_slogan );
This translates the English language site slogan into whatever language is current. Strings are hard-coded. They could have been in a database, but I've used PHP-level strings for years and it works. My code is even used to switch logos depending on the current language (I found no Zen way to put the site slogan underneath the logo so I embedded it inside the logo image). My function ajc_xlate( $target, $input_string ) searches $input_string for $target and, if found, replaces it with ajc_translate( $target ). A danger of partial string matches, yes, but powerful for English text that may be embedded inside HTML by the time I see it.
I will look up "hook_block". However, I expect that it is limited to blocks. For example, the site slogan does NOT occur inside a block; it occurs at the top of the page which is not a block. I managed to put my own Language Selector in the upper right corner of the page using a modified page.tpl.php; that is NOT inside any block.
I will look at Panels and VIews again.
RIght now The Boss wants a blog. I will create a login "Editor" so that the page title shows as "Editor's blog". AFAIK no way to change that label in Drupal, not even to capitalize the "b", except for templates/*.tpl.php. If he wants a different label, I will do it in PHP.
sourcesqr said "Imagine teaching a non-technical user how to operate your site in the block fashion. " The word "Operate" is vague. I have PHP code that inserts the name, picture, and text of a randomly selected person into a block. The ability to do that is all PHP, yes. But there is a front end (in PHP) to add, edit, or delete the persons shown. You don't need to know PHP to change the content, only to change the way the content is displayed. And that's a developer's job, not a non-technical editor's job. But thank you sourcesqr; you remind me that my translation strings should have a similar GUI.
nicktr said "Panels allows you arrange blocks on a page. " I thought that was Admin / Structure / Blocks. And the arrangement is limited to what is built into the theme. Maybe Panels give me more power to do that? I'll check it out. I'll look at Views also.
The reason people re-invent the wheel is because the wheels they can find are square. Maybe it's because they don't know where to look for round wheels; maybe it's because there are no round wheels.
A positive note - thank you all for responding to my posts. I previously posted in the global Drupal forum and rarely got any response at all. Sounds like the Hong Kong group is much more supportive.
Another PHP Kludge
We have a double site; one version for small screens and one version for big screens. I searched but could not find how to use two different themes for one site.
You go to "http://URL/" and index.php checks to see what kind of device you are on. If "ismobile" you go to "http://URL/mob/" and otherwise you go to "http://URL/pc/". The PC site uses a derivative of the Zen theme; the mobile site used the mobile theme. Haven't yet faced an iPod, which is mobile but with a big screen.
So we have two sites; one for pc and one for mobile. This means that we have two databases; one for pc sand one for mobile.
We have a special blog on the menu, the "Editor's Blog". It exists in the PC site, the PC site database, and user named "Editor" updates his blog on that site. But how to display the Editor's Blog on the mobile site?
I do not yet know of a way to transfer blog entries from one Drupal site to another. It's a frightening concept, because all the interconnect numbers (e.g. vid) have to be adjusted.
But this morning I looked in the dtabase and figured out the mysql code needed to fetch the entries from the pc database, even while running in the mobile site. So I now have a page in my mobile site which will display a list of entries from the Editor's blog, and will display a selected one entry from the Editor's blog.
How? The Drupal Mobile site has a basic page with one block, the block contents are "EDITORS BLOG BLOCK BODY". When that string is recognized my PHP code replaces the contents with the HTML-formatted data coming from the other database.
Views? WTF
I quote from http://drupal.org/documentation/modules/views: "Which Branch: Views 1, Views 2 or Views 3? Views 1.x is for Drupal 5 (and earlier). Views 2.x and 3.x are for Drupal 6. Views 3.x is for Drupal 7."
I'm running Drupal 7 (of course), so I guess I need Views 3.
I quote from http://drupal.org/project/views: "Views 3 documentation hasn't been written yet."
That same page shows that the "recommended release" is 7.x-3.0-rc1 dated 2011-Jun-18. Drupal 7 was released Jan 2011. It is now 26 Sep 2011. So for the annual Drupal release of eight months ago, all we have is an undocumented release candidate from three months ago.
This is what I am supposed to rely upon?
One aspect I think will
One aspect I think will definitely help you with Drupal is not to rely too much on one single source of information. Generally Google things and you'll find a vast array of documentation and tutorials, especially with Views in general.
Views however might be a strange situation, as Views 2.x was (and still is) incredibly popular, and Views 3.x has shifted and rebuilt the UI quite a bit, so finding guides specifically for Views 3 could be a little difficult.
2 places I often check however for support is the project issue queue (such as http://drupal.org/project/issues/views) and Drupal Stackexchange: http://drupal.stackexchange.com/
Remember that Drupal is open source and a large amount of the work is done for free. If you find an area of documentation lacking you can always add to it yourself when you become a genius.
you can always add to it
Don't wait until then. When you are a genius you can't see the difficulties of the newb. The best time to write documentation is when you are figuring it out for the first time.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Views is the most
Views is the most complicated, most used, most well documented, and most stable Drupal module. The maintainers are very conservative in assigning version numbers. You have nothing to fear from Views, and a lot to gain.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Agree
So far, I haven't built a site without views for several years. Learn how to theme a view is mandatory.
Julien MARY
Editor Capabilities
I have one guy who can log in as "Editor". He needs to be able to edit the block body of several blocks, such as the "About Us Block". On the other hand, he should not be allowed to edit other blocks, or do other things in the site. If I make him an administrator he could easily, inadvertently, destroy the site.
It appears that what I want to do is create a new role; less powerful than Administrator and yet with special privileges beyond a mere authenticated user. The Admin / People / Permissions page has three columns; this would add a fourth column. Unfortunately, that page has an entry "Administer blocks", with no finer gradation possible. I can find nothing in Drupal that will allow me to constrain a page, or a menu link, or a configure block, to a particular user or to a particular new role.
For me this is trivial to do in PHP. My PHP toolkit can add an "EDIT" link to a particular block only if the user is 'admin' or 'Editor'. That link would lead outside Drupal to a PHP page that reads the block body from the database (table 'block_custom' field 'body' where field 'info' = block description) and put it in a form with a submit button. The button would lead to another PHP page that updates the database and contains a link back into the Drupal site. No problem; a few hours work.
But that's not the "Drupal way". What is the Drupal way? How to give a particular user the ability to edit the body of a particular block?
I can't tell if you're just
I can't tell if you're just not looking hard enough since virtually every issue you've encountered has been made surmountable by the first 1-2 google hits, but anyway, the Block Access module should provide exactly what you need: http://drupal.org/project/block_access
Pro-tip, most drupal modules that provider finer-grain permissions generally go by the name "??? Access"
Thank you, ++
I'm used to C, Firefox, PHP, MySQL, and the like, where nearly everything is in the basic package and you rarely need add-ons. Apparently, with Drupal, to do anything you need to install a new module.
OK, I got the Block_Access module installed. And in Admin / Structure / Blocks / Edit block I can adust "ROLE SPECIFIC (action) SETTINGS". This gives the power to every member of a role, and the only roles I have so far are "administrator" and "authenticated user". What I need is an "Editor" role.
So - how do I create a role? FYI I have searched Drupal.org for "create new role" and "create role" and found many postings from people who created a role which did not work right; never did I find out how they created the role. I even searched the modules list but could not find a "Create Role" module.
Oh, and by the way, it's a pity that the Admin menu tree is not searchable.
Drupal Admin menu navigation
Drupal Admin menu navigation is probably the worst part of the entire system for new users I agree.
I don't remember which Drupal version you are using, so I'll point you here http://drupal.org/node/22275
Thank you +++
FYI my first mistake back in May was installing Drupal 7. As of today Drupal 7 is still not finished (e.g. the Views Module documentation). I should have installed Drupal 6, which is finished.
I have now found "Roles" button on the "Permissions" page and created a role named "editor". I have given the editor role permission to administer blocks and to configure all blocks. I assume that if he can "configure" the block then he can change the "block body".
OK . . . How?
Yes, that's the stump part now. Log in as "Editor", and I never anywhere get any option to configure the block. I have even logged in as admin and gone to Admin / Structure / Blocks and copied the URL, then logged out and logged in as Editor and gone to that same URL. No change on the screen that I can see; still on the home page.
Now that Editor is has "permission" to configure a block, how does he configure a block?
Addendum
Yes, I did assign user "Editor" to the role "editor"; forgot to mention that.
FYI
I installed the "Block Access" module and got the 'editor' role to work. Then I started with a fresh site with no Block Access module and it worked just as well. I never got anything useful out of the Block Access module.
In Admin / People / Permissions / Roles I created a new role named "editor".
In Admin / People / Permisions / Permissions, for the 'editor' role, I enabled 'Block / Administer blocks nd enabled 'Contextual links'. Significantly, I did NOT enable "Use the FullHTML text format".
In Admin / People / List / Editor I set the role of user 'Editor' to "editor".
The result is that user 'Editor' gets a contextual menu at the upper right corner of every block. If he clicks on that he goes to the page to configure that block. But he can only change the block body if it is plain text or FilteredHTML, not if it is FullHTML. Unfortunately he can change other things on the block configuration page, and probably screw up the site that way.
While I had the Block Access module installed, there were a bunch of permissions in on the Permissions page, but none of them were necessary. There were a bunch of items on the block definition page, like 'ROLE SPECIFIC CONFIG SETTINGS', but none of them seemed to have any effect.
I'm not sure what the data
I'm not sure what the data architecture of the rest of your site is like, so this may be totally missing the mark. But if I were implementing this, I would do it this way
This assumes your "editor" only needs to edit the content in those blocks and not the blocks themselves.
When the editor logs in, he would be able to see only those content nodes for which he has rights to. So he doesn't need to have or even know about editing blocks. I'd go as far as defining a view that lists out the content he is supposed to edit and put that up on his menu.
Russell JVM Gutierrez
Or use the Context module
Or use the Context module
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
Page / Content / Block
My architecture:
The site has pages. All pages are of the "Basic Page" type because I've never seen any documentation on the features of the other types of pages. Pages have titles. My pages do NOT have bodies; all page bodies are blank.
All of my pages use the default theme. I have never found a way to say "This page uses that theme, and that page uses this other theme." It would be nice to have such a feature.
Themes have layouts (regions), so a page has a layout.
Regions on a page contain blocks. Usually blocks do not have titles. Blocks are created independently of pages, but are assigned a page and a region on that page.
Blocks have bodies. This is where my site 'content' appears. I would like everything on the site to be in a block; unfortunately some material, such as the site logo, are built-in as not being in a block.
My Drupal architecture is Page / Region / Block / BlockBody. I deliberately avoid putting material into the page body because this bypasses the two intermediate structures of the hierarchy.
rgucci confuses me very much. He seems to overuse the word "content".
AFAIK, in Drupal terminology, pages are content, nothing HAS content. Pages have bodies (mine are all blank), blocks have bodies. The Admin menu item "Content" lists pages; when you "Add content" (add a page) you have to chose from three page types.. rgucci says "Create a new content type". OK, content types are page types; I could create a new page type. But later he says "Insert content into your blocks as appropriate (create an "about us" content node, etc., and use those as the contents of your blocks)." A "node" is a page, "content" is a page; I can lay out a block onto a page but I cannoy insert a page into a block.
Maybe if the kind Mr. rgucci would carefully re-word his statement using current Drupal 7 terminology I could make sense of it. But as of now he seems to be inserting pages into blocks.
Obviously
Rgucci is referring (and rightfully so) to text, images etc. as content as well when he says "Insert content into your blocks as appropriate...".
Just like you refer to the very same as content here: "This is where my site 'content' appears".
And you contradict yourself here:
"Blocks have bodies. This is where my site 'content' appears." because you refer to content as pages later "AFAIK, in Drupal terminology, pages are content"
and finally to put the ice on the cake you say: "content" is a page; I can lay out a block onto a page but I cannoy insert a page into a block."
Maybe its time do some re-wording yourself before complaining about other peoples terminology?
"AFAIK, in Drupal
"AFAIK, in Drupal terminology, pages are content, nothing HAS content. Pages have bodies (mine are all blank), blocks have bodies. The Admin menu item "Content" lists pages; when you "Add content" (add a page) you have to chose from three page types.. rgucci says "Create a new content type". OK, content types are page types; I could create a new page type. But later he says "Insert content into your blocks as appropriate (create an "about us" content node, etc., and use those as the contents of your blocks)." A "node" is a page, "content" is a page; I can lay out a block onto a page but I cannoy insert a page into a block."
Let's extend that knowledge then.
In Drupal, content types are content types. I don't know where you got the idea that content types are page types. In the administration page for content types (admin/structure/types), you can create new content types. In fact, to create a new content type, you click on a link labeled "Add content type", which you can navigate to by clicking on the menu item "Content types".
One of the pre-created content types is "Basic Page". You create other types and give them any name you want. See the screenshot below, taken from on of many online drupal demo sites.
Then you can set up the access rights for the content type that you created. Then create the content, and insert them into blocks.
To insert content into a block, there are several modules you can use. Here is a comparison
http://groups.drupal.org/node/93499
Since the Views modules is the most commonly used, then I would go for that option
From the description in the page linked above: "Any view can provide a block. A view can show a single node by filtering on the node ID. More sophisticated arguments and filters are possible."
Like I have been saying, insert content into your blocks.
It's good that you have solved your issues "using php". I try to avoid having to code in php at all when using drupal, except as a last resort, but that is my personal preference. Two of the things I like about drupal is 1) the flexibility in solutions (you can find pre-built modules, write your own module, etc.) and 2) the strong sharing within the community.
This information is here to help other people who run into similar problems. Do you think you can share your own solution so that it can help other people?
Russell JVM Gutierrez
People who helped to create
People who helped to create and contribute to Drupal and it's community (e.g. helping to answer questions like yours) are doing it voluntarily out of the love of Drupal and the kind and hard working people behind the scene and community. I think they deserve a lot more respect.
Anyway, AFAIK, the Drupal that you understand is FAR DIFFERENT than the principles and design that it is built on, and that is one key reason why Drupal is great. Before you start complaining about Drupal not behaving the way YOU EXPECTED, please, do some reading. There are a lot of great resources available in the community:
Online resources:
Get Started with Drupal handbook
Drupalize.me video tutorials
Lullabot Drupal Blog / Videocast / Podcast
And a few books I strongly recommend:
Definitive Guide to Drupal 7
Pro Drupal 7 Development
A Pro Tip: Even though Drupal 7 is new and largely enhanced, it still shares a lot of principles and methodologies with Drupal 6. If you cannot find something that's D7 specific, you can always find hints from the D6 counterparts.
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
Thanks. Respect?
I'm sorry. I have been programming for over 40 years, mostly in environments where content, Content, 'content', and "content" are four totally different things. Sometimes I find it difficult to write in English, which is more sloppy.
You deserve thanks for contributing. I said "Thanks", and I'll say it again. Thank you.
You get respect for the quality of your output. You do not get respect because you work for free. The same quality standards apply, whether or not you are getting paid.
There are some very fine open source products out there; for example Linux, Apache, MySQL, and PHP. We all know that there are some god-awful crappy proprietary packages out there. Getting a paycheck does not ensure quality; not getting a paycheck does not ensure quality either.
I have a copy of "The Definitive Guide to Drupal 7" on order. I really do want to make this work.
FYI I spent all day Monday trying to to allow Editor to edit the bodies of specific blocks. The best I could do was an ability to edit the entire block configuration of all blocks, which gives the Editor far too much power to mess up the site. So Tuesday morning I coded it myself, in PHP. It works.
Thanks, guys.
The last thing i ever wanna
The last thing i ever wanna do is to start a negative arguement, but I think there's still sth that you need to know.
I respect those who have 40 years of programming experience where one word from them worth thousands words from others, however I respect more of those who try to contribute to the community with all they have, eventhough what they know probably just 1/100 of what the guy with 40 years iof experience have.
We do not just respect how good people are, we respect their eftort and spirit, which is the two things that made the Drupal community what it is today.
Besides, those with 40years of expeirence could be a total ass, don't u agree?
As for the blocks, if u wanna configure blocks while not letting editors to mess with it, the simplest and the most recommended way would be to use views to creat a block and output of a node (or nodes) in it. U can use block.tpl.php if u don't even want th block to be available in the admin interface at all.
Cheers!
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
Well, keep in mind that he
Well, keep in mind that he hacked block.tpl.php.
Before it gets rendered on screen, every block goes through block.tpl.php. Andy's version scans the block content for identifier strings, and then uses those as a cue to call PHP code.
Andy- have you tried, as an Editor, including one of your identifier strings in the content of a block?
Sorry, I mean the block
Sorry, I mean the block template for individual block, e.g. block--block--1.tpl.php :P
Kelvin Lee
Onion Creative
Twitter: @KelvinLeeHK | @OnionCreativeHK
Google+: +Kelvin Lee
"We do not just respect how
"We do not just respect how good people are, we respect their eftort and spirit, which is the two things that made the Drupal community what it is today."
I would go so far as saying: We respect people. Full stop.
Russell JVM Gutierrez