I'm Working in Plone 4.1 and I'm just curious to know the difference between Products.CMFPlone.interfaces.IPloneSiteRoot and Products.CMFCore.interfaces.ISiteRoot. If I want to register a zope-3 style view, to which one should I register it?
Whenever I want to use a site root, I usually end up using the INavigationRoot from plone.app.layout.navigation.interfaces.INavigationRoot instead.
The INavigationRoot is provided by the Plone site object, but it will also be provided by the navigation root of any subsite or the top level folders in a multi-lingual site. Especially in multi lingual sites, users will never navigate or see the actual site root itself, so any functionality attached to it won't be available to them.
The ISiteRoot only makes sense for things like export import handlers or other internal logic, but not for any enduser visible functionality.
An IPloneSiteRoot is a specific kind of ISiteRoot. IPloneSiteRoot is provided by the root of a Plone site, whereas ISiteRoot is provided by any CMF portal. If your product is only intended to work in Plone, then it doesn't really matter which interface you use. If you want it to be usable with other CMF-based applications, then use ISiteRoot.
Frankly, I usually go with ISiteRoot just because it's shorter to type. :)
Related
I'm new to ezplatform and I have been just thrown in a project involving migration from ez legacy to ez platform.
One problem I've just bumped into is about siteaccess and images.
Example: users have custom images defined in a var directory, let's say var/news.
Unfortunately backoffice uses default siteaccess and I don't find a way to modify it without trigger a redirect from /ez#login to /login page.
I noticed that I can't change backoffice siteaccess in demo platform too.
So I was wondering either if there's a way to achieve this purpose or there's documentation that could help to address such subject?
Just to be clear, you have one var directory per site access, that is the issue right? As /ez will use the default one, you have a problem.
I think there is no simple way to manage this use case right now, I think it will be possible to do it with 2.x (ask in Slack)
One complex solution would be to put everything in one var directory and replace in the DB the different paths... :(
(or wait 2.x)
We are hosting multilingual Plone sites. The default Plone behavior is to use the current content language for admin interface labels. We'd like to change this behavior so that admin interface language is always English, regardless of content.
This will make managing multilingual content easier if you have little or no target language skills.
If we can set this so that when you login as admin and are member of certain or have certain role, the behavior kicks in.
Any suggestions how to do this?
You can register your own INegotiateLanguage multi-adapter from Products.PloneLanguageTool to allow for customisation. IIRC (it was a while ago I added that multi-adapter) you can just register it as an adapter on your own plone.browserlayer interface, though I'm not absolutely certain the browser layer gets applied early enough.
The correct way is to override language when i18n translation machinery queries the string for plone or other i18n domain providing admin text strings.
Overriding request.LANGUAGE has side-effects which will make your site unusuable. E.g. folder listings won't work.
Here is a package which does what you want:
https://github.com/miohtama/silvuple
we had the same requirement and solved it by adding a javascript for managers, replacing the the strings. not ideal because of the redundant vocabulary/dictionary, but worked fine for us.
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.
(I've posted this on the drupal forum too btw)
I'm converting the company websites to use Drupal, or at least trying to check that its going to be the best way forward. I have a background in PHP development, and I'm currently using the CakePHP framwork. I've built this site (not my design) and I can see how to replicate most of the functionality using Drupal, most likely using the CCK module.
http://preview.tinyurl.com/yk6u8mt
As you can see from the homepage:
A user chooses a country.
The country is passed using an ajax call to a script that decides which phone is best based on 'in country' network coverage.
A div is shown recommending the visitor the best phone for that country.
I'm wondering how to go about this in Drupal, I'm definitely not after a step by step guide, I just want to know if this kind of thing is possible with Drupal, and what approach to use.
If someone can help that would be superb. Thanks.
Okay, so you've got a path you're defining in hook_menu, which is where your form is being presented - or else you've got it set up as a webform in a node, that could work too.
Either way, in your form you're going to be using AHAH - check out http://api.drupal.org/api/drupal/developer--topics--forms_api_reference.html/6#ahah and http://drupal.org/node/348475 .
Basically, you're going to define another path in hook_menu that's of type MENU_CALLBACK, and which will receive the country as input, and then will return the div that you'll display on the screen.
One core example of AHAH that may be useful to you is where you're entering a password and it lets you know if the password is secure enough - check that out.
Edit: There's also some good examples at http://drupal.org/project/examples.
I would look into using CCK and views. you can set up filters for the views. If filters don't work, you have the ability to include php code. I have also successfully added jquery code in the header of a view through which I was then able to have my view filtered by what is typed in a text box.
Coming from CakePHP using Drupal is a pain in the a** - even more for developers.
It's application structure might be designed to ease extensibility but this only means you have a system to enable your own plugins and themes.
While modules are basically the M+C-part the themes are the V-part of an MVC-application. The problem is that this seperation is not very strict in Drupal - in fact you have to break it sometimes in order to make things work (e.g. you have to include a theme_mymodule_myfunction() into your module as default output which you then can override with your theme using mytheme_mymodule_myfunction() ) And don't even bother looking for classes ( see http://drupal.org/node/547518 ).
Also there is no real link from a module to a theme. On many occations this is a good thing as you can switch modules and themes seperatly without creating a problem. For application builders coming from CakePHP (or any other framework) you often feel a lack of "wholesomeness" - you create parts for a base software and have to live with it's drawbacks.
IMHO I wouldn't recommend this step. Drupal is fine if you have to manage a website and might add a few modules to add neccessary value (image gallery etc.) but I definetly don't recommend it as a base for a customized web-app.
This is related to my previous question regarding serving static html files but that doesn't seem to be a good solution,
I want to make a fully customizable ASP.NET MVC application as a hosted service. See allowing the user to customize the look/feel of their own page but it is still dynamic, meaning the data is hosted in the central database.
I looked at the "theme" or "skin" in ASP.NET but I don't think it is customizable enough. It seems only the developer can add new themes. I want to have something like the theme editor in WordPress so you can just change the look in anyway you want from a web-based interface.
I wonder how the theme files will be stored for the popular blogging platform? Are they stored in database or a file in filesystem? I prefer to store it in database, because if it is in filesystem it will have scalability problem. Each user will be tired to a particular web server and I have to determine how much disk space for each webserver.
I thought of doing something like the old MovableType, to generate static HTML when you add new post. This solution is problematic as well, because the flexibility depends on the complexity of the template engine.
Ideas? Suggestions?
Thanks!
"Fully customizable" is the most elusive of the white whales ;-)
I see your question is old, but none the less;
first I'd recommend defining some very clear,
and cohesive rules governing just what the "bottom-line" is,
or an inheritable template of sorts.
You get a pretty good impression of what might be useful during developing, I'd guess.
Next; just what and how is the customizing supposed to be presented and achieved?
The inherit ASP.NET custom custard, Web Parts, need quite some cajoling to behave in MVC views :
https://stackoverflow.com/questions/1106629/using-webparts-in-an-mvc-application
If you're leaning more towards customizable appearance (theme's n' skin's),
how about having a CSS file for each user, saves like a charm as VARCHAR(MAX), and can easily be inserted
in e.g. your Master Page's head.
The theme editor in WordPress simply allows you to edit Theme PHP files...
You can do it exactly like in wordpress but instead of editing PHP files your theme is composed of a set of aspx\ascx files without code-behinds...