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.
Related
I'm working on a WordPress ecommerce site. They want to have some industry-specific words (like "ADA Compliant, ANSI/BHMI") have tooltips with definitions.
I've added tooltips via tooltipster and created a shortcode for manually adding tooltips, but as these words are repeated many times throughout the site, I really want to give them a single interface where they can define a single instance of word + tooltip, that affects everwhere those words are written in the content.
The only thing I can think of is a gettext filter, but it seems like that would be terrible for performance, since they will have a lot of words.
I'd love some ideas of how I could achieve this. I don't know what direction to go in. (Translation won't work since it's in the content, not theme or plugin strings.)
I am not very good at putting on my "black hat" and figuring out what a nefarious user might be able to do with a certain type of open door. I'm working on an app that is planned to have such a door and would like some help figuring out how to protect it.
Imagine a site that is a distant cousin to WordPress. It is a content creation and hosting site for specific vertical markets with features to make it more appealing to those markets (compared to the many existing more general alternatives).
On such a site you want to enable the users to cook up their own look and feel for their content. I'm planning a sort of 3 tiered approach to that. 1) provide some selectable "templates" to choose between, 2) provide specific points of additional adjustability (vis. select background color, font-family, etc.) and 3) as a backup for the truly format obsessed customers, the ability to supply a CSS file for use on their pages.
It is about the security hole(s) that might be created by this last item that I wish some help. First and foremost, what sorts of nefarious things can a black hat accomplish from unfettered access to such a door? Is there anything they could do there that would adversely affect any pages that don't specifically include that CSS? Is there anything they could do through malicious CSS to gain some sort of system access? Is there any standard way of filtering user-supplied CSS to prevent (most of) these exploits?
thanks much!
Unless you're doing some sort of preprocessing (LESS, SASS, etc), there should be no risk to your server. The risk is that your users could modify the page in ways you weren't expecting.
Will your site contain any content that users aren't allowed to modify? Maybe a unified toolbar at the top where any user can sign in to their dashboard? A user could modify the CSS on their page to create a phishing attack for other users of the system.
Are you going to put ads on the page? A user could modify the CSS to direct any ad clicks to their own destination.
If any of the content on the page is outside of your users' control, you probably shouldn't let them upload custom css.
If the entire page can be controlled by the user (like in a custom site hosting environment), then custom css should be fine.
Do not allow them to upload anything of the sort, give them a user interface to modify their look and feel. This way you are limiting the damage they can do.
What is the best approach to have a different CSS dependent if the person is disabled?
For example larger text, different colours etc.?
Check out the Canadian National Institute for the Blind site: http://www.cnib.ca/en/
They have implemented some good features, such as
changing contrast
changing text size
skip to content
tables for tabular data only
For the most part, this is just switching out stylesheets as needed.
If you do this, you should probably use cookies to maintain preferences across the site.
Importantly, you should place the links for these options are the top of the page, where they will be easily accessible, both to view and through the tab structure.
There's a jQuery styleswitcher with cookies to keep the users' preferences here: http://www.cssnewbie.com/simple-jquery-stylesheet-switcher/ and a method for implementing one in an accessible way here: http://www.alistapart.com/d/bodyswitchers/iotbs.html
However, you should be making sure that your standard site colours, font size, etc are meeting a basic level of accessibility to begin with. WCAG2 Level A at a minimum, and high-contrast/text-size etc as an optional extra. If users are having trouble perceiving your site to begin with, finding and using the styleswitcher is just another difficult task for them before they can get to your content.
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.
Is there any way to show local tasks to user if they doesn't have necessary permissions? Right now it seems like Drupal just excludes them from page code. I want to show them, but with different CSS class.
Version of Drupal is 5.20
Even though there are some differences concerning the local task building between Drupal 5 and 6, Mac is right that the logic to ignore entries not accessible by the current user is pretty deeply embedded in the menu.inc functions. If you want to look for yourself, start with theme_menu_local_tasks() and follow the function calls from there.
If I had to implement the feature you're looking for, I'd rather avoid Macs suggestion of messing around with the menu access settings directly. Instead, I'd override theme_menu_local_tasks() with a custom version and duplicate the entry retrieval logic in there. The first run would fetch the primary and secondary links as before, and the second would do the same while impersonating another user (probably user 1 in this case). That way, I'd get two versions of the local task markup which I'd then needed to diff somehow in order to find the ones not allowed for the current user, thus needing the extra CSS class.
Note that this would still be somewhat ugly to do, as menu_primary_local_tasks() and menu_secondary_local_tasks() return already themed lists, so the comparison would need to work on the markup, probably parsing out the li tags somehow. So it might be worth spending some time trying to do the same thing (fetching the local tasks as two different users), but using lower level functions to get the entries before theming.
Note: Should you end up using the user impersonation logic, make sure to use the safe, second version that disables session saving during impersonation.
I know the D6 version of hook_menu much better than D5's. AFAIK - however - you can't override that behaviour as it is hardcoded in menu.inc.
If I am right with what above, a workaround (rather inelegant, I must admit) could be:
Remove the access control from the menu item, so that all menu items are visible to all user.
Put access control in the callback directly (you will make the tab non-clickable in a moment, but if the user insert the URL directly, this will prevent access to pages they must not see).
In the page displaying the tabs, load a different js file according to what roles the user has. The js file for users with limited access will select tabs by mean of their text content (at least in D6 tabs do not get any "individual" class: they only get a common "tab" one), it will remove the link to the tabs the user has no permission to visit and it will add a custom class to those tabs that should be displayed differently.
Add CSS theming for your custom class.
As stated before, I do not know D5 much, so it might also turn out that you can actually achieve what you want in a much cleaner way!