joe_g

Here is my user scenario: I often run into the scenario where the frontpage shows perhaps the latest 10 posts, and the rest equals the archive. The editor usually would like to manually order the newest 10-20 posts, and forget about the rest – the rest is found other ways (filtering / tagging / archive). Currently the editors need to move things from the 'frontpage' into the 'archive', not a big problem, but they just need to be aware of the two different locations.

sorry, found http://processwire.com/talk/topic/417-extending-image-field/?hl=%2Bimage+%2Bdescription after posting <- this solves it for me

Hello, Is there a way I can add more data fields than description field attached to image? Simply multiple description fields would already help a lot. I often find myself wanting to couple more data with an image. I know I could use a repeater field, but then I loose multiple upload, a killer feature for the editors. j

Yep, works perfect. Thanks .. !

thanks! no direct solution but helpful

Hi, is there a way to let a newly added page appear on top of the list in the backend instead on the bottom? (without loosing manual sorting) tried searching but couldn't find anything - hope I didn't miss some similar post thanks! J

amazing, now I just need to rethink my structure

soma, seems to work pretty goood thanks!!

Soma, that looks pretty sweet. I tried it but didn't get the little pen icon to show up on my list - any special prerequisites I should know about? tx!

Hello, I ran into this issue: When using markdown as text filter the default language isn't fetched (if the alternate textarea isn't filled out) Disable markdown and it works fine Ion PW 2.2.3 An upgrade might help in my case, perhaps? edit: Problem remains in 2.3 – I suppose a empty textfield with markdown isnt empty, maybe ther is a <p></p> in there or something...

cool, gotcha..!

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!!