joe_g

Yep.., PageListSelectMultiple makes ordering a non-issue If I would use that to build my structure. What do you think about an edit link on the PageListSelectMultiple? Attaching sketch. Just to see what you think. @apeisa: This is maybe what you ment with fredi in the backend? Didn't get it before, sorry. Yes that would be very close to the SSM!

Actually, about order, PageListSelectMultiple is pretty close - I can reorder my items, maybe that's what you ment? It's the one I'm using. I wonder if it would be practical (and possible) to build my structure entirely with PageListSelectMultiple's... The difference to SSM is the inline editing and possibility to search for items (only important if more than hundreds to select from). The inline editing makes me not having to be aware where the linked item resides in the tree. J

@Macrura, this is exactly what I'm doing, but with the two drawbacks described in my second post: You can only order things manually in it's main location, everywhere else it would have to be sorted by some field (date for example). And the editor has to be aware about the difference between the main location (the PW CMS tree) and the tagging system (similar to secondary parents) I could also ignore the original location and rely solely on tagging - but then there is no easy way to order things.

Thanks! Then I know my options. I wouldn't want to use any other cms than PW, but this is the only thing I'm missing. I attach a sketch of an example of the SSM interface, similar to something I did in a previous project. My hope is to evoke some curiosity and highlight the differences between SSM and repeater field. Its infinitely recursive using the same 'template' / ("section"): Person. To the editor (that using the CMS), this interface looks simple, even if the data structure is quite complicated. In PW this would be hard to do, simply because each person would only be able to have one parent.

Maybe I'm totally misunderstanding the repeater, but I looked into it twice now to really make sure I understood how the repeater field works (sort of hoping I would be wrong). The repeater and subsection manager seems like apples and oranges to me (doing vastly different things). SSM is many-to-many while repeater is one-to-many: An entry in a repeater field can only belong to one parent, if I understand it correctly. For example, I cant use the repeater in the following scenario: I'm editing a page with the template 'book' in PW, and I'd like to add an author, so I make an author repeater to be able to add a bunch of authors. When editing the second book I can't find the *same* author from the first book and add it to the second book, right? Am I getting this right? J

Thanks. Topic is a bit floating perhaps – Repeater field is strictly one-to-many, as far as I understand. You can't for example have add an author to a book, and then add that same author a second time on another book. (If author would be a repeater field) – The other option is page field, which is essentially a pointer to another page. Two powerful options, but I did know about these (unless i missed something). So it doesn't change my plan (so far) to use page fields to point to alternate parents in the directory as a way for my content to exist in several places. It's a good enough solution, but it has two drawbacks: – The editor has to be aware that everything has a primary location, and go there to edit the content – Manual order (drag reorder) can only happen in one place. J

(WARNING: long philosophical post, with no immediate problem solving needed. This is for the ones who might feel like discussing data modelling in PW) Hello! I'm about to start a new project and I ran into a structural problem that I'm not sure exactly how to get about (although I have an idea): I have a project where all data will be tag-based: the same piece of data will show up in different places on the website. In other words it will 'exist' in more than one place. The PW CMS interface is based on a hierarchy, where everything needs to have one (single) main location. I have no desire to expose myself to XSL again, so I'll be solving this project with PW instead of Symphony (getsymphony.com) – my previous CMS of choice. But I'll use it as a comparison: If PW is based on a folder/hierarchy metaphor, Symphony is based on a relational database model metaphor. Symphony has sections (=tables) that can be 'joined'. They can be joined 'visually' (inline editing) with github.com/hananils/subsectionmanager/. It gives almost the same separation between presentation and data as any other old mysql website but mouse-click data modelling. Symphony gives less help on how my url's should be structured than PW. This project wouldn't actually be much easier to solve with Symphony, I would miss the friendly url/template hierarchy. But a match between PW and the subsection manager (allowing true many-to-many) would be so awesome that the gods of data modelling would step down from heaven for high-fives. On a sidenote: To be honest I never quite understood why they (Symphony) decided to create a relational database on top if the relational database - instead of making the best CRUD known to man, but I'm sure they have their reasons. Anyway, back to PW: I could solve this by letting each entry (page) have a main location. Let the path = tag. So that everything is forced to have a main 'tag' (path). Then a second field with secondary locations, pointing to other parents where the item 'reside'. The problem is that there will be two manoeuvres that essentially mean the same thing: Physically moving the page, and 'tagging'. I could turn this into my advantage, though: Having a single main location is good for other reasons. There are formatting options that would only apply to the main location. So this approach is quite OK, and this is most likely what I'll do in the end. I'm just curious if anyone would have any thoughts on this. J

