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!
Related
Is there a module for Drupal that searches the final versions of the rendered pages (in the same way that Google would, for example) instead of all the nodes? The way I have set up my site involves views that display several nodes depending on what the page is. I don't want to search through each of the little boxes, but the finished version of the page instead.
For clarification, you are searching for a way to index the dynamic view content, and keep the search index out of the individual nodes?
I think your best bet is https://drupal.org/project/search_config
A lot has been added to Drupal 7 core, so that many 'search restrict' modules are now obsolete.
If this is still not what you are looking for, and you feel a bit adventurous, you can find various guides from before this was incorporated, and go the way of custom code. http://www.lullabot.com/articles/hiding-content-drupals-search-system
http://www.acquia.com/blog/drupal-search-how-indexing-works
If it is slick and stable, submit it back to the drupal community. They will be your friends.
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.
(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.
When using the core drupal 'Upload' module, I get a user-friendly way of uploading files to my website and providing a download link on the page.
But the page is formatted like this:
Attachment Size
Somefile.doc 13.37mb
Article contents here
And I would rather it was the other way around, showing the article contents before the attachments. I have explored how to do this and come up blank.
I'm using the 'Garland' theme if it makes a difference to how I can implement a solution.
You must be using some module that changed that order. Or had it in use. Since Drupal-core has no way to re-order fields, and Drupal core upload-field has hardcoded its position in the form and in the display.
However, if you want to re-order fields in Drupal nodes, there are several ways:
The first option would be to solve this in your theme. But since you are using a vanilla (core) theme, changing the code of that theme is out of the question.
The second option, just as valid, but a lot more disrupting, is to involve the "CCK (content construction kit)" module. A warning is in place: this module is both complex and powerfull. Over 90% of the Drupal sites use this module, but since it is large and heavy, it will make your project a lot more complex, debugging a lot harder and performance a potential problem. Use CCK only if you think it fits well in your entire project, not just for re-ordering a set of fields.
The third option is to write a simple module that re-orders fields.
With hook_form_alter(), you can change the appearance, workings and order of fields in any form, including the node forms.
With hook_nodeapi(), you can change the behaviour of any node on many stages, including when it gets displayed: to re-order fields.
As said above: you may have such a module (with hook_nodapi) re-ordering your output, since Drupal core upload has the weight of that field hardwired.
I have inherited a Drupal site on which (for some reason) there are two different content types for news: one for press releases and one for everything else. I would like to combine the two and use a taxonomy to categorize the press releases and other news types.
Is it even possible to do this? The site is using a number of modules, including Views and CCK, and I don't know how much a change like this would affect module data.
http://drupal.org/project/node_convert
The module linked above works extremely well for migrating nodes from one content type to another.
When you are done, you can then use VBO (http://drupal.org/project/views_bulk_operations) to mass manipulate the taxonomy changes you need.
Is it possible? Yes.
Is it easy? No.
To quote a well used phrase:
If it ain't broke, don't fix it.
You can get your site to work like you describe, and if you started with a clean site that you were going to build, it would be no problem. It's just a matter of choice. Now when you do have a database with views, content and other stuff, it wont be easy. You would have to:
Go through all the views, and set them up to use taxonomy and the 1 content type.
Migrate all the data into 1 content type. This might evolve setting up CCK for this content type to fit both, and take this into consideration when migrating the data.
It's possible the content types are used elsewhere, in custom modules, settings etc, these need to be tracked down and fixed as well.
So it's a lot of work with little/no gain.
Of course it's possible. The change won't necessarily be difficult if you've got a good understanding of how each content type is being used. You'll just need to be careful as it's a fundamental change.
If you think that the two different content types are not warranted and it is, in fact duplication of information then you could justify merging the two. Good house keeping!
You could phase out the unwanted content type over time and then when you're confident you've got it just right, build your self a merge module to move the old nodes into the new format. You could also build yourself test views and content types that you can dispose of later.
It may also help to install the devel module to get a programmatic overview of what your nodes look like. You shouldn't leave this module running on live sites as it effects performance.
Sometimes, there's a fair amount of crossover between content taxonomy and content types. It helps to ask yourself: What is a classification of an object and what's an attribute?
It is possible to change the content type of nodes.
The problem is if the content types use different CCK fields, which are present in a content type but not in the other. In such case, if you change the content type, those fields would not appear in the converted node; you should convert all those fields manually, or create a custom module to do that.