I'm trying to create a simple module to preview themes in Drupal. Each user has their own custom node and I want to be able to show them a preview of how the theme will work without them actually enabling it. Right now this is what I have:
function theme_preview_info($new_theme, $node_id)
{
global $custom_theme;
$custom_theme = $new_theme;
$node = node_load($node_id);
return $node->body;
}
It will display the content of the node, but the formatting is all messed up. How can I properly display the node exactly as it would as if i went to node/1, but instead view it at theme_preview/theme_name/1?
Do you have any experience building Drupal modules?
If not, you may find that what you are trying to do is not all that simple.
You will need some interface for the user to choose which theme they are previewing. Then, you will need to hook into Drupal's routing to direct users to the appropriate node using the selected theme preview based on a customized path alias (theme_preview/theme_name/1). There's most likely a lot of other back-end overhead that I'm not anticipating at the moment.
If you have experience with building Drupal modules, though, that might not be a big deal.
Switching out the theme is probably the easiest part. If you're in Drupal 7, you can use an implementation of hook_custom_theme() to change the theme used for particular nodes based on your intended criteria (i.e., which theme the user selected).
http://api.drupal.org/api/drupal/modules--system--system.api.php/function/hook_custom_theme/7
This way, you can actually allow Drupal and the selected theme to completely handle the rendering of the page, giving a more accurate preview.
I'm not sure how exactly you would go about creating the user's theme-switching interface or routing the user to a specific path alias for each theme selection.
You also might want to look into the ThemeKey module (http://drupal.org/project/themekey). It's possible you could use that module somehow to simply set up ab version of each node to be viewed in each different theme.
Related
I was wondering if someone with Drupal experience could advice what are the best practices in the following situations. I think they are all common tasks for any website that you build.
Display a custom HTML of a certain content type at front-page (e.g., only the link and title).
Should I build a module only for this?
Customize the login form HMTL, including inputs, labels etc, to something very different from the default login block.
Again, another module?
Format the node view of some content types; for example: showing additional fields values. I have some Joomla experience and with it, it's very easy to override the template on your theme.
But with Drupal, it seems HTML is hard-coded on PHP files and there are very few thing that uses templates. Or am I missing something?
You should create a view (from Views module), and for this create display 'block'. This block you can use later on your site. Within your view settings you can choose what and how you will display.
It depends what you would like to put there. If you put just some static text, change theme could be a solution. But still, a bit smelly. What you should do, is to create a module use hook_form_FORM_ID_alter and add both - field to your form, and code to use values which user added.
Change templates for this content type in your custom theme; or use Panels module - here you have nice introduction; or use Display Suite module - which do pretty much the some work as creating a template
html is in php files, but where else can it go? Drupal also has it template overwrite system. The customization of the theme can be usually done using that alone.
As for your questions (there are also other alternative)
load the content type in view/block, display in list format on home page.
create your own theme for css changes. create custom tpl.php for
layout, and div naming etc.
same as above.
It doesn't hurt to create a new module, but generally it's not necessary unless you are going for something like a muti-step form.
You can use both Views & Panels in order to achieve what you've mentioned above.
For instance, Panels gives you the option to override the home page with your own content. This content can be organized with Views.
From drupal.org:
"The Views module provides a flexible method for Drupal site designers to control how lists and tables of content (nodes in Views 1, almost anything in Views 2) are presented."
"The Panels module allows a site administrator to create customized layouts for multiple uses. At its core it is a drag and drop content manager that lets you visually design a layout and place content within that layout."
I am working with Drupal and Views module.
I am using the same theme with different Views.
I have created different pages which are listing nodes per viewname as this : views-view-fields--VIEWNAME--page.tpl.php but now when I click on an article title, I would like to personalize the node with the viewname, so I would like to use node-VIEWNAME.tpl.php, but it's not possible. The only thing I can do, is to create a node-TYPE.tpl.php but I do not want to follow this way.
So my question is how can I implement (may be with a hook function?) the node-VIEWNAME.tpl.php when I click on an article title (so when I have only one full article and which is defined by it's id in the url. This is for precision, I am not fluent in English.
Thank you very much !
Alexandre
The correct way to do what you're attempting - use the Display Suite module, set the view to point to a Display Suite object in the field settings, then click the gear next to that setting and pick the build mode you want to use. Then in your template.php file, do whatever special work you need to do to that build mode.
I'm new to Drupal. I want to create a contact page, so I copied page.tpl.php and renamed it to page-contact.tpl.php. I created some new elements in the page, so I can see that if I click on the "contact" link, I'll know that I went to the correct page.
Right now I don't see any change. Was there something I missed? Do I need to do something in the admin settings so Drupal knows which file I need to open?
I also tried clearing my cache.
In theory, this is a valid approach. Problem is, you'll be able to create a new layout for your contact page this way, but not necessarily change the contact form. If you wish to alter the form as well, I'd recommend using the webform module. It's pretty flexible when it comes to creating contact forms, plus, it creates a node, so you can style it with ease (either in you standard node.tpl.php or - even better - in node-webform.tpl.php). This is what I usually do.
There might be other solutions too, but it would help if you made it clear what kind of alterations you wish to introduce in your contact page.
When you say cleared my cache do you mean the browser cache or drupal's cache? Ensure drupal's theme registry has been cleared by going to /admin/build/themes, or logging out and back in.
I also recommend trying the webform module as mingos suggests.
Drupal core's built in contact module does not use any templates, so you'll have to use something like Webform if you want a per-contact template.
(I've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.
I have some nodes I am displaying in a view. They are displayed as nodes, unformatted. I would like the user to be able to choose from some predefined sort criteria ( via drop down list or similar).
So they could pick recently active, most commented, newest, etc., and re-query for new results.
Its easy with tables because you can make the labels clickable, but I do not know how to have similar functionality with a raw node preview display.
Just a thought, from me to me, and for anyone else who may be trying to do this.
An easy, sleezy option would be to just add another page view for each of the required sorts, and provide a link to these other views in the header of each of the pages.
This could also allow for (easier) linking to the individual sorts, so say if you have a sidebar block displaying recently commented nodes, you could adjust the .tpl.php of the block to have the title link to the view displaying the full set of recently commented nodes.
also im pretty sure there should be a way to do this with arguments, but i dont know how
Views 3 supports exposing sort order (just like you can expose filters)
Select the sort order (e.g. add sort by node creation date, then click on the settings for that), you should be able to expose the sort order to the end user. This is just like clicking on the settings for a filter and then choosing to expose it.
Standard views isn't going to support this, so IMO you're best off implementing a custom solution using just a plain old view and this jQuery plugin. You can either do this at the theme layer (the same way as any other JS in a theme) or a custom module (via drupal_add_js() to add the plugin and your bit of custom code). Either way will work, although the custom module has the obvious benefit of being theme independent (and thus more portable).
If you go the custom module route, please consider releasing it as a contrib module on http://drupal.org.