Can we extend / replace the labels presented in the SDL Tridion 2011 Content Manager Explorer?
I'm specifically interested in changing the root items under publications.
Background
SDL Tridion has organizational items, which groups or "stores" items or building blocks (not to be confused with Template Building Blocks, a specific item).
For example:
A folder stores components, schemas, and templates.
Structure groups store pages.
Categories store keywords.
Under the default Publication, we get three options: a root Folder, a root Structure Group, and a label for Categories & Keywords (which contains Categories).
The Categories & Keywords label itself isn't a Category in the same way that Building Blocks is a folder. Dominic Cronin hints at the differences in this SO answer.
Question
I can rename and localize Building Blocks and Root. But can I/where would I
extend/change the Categories & Keywords label? I'm thinking it's
part of Tridion.Web.UI.Strings. It would have to be translated/translatable.
Alternative programmatic suggestion?
Use cases for changing these include:
Change folder, SG, and maybe the Categories & Keywords name to make it easier for authors to have context on where they're at in the BluePrint (I sometimes forget context when the Publication name isn't visible)
Reduce confusion for when "Categories & Keywords" or other Tridion terms confuse authors. This should be used sparingly, but maybe "Tridion Categories" could help distinguish between the "Categories" that an organization already uses.
Great question. It is possible to use a DataExtender to modify the Tridion response, including the tree. I know an extension has been written before to hide certain parts of the outbound email distribution list tree based on group membership.
However, I don't think I would recommend a GUI extension for this. Instead I suggest filing an enhancement request through customer support since it should be part of the product and you have a good use case that applies to many customers.
You can make a DataExtender, which will override Title attribute for this particular node. You will recognize "Categories and Keywords" node by it's ID - it will start with "catman-" prefix.
Related
Just started using Drupal and tried to understand the core concepts. I have a developer background but I would like to use Drupal as a site builder and not digging into the code.
I'm trying to build a website which lists various vendors. One could be a Restaurant, another can be Photographer and other possible services (I have like 15 different ones).
They all have some things in common like Title, a Location (used Taxonomy/Vocabulary for that), description, image gallery, address, website, office hours and so on.
But they also have some custom fields. Restaurants can have fields like Facility options:Parking, Smoking area, etc or Capacity; Photographers can have others.
So there are lots of fields which are common for each vendor and some are are unique per each vendor.
What's the best way to implement this kind of structure as a Site builder?
I tried using Entities via ECK (Entity Construction Kit) and defining Entity types (as Vendor) and Bundles (as specific Vendors) but then I'm really limited in defining the common fields on Entity type level since Properties does not seem to be flexible in this regard, meaning that I cannot define them as normal fields and can't associate to them various widgets but only as a text input. Not sure if this a limitation of ECK or of Drupal 7 itself?
On the other hand I see the option of creating normal Content types for each kind of vendor which seems like alot of repetitive work, not sure if this is the right way (that's my only option at the moment)?
Maybe I should start learning more of Drupal and do some coding to create specific entity types? - but this means being more than a site builder. Since it will be a big project will this save me of some trouble later on or you see that I can accomplish the task easily without this extra effort?
Also by coding I'm not sure if there are easy ways of defining fields/widgets for Entity type Properties.
I would later on want to use faceting as well for filtering which will be based both on the fields which are common and unique for each vendor type, not sure if this is an important factor when creating the structure.
Any feedback is appreciated!
I'm a part-time developer (ranked Enthusiastic Amateur) and am trying to develop my first multilingual site in Drupal 7 using the Internationlisation (il8n) suite.
After following the initial setup directions, I'm now trying to implement a "featured article" column where Articles flagged as Featured appear in a list in the right-hand column of the page.
Ordinarily I'd simply do a "db_query" to return a list of node ids and then do a node_load() for each result.
However, how do I do this using il8n to ensure that I'm pulling out the correct language versions of the Articles?
Any and all help is greatly appreciated,
~Matt Bridger
Use the i18n_node_get_lang() function to check the language of the nodes and load only the ones with the right language.
Typically you would use Views module (http://drupal.org/project/views). To create a block listing the nodes you want, and then under Filter Language, use Content: Language set to Current User's Language to filter for only the language being viewed. With this solution, there is no need to write any code, unless you need some advanced theming for your list.
My Drupal 6 site uses 3 custom node types that are hierarchically organized: page, book, library. I want to use Solr to index and search the content.
I want the search to return only Book nodes in the results.
But I want the search to use the contents of children (pages) and parents (libraries) when performing the search.
Can Solr be configured to index & search in this way?
Thanks!
You are going to have a couple of issues with this:
Solr isn't hierarchical by nature, it's denormalized so indexing a heirarchy is hard.
You're going to have to figure out how to boost various terms/fields based on where in the hierarchy they are (is the library more important than the book, so to speak).
Drupal has a specific configuration related to nodes and modifying that, by default, wouldn't be the easiest.
The Solr implementation is tightly tied to the database, so modifying the configuration would probably take a lot of effort on your part.
I would recommend you don't try to implement this, but if you did you could look at the Apache Solr Attachments module. You would have to do something similar... basically:
hook_modify_query to modify the actual indexing of the node
custom theme your search results to display this hierarchy
Or you could create a single giant field with a bunch of searchable text and use that as part of your searches.
I'm creating a web application and I just want to know how to think about Drupal's db coming from an MVC background.
I have tables to represent people's data such as SSN, First Name, Last Name, Zip Code, Address, Language, Location. Now on the front end I want to create a form to populate this information for a bunch of subjects (people). I have my database normalized so the Zip Code has its own table (with a foreign key link to the person table). The "person" table has stuff such as First Name, Last Name, Address etc... and the "language" table will have the different language abbreviations (again with a foreign key back to the person table).
I would like to know how to move something like this to drupal's schema. I know I could create my own tables and link them back to the "node" table and then I guess build my forms to accept user input...but is this the suggested way to do it? I was looking at webform, but it seems this should be used for simpler forms where the database isn't normalized and everything is just stored in one large table. I'm not sure, but I would definitely love to hear what you guys think...and if you could point me to some resources that'd be great.
Drupal is flexible enough that you can create whatever tables you want and then write code to link them back to the node table. However doing this will mean that you end up with a lot of code which is very specific to your schema, and is not very interoperable with other Drupal modules.
You will find that you get on better with Drupal if you mostly do things the Drupal way. And only go for a very customized solution where you are doing something which isn't covered by standard Drupal modules.
For example you may find that the profile module fits your needs as far as standard information about people goes. The location module (specifically user location) will cover users addresses. By using these modules you are more likely to find other modules which work with them in future and overall you will find you have less code to write.
One thing you may find useful is the migrate module for getting your existing data into Drupal.
It sounds like you're just storing information and the subjects (people) won't be users of the Drupal site.
Leveraging the node and CCK modules to make this happen would remove most of the development work. For example, each of your tables (e.g. Person, Zip Code, Language) could be represented by a content type with a number of fields. The foreign keys would be represented by node reference fields. So the Person content type may have one or more node references to nodes of type, Language.
The migrate module seems well used (626th most popular of 4000+ modules used in at least 10 distinct Drupal sites), but it may be easier to whip up your own migration script, but I'm not familiar with either your situation, your familiarity with Drupal's API, or the migrate module.
Node reference fields display as links to the referenced nodes by default, but can be themed to load and display the referenced node instead (e.g. displaying Language information in a Person node). There's a handy screencast that illustrates how to go about theming node reference fields to load and selectively display the referenced nodes' contents.
Coming from an MVC background you may not like how Drupal stores data in the DB.
Profile module was mentioned, but I find I get more flexibility with Content Profile and CCK combined.
I've written some migration scripts before from Coldfusion to Drupal, and it's not too involved.
Is tagging is the best user friendly way to categorize a subject? An example would be the tags mechanism used in this Q/A site. (StackOverflow.com). How you would Implement categories in a best user friendly way? Or hierarchical categories are the best user friendly way to present available categories?
Is there any online store use tag to categorize product categories?
What you want depends on the nature of the media being categorized.
If you're working primarily with media that is difficult to index, like images, audio, or video, then you want a loose tagging system that encourages putting as many tags as possible with each item. The more tags the merrier, because you will need to use the tags to help index the content for searching.
For something that is more easily indexed (text!), you want a much more rigid system where it may take an extra step or two to create new categories or even force users choose from pre-defined categories. You no longer need to rely on user-supplied tags for search indexing, because you can index the content directly. You are strictly doing categorization, and for categorization to have meaning you need to be sure that users are sorting things into the same categories.
Whether or not a hierarchy or tree structure is appropriate depends on how well your categories fit into a tree structure. Some things fit better than others, and many things that appear to fit a tree structure (like programming topics) turn out not to be such a good fit after all.
I say yes!
Tagging provides a many to many relationship between questions and categories. It makes them loosely coupled and so gives control as well as flexibility for categorizing things.
Tagging has the advantage that a single post can belong to more than one category. This is not possible with (conventional) hierarchical structures. Tagging is a more powerful system than hierarchical categorizing - and so it allows the users to express more.
A hierarchical structure works better if you have a single editor who will spend the time to neatly categorize everything so that a menu structure can be created.
I think tagging works well when things can/need not be strictly categorized or require a hierarchy. It's kind of a non-relational way of relating things.
If works, tags should be controlled or filtered (e.g. crystalreports vs crystal-reports).
Retiring duplicate tags & migrating subject to a proper category will require human intervention.
I don't know of any store that use tagging. Static attributes can be categorized (Electronics -> Camera -> SLR). There could be other attributes, which are dynamic (price range between x and y) & those are not tagged.
Amazon has tags as well. I think, its search option has one choice where it says "get products tagged with" & gives you a box to put in your idea of what a tag could be (which shows you a dropdown of tags, it finds matching - same as stackoverflow).
Tagging can be very useful in every case. For example, gmail applies tags to all emails. Tags could be predefined (with a fixed meaning), or user generated. Having those predefined tags is important as they work like categories, can be controlled by the store owners, and still don't force you to use a hierarchy. You can emulate a category system with tags by enforcing some specific rules on the type of allowable tags, but you can't go the other way round with hierarchical categories.
So, for example, to find all incoming emails on gmail, we can search by the inbox tag.
tag:inbox
Or to get all unread emails in the inbox, we can search by two tags:
tag:inbox && tag:unread
It's much better than trying to categorize in possibly this fashion, for example:
/Inbox
/Inbox/Unread
/Inbox/Spam
Not that anyone cares about spam (the actual ones), but spam can be unread too. So should we introduce another sub-category called Unread inside Spam, or do some other restructuring within Inbox itself?
/Inbox/Spam/Unread
Another store-specific example could be to find all SLR cameras on Amazon that uses compact flash for storage, and supports RAW, and JPEG formats, we could theoretically use:
tag:camera && tag:SLR && tag:Compact-Flash && tag:RAW-format && tag:JPEG-format
Categorization forces you to choose a hierarchy which might mean you have to pick one between two or more perfectly reasonable choices. For example, is an iPod Touch a music player, or a video player, or maybe a portable computer, or all of it?
its depend on the context, if you want to make structure clear and controllable you should force it by your pre-defined category, but if you want to make it flexible and make easier for your user tag is the best technique to manage subject, furthermore it makes search engine easier to analyse and provides better results
so my answer if you asking for user friendliness it would be tags.