Forums / Suggestions / Large sites administration

Large sites administration

Author Message

Rami Grossman

Sunday 24 October 2004 1:24:46 am

Our organization uses eZ publish for developing our new website. We have thousands of articles to publish and we find it very unconvinient to administrate all this content. We need a fiew basic things which eZ admin lacks:
What about moving tree content with all its subtree nodes to another location?
Also adding location to a fiew nodes (selecting nodes like when I want to delete a fiew nodes I select the nodes and push the delete button). I have a site with thousands of objects and my content editor wants to kill me when I tell him to move nodes from place to place or any other mass manipulation.

What does eZ crew have to say about it? Is there any solution planned?

thanks
Rami

Balazs Halasy

Sunday 24 October 2004 1:36:47 am

Good morning Rami,

We have just implemented the move functionality that you describe in your request. Actually, it has always been available, but you had to use it from within the location bar (top area) in edit mode. The way it works now (in version 3.5) is that you go to a node and just press the "Move" button. eZ publish will then ask you about where you want to move the node (and all its children); and voila, the stuff will be moved, just like moving files/folders on a filesystem. In the administration interface of 3.5, this functionality will be available from 3 logical places:

- As a main button when viewing a node (you'll have Edit, Move and Remove)
- As an action icon within the detailed child list of a node
- As a menu item when clicking on the icon of a node

I suggest you check out the new interface and test the functionality:

http://admindevel.ezpublish.no

Login with admin/publish.

Sincerely Yours

Balazs

Rami Grossman

Monday 25 October 2004 1:21:44 am

Thats great!

I played a bit with the new admin site. But I found no option to add location not only to one node but to all its subtree.

Also do you think about changing the section to be not per object and its main node but to be per location. meaning that each object will have a section per each location on the content tree. This is more logical becouse the section is for defining areas. Today when I want to do design per section, when I change all the subtree section to something I'm not sure that all the nodes under the specified subtree will have the same section.

please take a look here:
http://ez.no/community/forum/general/dead_end_section_basic_problem

Frederik Holljen

Monday 25 October 2004 3:07:59 am

>I played a bit with the new admin site. But I found no option
>to add location not only to one node but to all its subtree.
This is what it does by default. If you move a node to another location all children will be moved in the same operation.

About the section per node (not per object): This is an idea that we have been thinking about ourselves for some time. We'll consider it for eZ publish when we move to PHP 5. Before that we can't change it since it breaks backwords compatibility.

Rami Grossman

Monday 25 October 2004 3:32:37 am

Thank you for the quick reply

I haven't got any comment about the adding additional location to all the subtree not only per node I'm on. This is very usefull. I would like to show a folder with its enteries in a fiew places of my site.

Marco Zinn

Tuesday 26 October 2004 1:21:38 pm

Hi Rami,
showing a folder, including it's children (the folder's complete subtree) in 2 or more different places is not supported by ezPublish... at least not in 3.3, and i'm almost sure, not on 3.4.
MOVING a complete subtree is easy, as the others said.

The "sections are used to structure the site" discussion is quite old (nontheless, it still appears, as the term "section" seems to be obviously for this).
ezPublish uses "section" for permission stuff in the first place, and then, sometimes, for design things.
We think of a "section" like this: A section defines, who can read that content (object). IF a person can read that specific CONTENT, it's not important, WHERE the content is published.

I'm sure, the guys from ez will add something, if i am wrong with these comments ;)

Marco
http://www.hyperroad-design.com

Rami Grossman

Wednesday 27 October 2004 12:14:39 am

For permisions there is an option to use the subtree also, not only section. But for design I can't use subtree condition when I want to override tpl file. So how can I tell the cms to use a specific tpl file per subtree and all its subnodes? If I had an option to make sections per node and not only objects it would have solved the problem. Or if ez would have added an override option by subtree it would be ok also. When I have the same object in different places I have no ability to override to the same tpl file. I can use tricks but its not serious. I have many difficulties with it. We are ready to pay for this kind of extention.

Our organization will use eZ publish as an enterprise system with one DB for all our sites. We will have one repository with all the content (all the articles) and each site will be showing some of the content, and there will be situations were the same objects will be shown in deiferent places with different design. It is very common.

Marco Zinn

Saturday 30 October 2004 10:28:20 am

