I'm migrating a site from a proprietary cms (reddot) to drupal. For all its flaws, reddot has a very simple yet flexible model:
templates consist of markup with placeholders for variable content
every piece of content, from a full page, to a shared piece of sidebar content, and even a single image can be built from a template, if an appropriate one exists
My first impression of drupal is: woah, this is complicated! Rather than three simple objects, now i'm dealing with nodes, pages, blocks, regions, views, panels, etc. What is the simplest way to recreate the template/content/placeholder model that i'm familiar with?
Reddot uses a rather well architectured MVC-alike system. In addition, from my limited experience, Reddot follows the there is only one way to achieve Foo-philosophy.
Coming to Drupal, especially as a frontend-developer you will be dissapointed, lose a lot of hair and probably curse a few times when you realise everything has to be done all over again.
Coming to Drupal you will love the gigantic amount of (unfortunately unorganised) documenation and its flexibility and enormous amount of new posibilities.
When people come from properly architectured systems into Drupal, I advice them to do one thing: become pragmatism-exstremists. Don't (ever) try to make things proper, clean or well-thought out. You will only be able to do that once you truly grok Drupal. And that only comes with a lot of experience. Just fiddle untill it works, close the code and never look at it again.
First thing you will need to learn, is Drupals PHPTemplate engine, which is rather different from Reddots, but has a lot of similarities. Where Reddot uses RenderTags, Drupals PHPTemplate uses plain old PHP.
<%!! Context:CurrentPage.Template.Name !!%>
becomes
<?php print $name ?>
And yes, $name is entirely globally scoped. Remember? I told you to be a pragmatism-extremist. Don't even think about namespacing, object scoping and such.
Want to know what variables you have available? Just do a <?php print get_defined_vars() ?>.
Want new variables in your template? You need to preprocess them.
Want to change, alter, strip or modify existing variables? You either need to preprocess, or template override or even write new modules that make new or different variables available?
Knowing which to choose, when to preprocess, when to create modules, when to override, when to implement hooks to alter stuff is experience.
Drupal has never thought that out clearly, there is no general rule or best practice, other then the last eleven times that Foo-concept did not work out, maybe Bar proves the best.
Drupal's templates are similar to what you describe of reddot, but there are probably more options and they can be nested. To get a good sense of how the templates work together download the Theme Developer module and watch the associated screencast.
To get a sense of the "placeholders" you can use in a given template, visit the api.drupal.org page for the template file or check out this Drupal 6 Theming Cheat Sheet.
Another one bites the dust.. ;)
Let me know how you go with the migration Bobby Jack.
I think for the content you might be able to create an XML variant in the CMS and export everything to re-import it to Drupal..
On the Drupal note: Once you get your head around the concept of templates being able to inherit/being overwritten it's easy.
It's like a set of pre-assigned content classes in RedDot which can change to render them in a different layout. Similar to the "replace content-class" functionality.
Related
I run a design firm and have frequent need for Drupal development. I'm looking for a bit of guidance on a Drupal workflow that will work best for my company.
My experience working with Drupal developers in the past has been great for back-end development, and chaotic for front-end development. Projects end up with multiple and inconsistent CSS styles, and doing quality control on the visual aspect is very time-consuming.
Moreover, I'm a front-end coder, and use HMTL/CSS/JS prototypes for all phases of projects. I would prefer if the front-end coding I do to was used by the developer instead of going to waste.
However, this workflow hasn't been compatible with Drupal dev partners so far. Because they use themes, and retro-fit them to the design I give them, they aren't able to use the HTML/CSS/JS work I do. Moreover, I have a responsive framework that I like (Foundation), and my developers want to work with the standard responsive Drupal theme (Omega). I don't like Omega because it isn't fluid.
Then there's things like my developer telling me they can't do a carrousel that uses CSS (background-image), because the available Drupal carrousel modules are all based on using the HTML img tag. Does everything have to be based on modules?
Going back to the HTML/CSS inconsistencies and the time-consuming design QA, I think this comes from trying to retrofit a theme. The code is very messy and it makes it hard to target elements for styling. It also makes it impossible for me to do my own CSS changes if I want.
So, in short, I'm looking for a completely different design workflow, and I'm looking for feedback on whether it's workable in Drupal without inflating costs.
Is it possible in Drupal to use front-end code (provided by me), throw in some PHP tags, and end up with cleanly-coded pages, instead of relying on themes? Would this reduce costs (because the HTML/CSS/JS is provided), or would it inflate costs (because it's easier to use a theme)? Are there any security issues involved? Are there update issues involved? In short, what's the big advantage with working with pre-fab themes?
I really, truly appreciate your comments.
We usually develop from the backend to the front end. Modules like Views add many div tags, classes and tags so the theme developer can make better use of them and fine tune the design.
I do not think that is a "messy" code unless you are doing all of the work in tpl.php files.
Modules simply processed the data. It should not heavily theme the output. For a better understanding, see the image below (from drupal.org):
If you want to do any database intensive work in the template level, you will have to load many stuff again that you could simply do in a module.
In my opinion, if your developer is not hardcoding the HTML stuff, he is doing it right.
Keep in mind that you can override most of the theme functions so you already have the flexibility if you want.
Is it possible in Drupal to use front-end code (provided by me), throw
in some PHP tags, and end up with cleanly-coded pages, instead of
relying on themes?
Yes. But you can't simply use slider-image.php like files for that. You will have to add necessary theme functions to and pass the variables to it. IMO, it's relatively more work if you need to completely rewrite the theming functions.
Would this reduce costs (because the HTML/CSS/JS is provided), or
would it inflate costs (because it's easier to use a theme)?
I do not think so. If you have multiple backend developers working on code, ask the theming team to make changes to HTML/CSS. CSS can make your site look worse, and a security bug can ruin your business, expose all your user information or even worse.
Are there any security issues involved?
Most likely. Default theme functions tend to come with much better security. Even though few bugs come out, they will get fixed soon by the community.
Are there update issues involved? In short, what's the big advantage
with working with pre-fab themes?
Because there is a whole lot of work that you can simply adopt. That will also block you from adopting others' CSS work though.
I work somewhere with highly stylized well thought out front end builds which are almost not compatible with the way Drupal theming is handled currently. Having front end developers track down bugs is also very problematic. It looks like there's some acknowledgement of this in Drupal 8 at least. At this point we frequently rework Drupal to work as an API and then build a lightweight PHP Framework app on top to pull content when we need it which gives us total flexibility to do anything we want with the frontend. Another alternative is to checkout Expression Engine where you are explicitly telling it what markup you want outputted and how you want your content to be placed in the markup.
The holy grail would be a very lightweight layer that was part of Drupal where we could use Twig to pull the content the way we want it and all HTML output was defined in Twig.
I've been coding in PHP for 4 years and even I find it so convoluted and hard to grasp. I have no idea how they expect designers to manage theming.
I know basic theming, theming with tpl files, views templates, contemplate templates etc. However I get lost whenever I enter the template.php file.
I needed to theme a node input form for a custom content type. I wracked my brain over it with like 7-9 tutorials and it's still not coming together. I understand why module building can be complicated - because most people who work with modules are developers anyway.
However, when even a developer can't understand theming, it's definitely over-engineered!
Maybe it's my fault, maybe I didn't learn Drupal properly. In that case, is there a step-by-step system to becoming a Drupal guru?
Theme is really not that difficult, if you only know basic php. You have 3 ways of altering the markup, the css and js, you should be able to handle.
Template files. By creating a template file in your theming and naming it correctly, it will take precedence over other template files, and you can thus create custom markup for views, nodes etc. By creating a template for a noce type, you can do stuff like printing out the cck fields in any other instead of using $content. All you need is on the node object.
Preprocess functions, which are placed in your theme, will give you the possibility to add or alter variables that will be used in your template. You name the functions like hooks: yourtheme_page for the page template yourtheme_node for the node template etc. Here you can create some custom logic, or modifications, to help make your templates more clean and just handle the printing of the variables.
Theme functions. You can overwrite theme functions to alter the markup that's used. You only need to create a function called yourtheme_[theme_function_name]. You don't need to understand much php to do this. Often, you can just copy the original theme function, and make a few alterations in it to get the markup you want.
With the above you can do 90-95% of what you need. Forms are a bit special since you in Drupal 6 can't alter them (easily) in your theme. Instead what you want is to create a small module and use hook_form_alter, which allows you to modify the form, text used on buttons etc. This is changed in Drupal 7, which will be even easier to theme.
So it really isn't all that complicated, just use the 3 basic tools described above. The tricky part can be to name your functions and templates, but devel themer can help you with that. Another tool you use is devel which can assist you in printing out variables so you can inspect them and see what you have available, fx CCK fields on the node.
Maybe you should get a copy of Front End Drupal.
In my opinion, Drupal theming is not difficult once you wrap your head around the concepts like templates, overrides, .info files and preprocess functions. Those things are not directly related to php skills, it's all about understanding the system.
It's interesting to see that you're a themer, yet you only talk about php, not CSS and HTML. In my experience, a lot of theming tasks can be accomplished with CSS, without even touching php.
Finally, I don't know if you are using a base/starter theme (like Zen or Genesis) already. I recommend using a base theme and realizing your own design as a sub theme.
Most people get an 'ahah!' moment when themeing suddenly starts to make sense.
I'd argue that this is probably tougher for experienced PHP developers, since you have to get past a lot of concepts that don't make sense in vanilla PHP ("the function is magically called at the appropriate time ... because of how it's named?!")
#googletorp's answers is pretty comprehensive, so I'll just add some practical tips that helped me along:
1) Try building a module that implements it's own themeable output and simple hooks. Hooks and theme functions make a lot more sense when you see how modules are actually calling them and using them.
2) Make liberal use of the devel module, especially the Theme Registry menu (note how it changes when you add a new theme function), the 'Render' tab, and the dpm() and dvm() functions
3) Buy a old-tyme dead-tree book on Drupal themeing. The online docs are really outstanding if you already know what you're doing, but can be extremely confusing if you're not sure what you're looking for.
4) Empty your cup. At the theme level, PHP is really just for simple logic and syntax -- almost everything of substance is getting handled by Drupal API functions. Try to think like a Drupal developer and not a PHP developer (i.e. don't assume you know how to do something just because you built a vanilla PHP site that does the same thing) and you'll have an easier time.
Keep with it! The theme system is actually really easy to use once you've figured it out.
to answer your question on why it is so hard:
Drupal themes may seem overwhelming, due to the sheer amount of possibilities, see #googletorps answer for a good overview.
Having "many ways to do one thing" brings power: power users can choose the best of all possibilities. But it also brings complexity: new users don't get a good lead, because there is no "you should do it this way. fullstop."
Alongside that amount of ways to get stuff done, there is the problem of nesting. Drupal has a concept of very deeply nested items. To take a random, yet simple example:
username<menuitem<menuitem<menuitem<menu<block<region<page.
Will render a menu-item, containing a username in a three level deep menu-item in a sidebar-block.
Where most templating-environments have concepts of a page, containing several "contents" that, at most, might contain some partials. the nesting is at most three levels deep. And each level has a clear, distinct area of expertise. Drupal does not have that: the nesting is fairly arbitrary. And each nested item is no different from its parents. This, again, offers power-users a great concept and power to work with, but is hard to grok for new developers/designers.
Lastly, another reason why it is hard to learn, is that the Drupal online documentation is more a wiki then a read-from-begin-to-end manual. There are great books that fill htat gap, you will have to buy them, though.
If you haven't seen it already, this is a great presentation on why Drupal 6 theming is difficult and how it is improved in Drupal 7. There is hope! The video made more sense to me a second time watching after more experience theming.
http://sf2010.drupal.org/conference/sessions/design-and-theming-whats-new-drupal-7
One of the biggest tricks is to override something that is normal rendered with a theme function into a template. This gives you much more control over the markup, and also lets you use the preprocess functions to manipulate the variables before handing it over to the template.
This is a huge boon to theming forms. See a short video that explains it better than I could here: http://drupaldojo.com/session/fine-tuning-ui-theming-forms-drupal-60
I starting working with WordPress as a CMS, now that the V3 makes it way easier to manage taxonomies and custom post types. My work is mostly focused on developing plugins and themes.
My biggest plugin does some admin stuff (add admin menu items and the related pages and features), but also does some importing and exporting, and hooks some of the base post processing treatments ("when a new post is created").
My biggest theme is pretty small, and all it does is display custom posts in a custom way.
After a few weeks of work, I have several thousands of LoC, and it's getting harder and harder to dig into it. Which leads me to the following question: How do you organize your WP plugins code? And what about your WP themes code?
several thousands of LoC
That's pretty epic! I've always found the beauty of WP is that I can, as jQuery put it;
Write less, do more!
You might be much better off using Pods CMS alongside WP to cut down your code.
This is how we structure client deployments that include themes, third-party plugins, and custom code.
wp-content/plugins only contains third-party plugins, no code in here is modified, and the site should not be deadlined by any of these plugins being disabled / removed.
wp-content/themes should contain the code related to presentation of the front-end. The trick is not not overload the theme (functions.php and other theme-related files) with code not directly related to presentation.
mu-plugins/ contains all of your implementation-specific business logic. Things in here should never be disabled, and are required for operations.
That is avery brief summary, but in a nutshell that is the logical compartmentalization of code that we've found to be most failure proof.
Why not to split plugin into several files by function? The same goes to themes. Any problem you have with that?
There are basically three ways you can do this: prefixed functions, with require_once's including files by functionality, which is quite common.
The other "right" way that's touted a lot is having one giant class with all your plugin code in it. While keeping things nice, as you said, once that file gets into the thousands of lines of code, you're screwed for manageability.
The way I like to do it is a way coming from my C# background - have one main plugin class, and other "worker" classes (you can put them in a namespace to keep classnames short). For example, have a class dedicated to the admin section (it can have its own little "subclasses" too, say one for each page). It'll take a while to refactor all this code into the different classes and files, but it'll be worth it - it'll be much easier to keep track of everything, as well as for example getting people to work on the codebase together. It also forces you to think more of how your application all fits in together, which lends to better thought out code.
I'm actually writing an article series about this, outlining the three different methods. You can take a look at the first instalment here. There are two more coming in the following weeks.
Hope I helped!
I'm implementing "news" section in asp.net website. There is a list of short versions of articles on one page and when you click one of the links it redirects you to a page with a full article. The problem is that the article's text on the second page will come from database but the articles may vary - some may have links, some may have an image or a set of images, may be differently formatted etc. The obvious solution that my friend have come up with is to keep the article in the database as html including all links, images, formatting, etc. Then it would be simply displayed on the second page. I feel this is not a good solution as if, for example, we decide to change the css class of some div inside this html (let's say it is used in all articles), we will have to find it and change in every single record of the articles table in our database. But on the other hand we have no idea how to do it differently. My question is: how do you usually handle something like this?
I personally don't like the idea of storing full html in the database. Here's an attempt at solving the problem.
Don't go for a potentially infinite number of layouts. Yes all articles may be different but if you stick to a few good layouts then you're going to save yourself a lot of hassle. These layouts can be stored as templates e.g ArticleWithImagesAtTheBottom, ArticleWithImagesOnLeft etc
This way, your headache is less as you can easily change the templates. I guess you could also argue then that the site has some consistency in layout.
Then for storage you have at least 2 options:
Use the model-per-view approach and have eg ArticleWithImagesAtTheBottomModel which would have properties like 1stparagraph, 2ndparagraph, MainImage, ExtraImages
Parse the article according to the template you want to use. e.g look for a paragraph break if you need to.
Always keep the images separate and reference them in another column/table in the db. That gives you most freedom.
By the way, option #2 would be slower as you'd have to parse on the fly each time. I like the model-per-view approach.
Essentially I guess I'm trying to say beware of making things to complicated. An infinite number of layout means an infinite number of potential problems. You can always add more templates as you go if you really want to expand, but you're probably best off starting with say 3 or 4 layouts.
EDITED FROM THIS POINT:
Actually, thinking about it this may not be the best solution. It could work depending on your needs, but I was wondering how the big sites do it. If you really need that much flexibility, you could (as I think was sort of suggested) use a custom markup. Maybe even a simplified or full wiki markup. I'd still tend toward using templates in general, but if you need to insert at least links and images then you can parse for those.
Surely the point of storing HTML with logically placed < div >s is that you DON'T have to go through every bit of HTML you store to make changes to styles?
I presume you're not using inline styles in your stored HTML, and are referencing an external CSS file, right?
The objection you raise to your colleague's proposal does not say anything about the use of a DB. A DB as opposed to what: files? Then it's all the same. You want to screw around with the HTML, you have to do it on "every single record." Which is not any harder than "on every single file." Global changes are a bitch unless you plan for it by, say, referencing an external CSS. But if you're going to have millions of news articles, you had better plan on versioning the CSS as well.
Anyway, the CMSes do what you're thinking of doing. Using a DB is a fine way to go. How to use it would depend on knowing the problem more intimately.
Have you looked into using free content management systems? I can think of a few good ones:
Joomla
Drupal
WordPress
TONS of others... just do some googling.
Check out this Wiki article: http://en.wikipedia.org/wiki/List_of_content_management_systems
I'm about to embark on a journey to build a multilingual Drupal site, where I will most likely have to use Views, Panels and Taxonomy pretty heaily. I am a bit worried about the new-node-for-every-language approach, especially using Panels.
So far I've gotten it to work similarly to what I want by not having multilingual support for the Panels content-type, and fetching content that is from Current language and language neutral . This seem to work as expected, but I'm seeing some problems with it. There might be the occasion that I will have to have a language specific Panel (not published in English for example). If I need to have all my Panels multilingual, there seems to be alot of work to place the nodes for every column in every page in every language. I'm thinking I could possibly solve this by fetching the content with some kind of view with arguments, but this will most likely also lead to alot of work.
Is there some proper way of doing what I'm attempting to describe, or do I have alot of seemingly unnecessary work to expect?
I assume you have i18n module (http://drupal.org/project/i18n) and Views module installed. Then you can create a view for each language - one can choose language in "Filter" section of the view definition.
Once you have views, then you can link them to menus or blocks. The problem is you must have a separate version of block or menu for every language, with a proper view associated - Drupal is choosing proper language version itself according to the configuration (typically content type set in a browser). I haven't found any easier way of doing that.
Fortunately preparing multilingual content is not that hard thanks to the "transalte" functionality for nodes after enabling i18n module, so new node for every page is something one can live with.
BTW you are right that the way Drupal is doing i18n is not the best solution one can think of. I am having hard time with it sometimes.
Well there are some serious issues with views over translating taxonomy terms or vocabs names. This could be resolved with some extra modules or / and custom PHP code inside views fields. Usually 70% of modules does not support translation, then you need to patch them to support it. While others does have translation possibility, but it could be two possible ways: uses variables table to hold different translations UI dependent (need to switch to other language to find a string) or uses translation field tables to utilize "translation interface" from admin menu.
So far that's it :)
I wish you luck!