I'm developing an online magazine, and am using Views to generate blocks for the homepage.
I am using a slightly customized Article as the content type for most of my data, with Views providing blocks with the necessary fields from those Articles. For example: the Latest Blogs View shows the Short Headline and Teaser fields, but the Top Headline View provides a block with the Image and Full Headline fields.
Right now I'm using Views to filter Article by tag, so Articles need to be tagged to show up on the homepage. Most of my blocks are lists and don't need the tightest sorting flexibility. However, some blocks are not lists, or it's important for the end user to have control over the display order of Articles in certain blocks. Is there a way to enforce site-wide 1:1 tagging for term:article relationships. For example, I want to ensure that only one Article is tagged top.news.1 (the first Top News slot), and likewise only one article is tagged top.news.2. When someone wants to add top.news.2 to an Article, the one Article that already has that tag will lose it. Or something like that.
I have played around with Views enough to gather that it is really powerful, so this level of microcontrol might not be necessary with the right configuration, but I think restricting taxonomy versus configuring Views filtration would address the problem more directly.
I've looked around the web and haven't been able to find anything really relevant. Sorry if I missed something obvious.
Thank you!
Is it correct that you (or your site editor) want the ability to:
spotlight a certain nodes
arbitrarily change the order of the spotlighted nodes, or add/remove a node from the spotlight while keeping the position of the other nodes?
If so, your best bet is likely Nodequeue, which does exactly that, and allows you to restrict the number of nodes spotlighted. It's very easy to use and our non-technical clients have no problems with it.
If your use case is different from that or requires more flexibility, Nodequeue may not be the right fit, but it works great for the specific example you're describing.
Related
I have posted this question to the plone user mailing list as well, so I hope nobody minds that, especially since it is nothing I have hidden.
Since my question is hard to put into a generic question, I'll try to explain it with a (hopefully) illustrative example. Please bear with me on this one.
Content Type: Product
Each product shall have several explanatory sections with a title and a rich text as the section contents. Said title should be either taken from a listen of predefined titles (by the editor) or entered freely once (the exception).
Since the site will use Dexterity and requires a multilingual approach (plone.app.multilingual), centralizing the titles saves the translators some headaches and avoids unnecessary duplicates. Also in general, the styling is done through Diazo, so the sections will be mapped on a nice widget.
My problem is, how to map this onto Plone with usability for the editors and translators as well as efficiency for the software stack in mind.
Approach 1
Put the titles in a hidden folder and use a vocabulary in the Product content type. Also make the Product a folderish content type and require the editors to enter each section as a separate item into said folder (e.g. ProductSection non-folderish content type). Repeating that process for each product. But this seems not very user friendly and imho would not scale very well with the number of products and sections.
Approach 2
I could naturally also reduce the Product content type in general to just one single rich text field and have the user enter each section as a div block with a headline and a paragraph. Even though this is the easier way to implement this, it puts the burden on the translators (many duplicate translations) and on the editors (e.g. changing a title for marketing or whatever, requires changing it manually through all products etc.).
Again, please remember this is an illustrative example of my problem and here Product is really that, a product from a company's portfolio and not a Plone add-on. ;)
So my question basically boils down to this: Which approach sounds more reasonable? Or is there a more standard and/or creative way to solve this problem?
Thanks a lot for any suggestions and help in advance. It is very much appreciated...
UPDATE
After I received a very enlightening answer on the plone users list, my current thinking (untested, brainstorming) is as follows:
Product will be a custom form (due to MultiWidget, see below)
the section blocks will be saved in a list on the Product object (titles will be a choice field only)
the section titles will be saved elsewhere and manageable through different means (needs to be accessible by a Site Administrator, so anything ZMI is out of the question)
easy editing through z3c.form's MultiWidget (that's the key ingredient, actually)
If this works out and plays nicely with Dexterity and multilingual, I guess that's quite the optimal solution for everyone involved.
Naturally I'd appreciate any and all kinds of comments or suggestions. Maybe I am totally on the wrong track now but based on what I read up, this should actually work fine.
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!
I'd like to add a block to the user profile that shows them content listings in their groups based on tags that they have in their profile.
(ie: someone puts a bike up for sale, the user has listed "bike" on their wishlist, it should show up to get their attention)
Since these tags vary user-to-user, I'm not sure exactly how to set up the filter.
Going a little farther, can I sort them by the number of matching tags?
I've found that taxonomy terms and views can be very tricky to get right. The main problems is that taxonomy terms has a one to many relationship with nodes, and views is built to be generic.
It might be quicker to create such a block in a custom module instead, because you may very well get stuck in views before getting what you want. Also you most likely have to create your own sort plugin for views, to get the sorting you want. I haven't seen any module creating something like that, and I don't think it's possible with views core. Creating plugin for views can be very harry, the first time you do it, so unless you know your way around views, I think you will have more luck just creating a block yourself. It's much simpler, than having to extend the views functionality.
Have you looked into Views? You can set up a block with views that retrieves (almost) ANY information from the database.
In your case, you can filter the information that you need and that belongs to the current user, also, sorting is doable via the Views administration.
I am currently looking at using either the Taxonomy or CCK module on my Drupal site as a means to create a hierarchical system. However, I'm a little confused on which one would best suit my needs, or if there is something else that would work better.
Basically, there will be probably 70 or so "mini-sites" on the website I'm working on, each with a landing page and about 5 sub-pages of detailed information. I need a way to mark those sub-pages as being sub-pages of their parent page, as well as create a menu system to navigate between them.
What is the best way this could be done? Thanks for your input!
Have you tried using the Book module? It might take a bit of theme-adjusting to get it to look right it seems to be how most people settle on displaying this type of page structure.
Depending on your needs, Organic Groups and/or Spaces can be a good alternatives, since it'd allow you to easily control themes, permissions and other settings in a mini-site basis.
Each Mini-site would be an OG node and/or a space, and subpages could be organized in tree structure as well, using Book module from Drupal Core.
The best option is the book module. It gives a way to organise hierarchical content in a book manner. There are 2 blocks generated automatically: the book navigation and the book outline which gives, for each page, a link to the previous and the next content.
For more information drupal handbook: http://drupal.org/handbook/modules/book
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.