Long time since this was discussed, I basically followed what I perceived was Ryans main point: Try to map things out within the PW hierarchy instead of trying to build around it. It's a lot easier for the editor to follow. For example: put 'data'-pages next to its 'visual' counterpart, instead of stashing it somewhere obscure under /data/ - I followed this in my last big project and it worked well. This would be similar to organize your folder structure the best way possible, as "semantic" as possible (instead of abstract), mapped to your website / client / solution as possible.

thanks! Will try this.

Hello there. I'm currently deleteing 160.000 session files : ) rgds, J

Gone for a week and comes back to an amazing discussion of stuff I need to look into !

Hello, I ran into a broad and general structural issue and I was wondering how you seasoned processwire developers get about this. The page based hierarchy in the admin immediately invites to create a structure that corresponds to the menu/website structure. This is how my projects usually start out. Step 2 is usually to put everything that doesn't belong in the navigation under, say, '/data'. But now I'm facing a more complex structure that can't be mapped very well to the admin. I find myself wanting to structure the admin side hierarchy independent from the actual site structure. I understand the philosophy of the 1:1 mapping, it makes the cms incredibly easy to grasp! But what would be the best practices when this isn't practical? In practice, the admin structure, in most projects, becomes (a bit messy) mix between actual website structure and logical parts. Two main ways to get about this is either to put all 'non structural/non visible' pages under /data, or put them as children to their logical parent, but then the admin hierarchy gets littered with a mix of visual and non visual pages, and you end up with very complicated paths that also are dependent on the website structure. (If site structure changes - all logic parts must be adapted) If I go the route of putting non visual children pages under their visual parent, to make it easier for the editor, it would perhaps be a good idea if actual pages, and non visual pages could have some kind of different styling. If I go the other route to separate pages from dynamic elements (non visual pages). I would want to sort my website under three main categories: 1. menu structure 2. page structure 3. data. Would this be even possible? It would require some advanced url routing. I give these suggestions only to illustrate my point, there might be better ideas out there thanks for listening J

ps. got a bit impressed when I realized I could use dot syntax to display connected fields: title, category.title

Perfect, Thanks!!

Hello, I was wondering if there would be a way to show something else than the title in the backend page tree? Sometimes the title isn't the most descriptive thing for a page. For example a thumbnail for a photography portfolio website would be better, or sometimes I'd like to have som additional fields in there. thanks for any input! J

Nice thanks, works great. I figure this would give a lot less sql queries than iterating over all template A's. I'm using it for Page (hundreds) and tags (a handful), and instead of looping through all hundreds of pages to check what tags are in use, I guess this would one sql select per tag.

Ah yes, I would need to explain a bit better perhaps. It's a general case where I have an association page A includes a bunch of page B's with a multiselect. I'd like to list all page B's that have been included one time or more into a page A. I guess (this is my question) the only way to find out what page B's that have been included somewhere is to loop through all page A's. I figure that multiselect, or any form of association is only one-way, not two ways? The B's are not aware of where they are included? thanks J

Hey hello, Basic question: If I have tagged posts, and I would like to list all tags (in this case it's a bunch of associated pages; 'page'-type) that have been used at least once, I'd have to loop throught all posts, right? There is no shortcut? thanks! J

Tried replacing Pagefile.php, and it works for me thanks! =) J

Works perfect! Many thanks, J

Hey there, nice module. I'm using it for percentages to set fluid sizes and such. I ran into a small issue, it seems like it always ignores the default value - i can't get it to be 100% as default, for example thanks for any input!

Hi there, seems like I got the same issue. Files arent deleted in the file structure after deleting in the cms. server has PHP Version 5.3.2-1ubuntu4.17

Perfect, thanks. Thats the answer I was hoping for! J

Hello there. Quick question about something I couldnt find out by scanning the forum: Can I add a second language with the multilanguage text fieldtypes and still keep the existing content. Ie. can I translate a website with an existing content and structure, or do I have to plan the multilanguage support from the beginning? thanks! J

Thanks for the input! In my current project the 'Create New' option covers most of my scenarios quite nicely. Although, FYI, for more complex structures it's quite impressive how the subsection manager has a search field to find 'joined' items, and how you can create structures with several layers of hierarchy in one single page, that still are intuitive for the client to edit. J