wheelmaker24

Wow! That was quick Will try it out tomorrow!

You are right, this is a better name!

While I agree that Dave's statement might be a very specific need, I think that both "One" and "Single Child" options have their purposes. Besides the use-cases mentioned above, you could use it for the following: A "config" page for specific pages (e.g. when having a portal with sub-portals you could add a "config" page as a child to each sub-portal and there configure theme, navigation, ...): Sub Portal 1 Config Page Page 1 Page 2 ... Sub Portal 2 Config Page ... Sub Portal 3 ... When using a folder strategy for the page tree, you could use it for sub-pages like "Attachments", "Comments", ... that may be added once to every page without canibalizing the page hierarchy, e.g. /page1/ /page1/comments/ /page1/attachments/ /page1/subpage1/ /page1/subpage/1/comments/ /page1/subpage2/ When having a registration system with the following page structure, "Events" and "Registrations" pages should have the "Single Child" option enabled: Conference 1 Events Event 1 Event 2 ... Registrations User 1 User 2 ... Conference 2 ... Conference 3 ...

Hi, I got a new idea which come in handy when creating ProcessWire pages with enclosed subsections. Currently within the template family settings there is a setting "Can this template be used for new pages?" with the options "Yes", "No" and "One". My proposal is to add a fourth option that is "Single Child". This would allow the template to be created only once within another page (meaning that there wouldn't be any siblings with the same template). To give you an example look at this page structure for a multi-site webpage: Newsroom root Newsroom for Country 1 News articles Article 1 Article 2 ... Tags Search 404 Newsroom for Country 2 News articles Tags Search 404 Newsroom for Country 3 ... The root template will automatically redirect to the country newsroom page according to the browser's locale settings. Within each country newsroom there should obviously only be one "Tags", "Search" and "404" template. The option mentioned above would enable me to do this. A work-around solution for my specific use-case would be to select the option "No" and automatically create the Country Newsroom's children via a hook that triggers when a new country newsroom page has been created. But I think that this fourth option could come in handy for other use-cases as well. What do you think?

So, bernhard, how did you hide the label and the "Add new" link? Or is this just a mockup?

Hi, I was just playing around with the Repeater fieldtype and wondered if this might be a good fit for something I would call a "FieldCollection". In a FieldCollection the behavior should be exactly the same as in a Repeater fieldtype where minimum and maximum items are set to "1" – just the look and feel in the backend should be slightly different. Think of templates that share two or more fields for the exact same reason – e.g. a "published from" and a "published to" date field and a checkbox. Instead of adding those three fields to every template that needs them, why not create a FieldCollection? Changing the FieldCollection will change the fields on every page it is added to. The only caveat of using a Repeater item set to min and max 1 item is its appearance in the backend: Some of the Repeater features (delete item, add new item, ...) wouldn't be needed for that particular usecase. What do you think? Many greetings! Nik

Sure! And I totally forgot to do so in the first posting: Yes, all instances share the same templates and fields. But it would be great if additional to the "site-core" templates adding instance-specific fields and templates would be possible.

Hi guys, I would very much appreciate to get your feedback to the following idea: We've created a publishing system for our company that is based on ProcessWire. Currently we are only using it for one publishing page. But it could very well be possible that in the future we are in need of managing additional pages. I'm thinking of something like it is described in the article about Multiple-site support, but with something like a site-core that is included by any site instance. To keep server management simple all the instances could use the same database. Imagine the following folder structure: All the templates, modules and assets from the "site-core" folder are automatically loaded by each other "site-" instance. This would enable other instances to add their own templates but still let them use the "site-core" templates. Also the ProcessWire "wire" folder would remain untouched. Additionally it could be great to restrict module configuration access to only activate the "Site" tab on instances. And being able to create new instances from the "site-core" instance ;-) What do you think? Thanks for your feedback Nik

Hi Zeka, seems like the initSelector approach doesn't work...

