I am developing a multi-country and multi-lingual website using Drupal. I am relatively new to Drupal (this is my first project on it).
My client will have multiple country sites (www.example.com/uk/, www.example.com/bg/, www.example.com/fr). What i need is to be able to tag content to a particular country in Drupal and to also have that content then appear on the relevant site. A use case is below:
The user creates a page called about and tags it to the country Bulgaria (bg). They then navigate to www.example.com/bg/about, to view the page.
I am also using the Multilingual - Internationalization module (Link to module). So on top of the above the user will also tag content to a particular language. A use case is below:
The user creates a page called about and tags it to the country Bulgaria (bg), they also select the language as being English. They then navigate to www.example.com/bg/uk/about, to view this page.
I have tried many modules etc but to no avail so far. Some things to bare in mind below:
This is based on a Drupal 7 install on a local server
There is no scope to change the URL structure
www.example.com will be their primary groups website which will link through to the international versions
Any guidance or solutions is much appreciated.
I think it may make sense to try using the Organic Groups module to create the 'multi-site' aspect of this. It'll give you more separated sites than tagging alone.
You can make all your groups (countries) be global (in the organic groups default scenario, groups can either be globally visible or visible only to their members). Then when one of your editors is creating a page, they'd have to select which group that page should belong to, rather than use a tag to segregate country-specific content.
Groups are a good solution, I think, because then, each group (country) can have its own independent menus, using the og_menu module, so you can really set them up to look like their own independent little sites.
Once that's set up (and it will take you a while, because there's a steep learning curve with using Organic Groups), you can do the translations independently of which group a page exists in. I'm assuming the translation stuff is working fairly well with the Multilingual - Internationalization module.
If you use the pathauto module, you can set up your url rules to automatically behave the way you want (i.e. with bg for the 'Bulgaria' group, etc). I actually don't have that setup for my site using Organic Groups, but there are various discussions on how to do that, and I'm just citing one of them here: https://drupal.stackexchange.com/questions/36892/organic-groups-group-content-types-and-pathauto
I hope this helps a little....
Related
Here's a puzzler: I'm doing a site for a client that starts with a landing page that links to his four law offices, each with a color coded header and office info. They all have content specific to their offices, no problem. But they also have some content that's universal, like a blog. How do I put the blog in for all the offices but preserve the office info on those pages? No, I do not want to use frames, but yes, that's the idea I'm talking about.
Couple different ways you could approach this, generally depending on how much information you need to share across the offices, whether you have requirements on how these different offices are administered, and generally how similar the content is.
The first decision to make is whether to use Single Site setup (in which they technically operate as one WP site), or a Multi-Site setup (in which you could use one common theme, but the posts/pages are administered independently - you could still use a plugin like http://wordpress.org/plugins/network-latest-posts/ to share blog posts, but you'd want to make sure it meets your needs beforehand). More on this decision here: http://mashable.com/2012/07/26/beginner-guide-wordpress-multisite/, and setup here: http://codex.wordpress.org/Create_A_Network.
If you opted to go single-site, then one simple option may be to create page hierarchies, with the parent-level pages as Office A, Office B, Office C. If it's only a couple things that need to change based on the office (e.g. header colors, simple branding or info), then you could make a function that checks highest parent-level page (using get_post_ancestors - http://codex.wordpress.org/Function_Reference/get_post_ancestors), and use that result to determine which offices' branding you should use.
Best of luck!
So I'm designing a Drupal 6 site for a lefty political party. I want to generate 48 separate "Candidate Pages" from a single configuration of Views+Panels. The panel will include picture, bio, blogroll (views), and some social media widgets.
Each candidate URL is formatted /elect[username] (where each candidate is a user, and each username is their firstlast real time).
My question is: how should I best go about configuring this panel (and views)?
I know there are two main options: 1. pull the URL into Panels and Views 2. Associate the author of the content to the Panels and Views arguments.
What do people think is best, and how might I go about defining the necessary arguments?
That would depend on the content you would like to feature on the page and the most efficient way to query it.
My first guess would be to override the user page in Panels, this will take care of the picture and basic information.
Considering that the user can be used as argument in Views , retrieving a candidate's content type should be pretty straightforward, whether it's a bio or a blogroll.
Bear in mind that when defining your various content types you can add a user reference field, this could come handy for other types of content...
Finally the Content Profile module could be a good addition.
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 just want some opinions on what's the best way to go about meeting the following requirements.
I have
One main Drupal Installation
It is a typical "listings" site where users can list items
One user can have how many ever "listings" that are linked to his account
I want to be able to create sub-accounts, that use the same base site. However, for each subsite:
Only the users listings must appear on his site
It must have a completely different theme.
It must have its own menu items
The site must run off it's own domain OR subdomain
I need some answers:
Is this possible, or will each user need a completely new Drupal installation and just use a web service or something to get its listings from the main site?
What modules / components will make my life easier?
Any other suggestions to make this as simple as possible?
The problem description is not detailed enough to give a fully sound advice (and - additionally - it looks like you could probably get better advice on a drupal specific forum, as the question seems more related to installation and configuration than to programming), however - from what I understand - it looks to me that your solution could give in either of the two directions:
Tweaking a single installation to appear as different sites
Creating multiple sites that shares the same codebase and part of the data
The tweaking solution has the advantage that you have only one DB to mantain, but there is no actual real separation between the subsites. You could implement this by:
SUBSITES: mapping various subdomains on the same IP
CONTENT: using the native permission system to filter which list items to display (for example: each logged user can display only nodes created by himself, or set to be visible to its role, or having as associated taxonomy term its username...)
THEMES : if subsites will be used only by logged-in users, use the same mechanism that you would use for filtering content [each user can natively pick a different theme if you allow them to], if they must appear with a different look also to anonymous users, then use the URI to pick up the appropriate theme (if visitor X reaches the site via user1.example.com the site will have the blue theme, whilst if the URI is user2.example.com the theme will be pink).
The multiple sites solution has the advantage that you have a real separation between subsites (with even a different DB). But you would then have to either sync or transfer "on the fly" data between the main site and the subsites. If you go for this solution, you should probably take a look at the following links:
the services module, which allows to easy set up webservices
this page explaining how to connect drupal to different databases (surely faster than using webservices... reasonable solution if you for example have sites and subsites running on the same server)
I didn't want to stick this in a small comment but I am in agreement with mac on many of his points (upvote!).
The best way would be to create your subdomains and have them be symbolic links in the site folder to the default / main-domain folder.
Given what you have told us, you are much better off creating a module that creates its own node types (or even just CCK) and use a combination of the permission system (CCK offers this as well through content_permission), Views, etc. No need for separate sites, just need users to look at their own content.
The beauty of this approach is you can use Flag to allow user's to friend each other, use Views to allow them to see friend's lists, etc.
Theme's can be set on the account level, so no issues there.
"Have their own men" - does this mean have their own block on the sidebar or header than has customized links or a completely different menu SYSTEM? Will need clarification before I can answer that.
My site is to have a section for normal users, a section for managers, and a section for use only by anonymous visitors. Each section of the site requires changes to Drupal settings for using a different theme, changing the Primary & Secondary links, changes which blocks are used, etc. In other words, the user experience changes significantly from section to section.
I could probably accomplish what I need by using Drupal's multi-sites, a shared database, and using settings.php to override the variables I need to (ie: menu_primary_links_source). However, to make things more manageable from an operational point of view, and to buy flexibility, I'm considering using the PURL API (purl.module) to prefix the URLs for certain site sections, and having my theme and custom modules react according to the current PURL prefix.
Before I get started, I want to ensure I'm not discounting Spaces.module. Spaces uses PURL, Features, and Context (which I'm also currently using for my site). I don't entirely understand how exactly Spaces fits into the picture. Would it help me make different site sections, each with specific configuration & behavior? Or am I better off depending directly on the PURL API?
The Spaces-PURL-Context conundrum. Fun. I've been meaning to write this up long-style to finish wrapping my head around it.
What is Spaces?
Spaces is a module that creates containers of overridden configuration for your site. It's not specifically about features, it's about any number of configuration values that are able to work with Spaces, including whether a Feature is active or not. (Active does not mean the module is disabled, just that a number of Feature-oriented things are whisked away, such as content types and Spaces-aware Views.
When using Spaces, you need to decide what type of "buckets" you want to use. Open Atrium uses OG and User-shaped buckets, what you need is a new sort of bucket based on user role. For the sake of sanity, you might even need to create a separate module just to define user roles as a more concrete thing in Drupal, kind of like how Spaces OG needs to lean on Organic Groups for a number of concepts.
What is Context?
Context is ultimately a page decorating mechanism. You tell it some stuff about the page, it modifies the page accordingly. Context cannot modify the URL, it's the other way around. Features define Contexts to tell the site how to render a given page uniquely for that Feature, there is no direct connection between Context and Spaces or Context and PURL.
What is PURL?
PURL is a method of sticking things in the URL and keeping them there until you are done with them.
How this Glues Together
Spaces with PURL integration are triggered based on one of two things: The URL or something about the content in the page. To explain this, I'll use Spaces OG as an example.
You click a link. The link was prebuilt with a PURL component that Spaces OG is watching for clues. If that piece of the URL makes sense to spaces, the Space is triggered.
All links except those that opt-out of the PURL modification persist the PURL URL element, meaning the Space is happy, and re-triggers with each page load.
Spaces OG knows to check nodes for their group affiliations. If Spaces can crack open a node and find a group, it will trigger that node's Space, using PURL's modified version of drupal_goto() to redirect the whole page for URL consistency. This will trump any existing URL structure.
If there is no URL component, and the node has no group affiliation, no Space is triggered.
Once the Space is triggered, all of that Spaces configuration values are pulled into play. This will mean the Space's preset defaults (you can have multiple default Space configurations for every Space type) overlay Drupal's defaults, which in turn are overridden by any configuration saved specifically for the Space. In the case of Open Atrium, this includes such nice things as group color, blocks on the dashboard, and enabled Features.
If the user goes to visit something provided by a Feature--a Node, a View, etc, any Contexts related to that node, that view, that URL that any module provides might just be triggered, and start doing things with blocks and theming to tailor the page for the Feature's content.
Next Steps
As I mention above, it sounds to me as though your first step is to try looking at Spaces OG, and rewriting it to be centered around the User Role instead of Organic Groups. You shouldn't have to do much with PURL directly besides a little copy and paste from Spaces OG. You might want to post in the Spaces issue queue to float this idea where the maintainers might see it and give pointers.
The way I understand the spaces module is this:
It provides a way for the features module (and your "features" created from this) to integrate with and be available within defined areas of your site. Out of the box this includes: Organic Groups, Taxonomy, and Users. There is an API to define more "spaces" than this.
So for example you could create a "feature" (with the features module) of an image gallery. Using spaces with organic groups, you would be able to have each group have the ability to enable and disable this feature and it would only be available within that "space" (group in this case).
From the organic groups page:
Groups get their own theme, language, taxonomy, and so on. Integrates well and depends upon Views module
So in your situation, you could think of spaces as a way to make organic groups more flexible. As NoParrots said, OpenAtrium (http://openatrium.com/) relies on the features/spaces/context modules heavily, so that might be a good place to review how these modules work together.
EDIT:
I found a great video that might explain things more clearly: http://www.archive.org/details/TheHeartOfOpenAtriumContextPurlAndSpaces_782. Around 16:00 he starts talking about PURL.
From this page (below the video) there is also an explaination of PURL/Context/Spaces which I think is pretty good:
Context is a module for triggering reactive behaviors within a page load.
Controlling block visibility, menu
trails, page classes, and page
template layouts are examples of
things that fall into its
jurisdiction.
PURL is a library for capturing and abstracting request handling that goes
beyond what the Drupal core menu
system provides ($_GET['q']).
Detection of request components, like
subdomain, path prefix, user agent, or
file extension, and sustaining their
presence is its primary role.
Spaces is a generalized configuration override framework. In
theory it allows you to "customize
everything, for anything." In practice
it allows things like custom group
colors and features, per-user
dashboards, and multisite-like usage
of a single Drupal install.
I would suggest using Spaces or Organic Groups. Spaces was used considerably in Open Atrium... a Development Seed out-of-the-box intranet package. Intranets really require the concept of access control and feature visibility depending on which department or role you have so I'm confident that Spaces will be very good for you.
Of course there is the venerable Organic Groups also. Spaces is a "higher" level concept than PURL. Spaces uses the context and PURL modules BTW. My gut instinct is for you to use Spaces or Organic groups.
There are a couple of videos on the net that talk about Spaces. Check them out.