Jump to content

wheelmaker24

Members
  • Posts

    48
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2,289 profile views

wheelmaker24's Achievements

Jr. Member

Jr. Member (3/6)

6

Reputation

  1. 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 ...
  2. 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?
  3. So, bernhard, how did you hide the label and the "Add new" link? Or is this just a mockup?
  4. 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
  5. 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.
  6. 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
  7. Hi Zeka, seems like the initSelector approach doesn't work...
  8. 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
  9. I see! I'll keep it with Jan's solution then ;-) Thanks, everybody!
  10. 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.
  11. 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
  12. 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.
  13. 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
×
×
  • Create New...