Hi guys, I've been thinking about the page editing permissions on our - hopefully soon to be released - intranet application that is based on ProcessWire. To explain the structure of our page: We've got an overall news section, country specific news sections, a social media section and of course static publishing pages I've decided to divide the news sections from the pages, as content from those sections is not per se bound to the starting page but could also be displayed from other pages. We are using the following templates: The starting page for example is a page-sections page that is divided in three sections displaying content from a) an overall container-news template, b) a container-postings template and c) country specific container-news templates. Each section has an archive page (page-section) that only shows content from the container chosen in the section. (I will maybe post our approach as a case study, if anyone is interested) But let's come to the permissions: It would be great being able to add editors and publisher to specific pages. The user should then inherit the template's permissions, but still be restricted to the page he or she is assigned to. Example 1: I would like to add a user as an editor of the Austrian news section (container-news). With this the user should get the permissions to add children to the Austrian container-news page but also get edit permissions for their children (the allowed children are already defined within the template settings). Example 2: I would like to add a user as an editor of the Services page (page-default). He or she should then get the permission to edit the Service page and all of its children. I was thinking it would be a good idea to add an editors and a publishers page field to each template that is linked to the user pages. But I'm not sure how to proceed from here. Ideally those to fields would appear within the "Settings" tab of each page. If possible each "Settings" tab should also list the users that inherit access from parent pages. A page field with all the editable pages within a user template would be great (like in Ryan's "Page Edit Per User" module) -- although the primary use case will be the other way around (chosing users from pages, not pages for users). Where should I start? Are there any hooks I can use that manage editing access? What do I need to consider from a security point of view? Thanks! Nik

I see! I'll keep it with Jan's solution then ;-) Thanks, everybody!

Hi nikosch, I've tried escaping with backslashes, but this does not seem to work: To add a link insert \[Title\]\(http://www.your.url\) to your text. Jan's solution is working, although as he said copying the phrase is not possible for authors then.

Hi, just a quick question: I want to add the following text to the note field of a template field: Unfortunately this is parsed automatically and it shows something like this: I tried escaping the Markdown code with backslashes, but this didn't lead to the expected result. Any ideas? Thanks! Nik

I meant the Core module "ProcessPageList", the one showing the page tree on all pages. The link in my initial topic explains how to create quick links within the admin navigation to show specified sub-pages of the page tree. I was looking for something like this that shows the full page tree but only pages with specific templates.

Hi guys, I'm trying to add some useful admin links to my page like preconfigured ListerPro pages, ProcessPageAdd links and so on. Is it possible to modify the ProcessPageList to only show pages with a specific template? I've already found a tutorial to modify the PageList to only show items of a specific parent (see here). The easiest way is probably to duplicate the module and modify it, right? Thanks! Nik

Yes, I've already found that function (see first screenshot attached). What I was looking for was a way to sort the pages on the second screenshot (guessing that the select order on the third screenshot will follow that order as well). Screenshot 1: Pages Add Module Configuration Screenshot 2: /admin/page/new/ Screenshot 3: the actual dialog after clicking on "Add New" -> "News"

Hello, I was just looking for an answer to the same question! In my case I've got four container pages that can have news pages as children (think of the container pages like categories). It would be great if I was able to sort the select field just like it's possible with the Bookmarks. I think, a good place to implement such sorting capabilities would be the Admin -> Pages -> Add New page (admin/page/add/), as this page already lists all the possibilities. What do you think?

This would work fine for us – except that I like the layout of the current fieldtype, especially as it shows all the different folders of the articles (s. screenshot attached).

Hi guys, we are using the PageListSelectMultiple field on many pages to create links to related content. This works really fine for most of the items (I've filtered the Page field to only show items below a specific parent page). Would it be possible to integrate an additional search field to the PageListSelectMultiple field? This would enable the author to quickly find content, even if it is older. I think this feature could be interesting for other users as well. What do you think? Regards, Nik

I think I've found a solution: Following the same approach as above but changing the pages field to be a repeater field with a single-select page field in it ;-) Perfect!

This would be a great solution if it would always be the cards 3, 5 and 7 to be stickies. That's not the case: It might be that there is no sticky card at all. Also I would like to have something that works not only on one page but on many others as well. Into the bargain it should be easily manageable by editors. That's why I came up with something that is manually draggable like the page field…

Hi guys, I'm currently designing the backend fields of a new intranet publishing platform and I think that there's still some improvement possible. Like I know you, you probably have some great ideas for my issue To explain the structure in the frontend: The starting page is divided in three horizontal sections with each section having cards in them (the first section having 8 cards, sections 2 and 3 each having 3 cards). Normally the first section should display the latest news, the second section should display social media postings and the third section should display news from a specific category. My current approach: I've created a "page-sections" template for my starting page, which has three "section" templates as children. For each section I've defined a field "Standard selectors" with content like template=news, sort=-date Now the tricky part: It should be easily possible to define some "sticky" cards in each section. For example in the first section the third card should be an important news, the fifth card likewise and the seventh card should be a promotion card. So what I was trying to do is adding a "page" field to my section template like the following: As you can see I've added 8 pages (resembling the 8 cards for the first section) where pages 3, 5 and 7 are specifically selected items and the others are just an empty page named "Standard-Kachel" (meaning "standard card"). This standard card field should be filled out with the fields from the "standard selectors". With this I would be totally happy! The problem is that the page field does not accept the same page selected multiple times. Is this possible anyway? Another idea was to use the ProField Table instead. But there one would need another approach to add the page field as a column. Maybe you've got another idea? ;-) Thanks a lot!

