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.
Related
I want to create an online Arabic-Hebrew Dictionary for one of my clients and this is my first experience in Drupal Module Development. If I were to create the Dictionary in custom PHP and MySQL, I would create a number of database tables and do my queries accordingly.
I know that there is a built-in content type in Drupal 7, should I use it or create my own content type, If I should create my own content type, how can I do it ?
Thanks!
The built in content type will give you a Title and a Body, you can also use taxonomies in order to get more specific queries.
Creating your own content type will depend on your site structure. If the above is sufficient, simply use or modify the built in content types, otherwise create your own.
My advice would be for you to experiment with Drupal, watch various tutorials, then decide on the structure that would be best fit your requirements.
Your question is very vague, there are a lot of resources out there for Drupal beginners, you'll get a more detailed answer by checking tutorials first.
I believe that it depends. It generally is better to build upon the existing content types as much as you can. But if you determine that it would be too awkward/inconvenient to build upon the pre-existing content types in order to get the best solution to your problem, then you should programmatically create your own content type in your module.
Whichever path you choose, make sure that you properly document your content type structure, so that whenever you or someone else has to use that module, they will know exactly what each field is being used for, any dependencies, etc.
I've recently taken on a project from a client of mine, after a lot of persuasion I've managed to finally get the website under some kind of CMS. I'm pretty new to Wordpress I've come from an ExpressionEngine background and fancied trying something new for a change, so excuse the lack of knowledge (I'm trying my best! :D).
Now The issue I'm currently facing is that they have very specific directions regarding how they want their content displayed on their website and more importantly how they would like to manage it. They are a travel agent I'm currently putting together the resort directory that will display all of the resorts they offer.
In regards to the current structure of the directory it will be made up of 4 different sections. To give you a better understanding of how I want things to work take a look at this hierarchy below, (I've used turkey as an example, these would need to be dynamic):
/destinations/ This will be our destinations page that will list
all of the countries they currently
offer. I imagine this to be a static
page with some content about the
countries on offer with a list of the
countries below (These will be our
parent taxonomies).
/destinations/turkey/ This will be our parent taxonomy. This
page will also have to have the
ability to add some static content to
insert information about the country
and its locations. Below this will be
a second list, these will be the
different areas of turkey (These will
be children of the parent
taxonomies).
/destinations/turkey/belek/ This will be our child taxonomy, This
page will again need to have the
ability to add some static content.
It will also include our list of
resorts that my client offers within
this location (These will be our
entries/posts).
/destinations/turkey/belek/resort-name
This will be our post/entry page,
here we will have all of the
information on the select resort, the
specifics of this aren't an issue and
I've already got this sorted.
Now, I've done a lot of reading up on custom post types, custom taxonomies and their abilities and uses but I'm hit with a situation at the moment where I can't decide on which route I should take. I've been experimenting over the last few hours with the setup of one custom post type (for resorts) and one hierarchical taxonomy (for locations). Which works some what ok BUT due to the limitations of the taxonomy UI within the admin panel it doesn't allow me to add my static content/images etc. (I'd much prefer to use a WYSIWYG especially from a clients point of view).
So this makes me wonder if it would be worth making two custom post types and scrapping taxonomies all together, making one of the post types resorts and the other locations. With the locations post type I could set it up like the pages module (which would give me hierarchical controls to allow me to organise my locations how I had originally planned) but is this a wise move? I mean from what I've read you shouldn't really organise content this way but I've got a feeling that maybe just a clash of contextual semantics (I could be wrong!). Would there be any limitations for me setting things up this way should I wish to add search functionality in the future? Or anything else for that matter?
I thought I'd mention this before I FINALLY click the submit button (apologies for the great wall of text) but pages... I've read here that they are powerful little gems within Wordpress, how should I be taking advantage of these if I'm using custom taxonomies? How well do they work with listing categories are they what I need?
Right, that about wraps up everything I've got to ask for now - maybe I should have split this into a few posts but hey! I hope this gives you guys enough information about what I'm trying to achieve and please if I am going wrong feel free to point me in the right direction I'm really eager to learn more about Wordpress and it's capabilities.
Regards
Danny
While this is one approach, it sounds like what you really want to be using (rather than custom post-taxonomies) is simply the Page functionality of WP. Everything you're describing is simply the hierarchical structure of the navigation of your pages. Yes, you can use the custom taxonomies to accomplish this same thing, but since you're describing things that tend to be "one" thing (ie: a single resort) you probably don't need the taxonomies.
You might want to look at another option: PODS CMS http://podscms.com
This will give you a simple structure to add custom features to your posts relatively easily... Things like pricing, amenities, and other "organizable" details can be stored using PODS and then referenced across your site for better usability. It might be worth a look!
It may sound 'weird' but I need to have a view that lists all the content types I have.
For example i have two content types : contenttypeA, contenttypeB
I want to create a view that just displays the two content types (and show number of items of that type, but that can be done later).
For now what I did is add one content of each content type and list them but only show the 'node type'; it works well if there's at least one content but I want to display even without any content of that content type.
Any idea ?
Introducing the node_type table to Views requires a custom module and some Views API knowledge however http://drupal.org/node/1001222 will give you a head start.
Use a Customfield: PHP code field and custom code the whole thing with PHP. This is provided by the Views Custom Field module.
Use the Table Wizard module to make the node_type table available to views. You may need to use the Data module as well since they say that all future development is going there.
Expose the node_type table yourself by writing a custom module using the Views API as suggested by chx.
Number one is the quick and dirty way, but number 2 might be a little more manageable, but I am not completely sure it will do everything you want. If you do number 3 make sure you contribute back to the community by putting your module on drupal.org.
There is no native functionality in Views to do that. You can write a static page or (overkill) a module that provide a "system"-like type similar to Views Watchdog.
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'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!