Hey all,
this solution doesn't work complete for me. If I give the user access to
/siteOne in Website ACL it works, but if I set the access to
/siteone/anypage it doesn't. In this case the user doesn't see an entry in
the website section. But I need to grant that access to /siteone/anypage.

Any ideas?


Magnolia - User mailing list wrote:
> 
> Here's how we do it:
> 
> 1. Log in as root user
> 
> 2. Create the root folders for the site
>       - 1x in the website repository
>       - 1x in /config/modules/templating/templates
>       - We also root folders for the site here (optional):
>               - 1x in /config/modules/templating/paragraphs
>               - 1x in /config/modules/templating/dialogs
> 
> 3. Create a new role with the following permissions
>       - Website
>               - Read only | Selected and sub pages | /$
>               - Read only | Selected and sub pages | /tmp/fckeditor
>               - Read only | Selected and sub pages | /docroot
>               - Read/Write | Selected and sub pages | /path/to/root/folder
>       - Users
>               - nothing
>       - Config
>               - Read only | Selected and sub nodes | /modules/adminInterface/ 
> config/menu/website
>               - Read only | Selected and sub nodes | /modules/templating/ 
> templates/[siterootfolder]
>               - Deny access | Sub nodes | /modules/adminInterface/config/menu
>       - Roles
>               - nothing
>       - Store
>               - Read only | Selected and sub nodes | /
>       - Expressions
>               - Read only | Selected and sub nodes | /
>       - Documents
>               - nothing
>       - Groups
>               - nothing
> 
> 4. Create new user and of course assign it the new role you've just  
> created
>       
> 5. Publish role and user
> 
> 6. Log in as the new user and test the settings
>       - You should only see the menu item "Website" as well as the root  
> page of this user
> 
> Good luck!
> 
> -Will
> 
> P.S.: There's one reason not to have to many sites and therefore  
> editors in one Magnolia: Each time an editor activates content, the  
> _whole_ cache gets cleared. Of course you could only allow activation  
> of content with the workflow, then have an editor in chief activate  
> things once a day.
> 
> On 19.04.2007, at 04:30, SoreGums wrote:
> 
>>
>> This is exaclty what I want to do, except finding out the specifics  
>> of how to
>> do it is really hard for me :/
>>
>> Is any one able to point me to either a wiki entry or a mailing  
>> list message
>> (i've searched and come across all the questions related, but the  
>> answers
>> are thin on the ground)
>>
>> I'm sure if I spent a few weeks/months I could work how Magnolia
>> works/functions and then from that fit what I want to do into the  
>> magnolia
>> platform. But like most people I don't have this sort of time...  
>> Magnolia is
>> a pretty sweet platform from what I've been able to learn in the  
>> last two
>> weeks, but figuring it all out to do what I want to do is  
>> mystifying ;)
>>
>> I have so many questions and the answers are not exactly apparent.  
>> If I had
>> a spare 15grand (AU$) I'd be on the blower to the developers :)
>>
>> Thanks for all pointers.
>>
>> Nick
>>
>>
>> Magnolia - User mailing list wrote:
>>>
>>> Hi Everyone,
>>> finally our customer is ready and we want to start implementing their
>>> site on Magnolia. Now our customer has 11 individual sites, all
>>> belonging to the same company. After our brief experience of doing  
>>> one
>>> small project in Magnolia we would try to do the following:
>>> - Install the magnoliaAuthor/magnoliaPublic duo
>>> - create a root folder for each website of our customer
>>> - create the en/de/fr folders in each website folder
>>> - create the websites in these folders accordingly ( so it would be
>>> example1/en/* )
>>> - create virutal hosts for these subfolders, so that www.example1.com
>>> shows that part of the tree
>>> Now so far we think this would work best, editors can be given access
>>> only to specific websites and subtrees, we only need one instance of
>>> Magnolia (instead of 11). The only slight disadcantage would be,  
>>> that we
>>> cannot (or can we?) assign templates to only a part of the tree,  
>>> so an
>>> editor could accidentally assign the template of a different  
>>> website to
>>> the page under his tree.
>>> We have managed to set up virtual hosts in Tomcat to map the  
>>> domain to
>>> the magnolia instance, but have no experience setting up multiple
>>> virtual hosts to point into seperate subfolders of the SAME Magnolia.
>>> Has anyone tried something like this? Would anyone caution us against
>>> going this way?
>>> Many thanks,
>>> Martin
>>>
>>
>> -- 
>> View this message in context: http://www.nabble.com/Any-reason-not- 
>> to-do-multiple-sites-in-one-magnolia--tf678870.html#a10070696
>> Sent from the Magnolia - User mailing list archive at Nabble.com.
>>
>>
>> ----------------------------------------------------------------
>> for list details see
>> http://www.magnolia.info/en/developer.html
>> ----------------------------------------------------------------
> 
> 
> ----------------------------------------------------------------
> for list details see
> http://www.magnolia.info/en/developer.html
> ----------------------------------------------------------------
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Any-reason-not-to-do-multiple-sites-in-one-magnolia--tf678870.html#a11314020
Sent from the Magnolia - User mailing list archive at Nabble.com.


----------------------------------------------------------------
for list details see
http://documentation.magnolia.info/docs/en/editor/stayupdated.html
----------------------------------------------------------------

Reply via email to