No, I meant 300+ "static" pages to be published within the website in total – counted without the news pages of course. I am currently rethinking the intranet publishing pages for about 10.000 employees: The current system is based on company's standards (meaning SharePoint Server 2003…) and is of course getting a bit long in the tooth. The problem we are facing with the current system is that it is not very flexible. The life span of the new (ProcessWire) system should be at least as long as the life span of the current system – meaning it should be prepared for techniques coming in the next 10 years. Regarding the different pages published by over 50 editors, many of course want to achieve their "own" design. What I'm thinking of is how to balance options of making pages unique by their editors but still consistent within the whole system. It is true what you say, that the system's editing options should not be based on the layout but on the content. But still: I don't want to restrict a system too much that should be flexible enough for the next 10 years ;-) For example we've already created optional fields (restricted to a specific user role) to add additional head tags (like CSS links) or scripts just before the closing body tag. Using hanna code one is also able to implement jQuery plugins in the future without touching the template files (which in a production environment is not too easy anyway).

Thanks for your responses, I totally agree with both of you! I think the best solution is to define content elements (like tables, figures, attachments) that can be added to any page within a page field. The problem we are facing is that we have to develop a structure that is working for 300+ sub pages. Of course we will develop according to a style guide which helps a lot in terms of how to display elements. But I wonder if it is possible by structural design to let publishers customize their pages without loosing consistency.

Hi there, I started this topic to collect ideas about different publishing concepts in ProcessWire web pages that are used as big publishing systems. Please think of this topic as a collection of ideas and tools. So feel free to post your concepts as well. When it comes to bigger publishing systems it is of course important to strike the balance between consistent page layouts and flexibility. Also it should be easy to handle for publishers (the frontend editing features could come in handy here). Structures: From my point of view there are different approaches. I think there is nothing like a "perfect solution", because decisions should be made from case to case. 1) Create one template per layout This is of course the easiest way: A possible default page template would have fields for headers, main content, sidebar content and footers. For every other scenario you simply create a new page template. In the worst case you end up with thousands of different page layouts. 2) Use CKEdit or any other editor to handle layouts Here your page content would basically consist of one field (e.g. body) and you let CKEdit handle everything else. As CKEdit is plugin based you could use something like the Bootstrap plugin to achieve different layouts on different pages. Although I have to admit that I'm not very comfortable with having a WYSIWYG editor handle the page layout. 3) Use page fields for content elements (PageTable or PageTableExtended) For me this seems to be a good balance between flexibility and "controllable" layouts from a developer's perspective. Just create sub-templates for content blocks (e.g. content-table, content-gallery, content-infobox, ...) and make them available as child templates for every publishing page. Having a page field on the publishing template you can then add, edit and sort content parts. Another way is to integrate content-templates via HannaCode (e.g. [[table]], [[gallery]], [[infobox]]...) and use it inside a CKEdit (this would pretty much be the WordPress approach). The only thing not seeming "clean" to me is that is could be possible that content elements are page siblings to publishing pages (if you are not using one place for every content item to be saved in, which then could make permission management difficult). 4) Using GridManager I've just come across this plugin which one can use as an InputType in the PW backend: Grid manager. This looks good for me but on the other hand could still be confusing for publishers that are only occasionally updating their content. tbc...