eZ Community » Forums » eZ Publish 5 Platform » is 'choose section' lost in ezpublish...

is 'choose section' lost in ezpublish 5?!!

is 'choose section' lost in ezpublish 5?!!

Tuesday 26 November 2013 11:41:00 am - 10 replies


this seems very stupid, but i dont find where to define section in ezpublish 5!!

i can change the section, when an object is published in node's details, but just before being published i cannot!

Am i dreaming!!!!???

Tuesday 26 November 2013 1:23:22 pm

Not really, since eZ Publish 5.0 you can only change the section after publishing the content and not while your editing

Tuesday 26 November 2013 3:17:34 pm

Is It logic??!! 

I have a public folder , editors publish their articles on private or standard section.

I think asking them to change the section of the article, after being published is not really logic!

Up until now i had not any problem with 4.6 but now the problem is that, 

my vip users receive private news with mail but the normal users should not receive them... but now they will receive mails both of them... 

can i add this part to my page template manually?

Tuesday 26 November 2013 3:29:23 pm

In this specific case, I'd advise to add a new folder inside of that public one belonging to restricted section.

Every article published inside that folder will be hidden


Modified on Tuesday 26 November 2013 3:37:45 pm by Pedro Resende

Tuesday 26 November 2013 3:48:57 pm

If you consider this a bug, I'd advise you to open a new issue in http://jira.ez.no

Thursday 28 November 2013 1:43:57 pm

I understand that the removal of this feature can be annoying.

To be frank, in most use-cases that we have seen, what Pedro explained was in use: restricted content was always placed in one (or several) containers that were assigned the limited sections, and just inherited from the container's section. No need to manually set anything.

Thursday 28 November 2013 2:49:53 pm

Background for why it was removed:
- It sets the section on the object not the version (there is no section on the version), and it also applies it on the sub tree.


Alternative would be to re introduce it for first version before publish, similar to the location thing optionally available in the bottom during first draft editing.

Friday 29 November 2013 11:35:53 am

I kinda agree with the idea, André. It does make sense when creating a content, while it really doesn't when editing it.


What do you think, "pa" ?

Monday 02 December 2013 10:46:47 am

In my case, as I explained you or to be more precise, I have a folder in which I publish the latest news.

Some news is only related to the VIP users. Some related to management group and some to all users.

In this folder i have some sub-folders about the different projects.








The object is to have a folder which can contains all type of news about projects in different sections for all these groups.

When an article is published it sends an email to the related groups. 

Management group should not receive VIP groups and vice versa. And the rest of users should not receive VIP or management mail.

There are some different kinds of editors here:

One who publish VIP news, one for Management and other users.

Before this architecture was just fine.

Now editors should publish their article in users section and then change it to VIP or Management groups and of-course they should pray to not posting it when the cronjobs are executed!!

or either they should copy all the projects but its annoying since it changes the last architecture.. 

Thursday 14 August 2014 4:25:37 pm

Playing around with content staging variations, and the fact that using "object copy" action to create a new object at version X > 1 , I came to the conclusion that the eZ API should in the end have separate "create object" and "add new version" actions. Some things indeed do make sense on creation of the object but not on update (creation of a new version)

Thursday 14 August 2014 5:28:15 pm

API is not really the topic here, furthermore eZ Platform API already has this distinction:


The admin interface issue being discussed here got a pull request earlier today and is tracked in this issue:


Testers wanted happy.gif Emoticon

Modified on Thursday 14 August 2014 5:30:34 pm by André R


You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from