Hi Rami,
depending on your setup (who's doing the GUI design work?), you may get going with a "switched" pagelayout.
We use this to show or hide parts of the pagelayout (like news lists) or switch key visual images, depending on subtree, node id and/or path depth.
While this works, it may not be good a solution, if you really want to switch ALL of the pagelayout code.

If you are willing to pay for it, contact ezSystem for a support contract.

Marco
http://www.hyperroad-design.com

Bruce Morrison

Sunday 31 October 2004 11:33:45 pm

Hi Rami,

> For permisions there is an option to use the subtree also, not only section. But for design
> I can't use subtree condition when I want to override tpl file. So how can I tell the cms
> to use a specific tpl file per subtree and all its subnodes?

I do believe this is possible by using Match[url_alias]

See http://ez.no/ez_publish/documentation/customization/custom_design/override_templates

Cheers
Bruce

My Blog: http://www.stuffandcontent.com/
Follow me on twitter: http://twitter.com/brucemorrison
Consolidated eZ Publish Feed : http://friendfeed.com/rooms/ez-publish

Rami Grossman

Wednesday 17 November 2004 11:16:52 pm

We started adding lots of material and there is something very uncomfotarble - when adding location to some object we have to add location to all its children manualy to the same new location. If there was an option to add location automaticly to all the children as well. it sould ask me if i want to add location to for children as well or just for the edited object.

please put it in 3.5 version it is very nesecery to large sites. We have site with thousands of objects.

Balazs Halasy

Thursday 18 November 2004 12:16:40 am

Sorry to say, but this is the way eZ publish works. Creating new locations is not like creating symlinks or "shortcuts" within a filesystem. What you are asking for will not be implemented in 3.5 because we have already passed the feature-freeze point and because it is a bit complicated. I suggest you add this request as a suggestion.

Allman

Paul Borgermans

Thursday 18 November 2004 12:43:55 am

Rami, Balasz,

This has been discussed before and in some situations this can be a showstopper for using ez publish. The locations concept should be discussed in depth for 3.6 in terms of required features to make it really useful. It is more or less OK for user groups/permissions now (but try to add 30 users to a new group ...), for all other content you quickly hit a wall.

I hit that wall a long time ago and do not use it for regular content except for a few very isolated cases.

You have to work around such requirements, possibly by using object relations and complicated (resource consuming) templates with lots of fetches. That's how I do it here.

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Rami Grossman

Thursday 18 November 2004 2:48:45 am

But Allman,
If I choose to move object to a new location it asks me if I would like to move the chlidren as well, doesn't it?
So this is the same as moving, instead of switching the children location from the old to a new one just add an aditional location to all the children.

And thanks paul for understanding me. We have several websites with thousands of objects. We decided to use eZ publish as an ERP solution. I hope we are not mistaken becouse we put a lot of resources on this project... eZ has lots of good feateres but sometimes I don't understand their logic. Its like not looking at the whole picture, like in the section matter I disscused in the begining of this forum thread- eZ said that it is ment especially for permissions. I also would have sugested that objectrelation will have a brother - noderelation. We have with it the same problem as we had with the section. It is a pointer only to the main node of the object. What if I need to view one of its secondery nodes. Design is dependent on the tree structere.

Frederik Holljen

Thursday 18 November 2004 2:59:40 am

If I choose to move object to a new location it asks me if I would like to move the chlidren as well, doesn't it?

It does not.

We will look into solutions for these problems at some point. Some of these problems can not be easily solved while retaining compatibility with prior eZ publish versions.
I do welcome a discussion about these topics. Exactly what features are we looking for?

Paul Borgermans

Thursday 18 November 2004 4:18:38 am

Frederik, Rami,

- About moving nodes: eZ publish does not ask for "moving the children" along with the parent, but it implicitely happens by design.

- Breaking compatibility: to be avoided of course, but it does not necessarily have to happen

Features wanted:

- assign multiple objects to the same node (mainly useful for user management) in one step, avoiding editing each object seperately
- inheritance of additional parent nodes: couldn't this be made with an option box and a ini variable? At least that would mean "behaviour compatibility"
- inheritance of sections and related permissions. For example if you have several site accesses, say intranet and public operating on the same database and having several sections in common but also some sections dedicated to each. If you want to publish someting in both places, you need to assure that the main node is in the public section (with the least permissions). in order to have the wanted access rules.

That's a start :-)

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Mark Marsiglio

Friday 26 November 2004 7:21:58 pm

Rami,

We resolved the "adding children to additional locations" issue that you mention by editing the fetch in our templates. The end result is that in our tree menu, all of the children of an item are shown in all locations. We do this with this fetch:

This is from the old style of treemenu, before the treemenu operator. So, this is one of the seven nested calls for this function which resulted in the treemenu.


{section show=$node_obj.path_array|contains($:item.node_id) loop=fetch(content,list,hash(parent_node_id,$:item.main_node_id,class_filter_type,exclude,class_filter_array,array(16,21),sort_by,array(priority,true())))} 
<div class="NavLevel2">
{section show=eq($:item.main_node_id,$used_node)} 
<div class="NavSelect"> 
{/section} 
{switch match=$:item.data_map.link.content}
	{case match=1}<a href="{$:item.data_map.url.content}">{$:item.name}</a>{/case}
	{case}<a href={$:item.url_alias|ezurl}>{$:item.name}</a>{/case}
{/switch}
{section show=eq($:item.main_node_id,$used_node)} 
</div> 
{/section}
</div>

The important part is that the children of the main node of the object are displayed. We did this just by replacing node_id with main_node_id.

We made this a while ago, so forgive any strangeness in the code.

http://www.thinkcreative.com
Turning Ideas Into Strategic Solutions

Rami Grossman

Monday 06 December 2004 1:36:52 am

Will you make the lifes of the large sites administrators easier on the 3.6 version according to the sugestions discussed here?
I remind:
1. adding location to the all subtree.
2. possibility to work with sections per node and not per object or instead making it possible to override by subtree and not only by url_alias (becouse url_alias has a fiew problems in some cases).
3. noderelation datatype (similier to the objectrelation node) - for object in different locations which each location has its own design.

Paul also had an interesting list of requests:

- assign multiple objects to the same node (mainly useful for user management) in one step, avoiding editing each object seperately
- inheritance of additional parent nodes: couldn't this be made with an option box and a ini variable? At least that would mean "behaviour compatibility"
- inheritance of sections and related permissions. For example if you have several site accesses, say intranet and public operating on the same database and having several sections in common but also some sections dedicated to each. If you want to publish someting in both places, you need to assure that the main node is in the public section (with the least permissions). in order to have the wanted access rules.

Thanks!

Rami Grossman

Saturday 08 January 2005 11:28:12 pm

Are there any plans implementing any of these features on the 3.6 version?

Badger Mushroom

Friday 21 January 2005 9:32:41 am

Hi Mark,

I was just wondering...

Say, I've added an object to folder A, and also added a location to folder B. When viewing folder B, I would like the URL to point to the same object URL as in folder A.

In my other thread, I've said "Related Objects" maybe the key to this... but all it does is to add a link whereas I want the flexibility of adding locations without duplicating the URL.

Thanks much for any help!