formulate

Unfortunately doesn't help. I actually NEED all users to edit at the same time. I don't want to lock them out at all. It's critical functionality for a web app I'm developing. I also forgot to mention that users will be editing from a front-end form, not the admin.

Hi, I have a ModX site I'm porting over and I have the following situation (simplified for explanation purposes): 1 page. 10 text fields. 10 individual users that can edit the page. Each user is assigned to and can only edit one field. Example: User 1 = Field 1, User 2 = Field 2, etc. What happens when all users edit the page at the same time (ie: open the page within a few seconds of each other) and then save a minute or two later at random times. Is PW smart enough to compare what's changed and only update the one field or will it overwrite all page fields with data from that particular user's session? Also, what happens if 10 users try saving all at the same time? I presume PW just queues up the DB saves and sequentially executes, hopefully only writing data that has changed via a compare of some sort. I don't want a situation where User 2's save overwrites User 1's field data, etc. The way I got around this issue with ModX was to assign users a unique page each, that way they are all writing to their own unique page and therefore the above issue is not present. I then fetch and glue all those page's info together for presentation on the main page. Make sense? Is this the best approach to use in PW? Is there a better way I could be doing this?

Yeah Unfortunately the only way I've found to get around this is do two queries on the listings page. One query has no limit and passes the results as a session string variable. The second query has a limit and is used for the list / paginating of the list. I still think there's a better solution here using start= somehow, but I'm not PW savvy enough to figure it out. Maybe down the road once I'm well versed with PW, I'll revisit this issue. For now I'll just have to live with the overhead. It seems my development method lately has been "throw money at computing power" to solve any performance problems rather than have well done code Anyway, thanks everyone for your input. On to the next problem.

Unfortunately this won't work because on sub-pages the results are no longer an array (they were passed as a string). Also, it would have the same issue of only having results that were generated by the limit=10. This is the key to the solution: Somehow renderPager() is smart and knows to re-query once you go past the limit. I basically need that same functionality on sub-pages so that my prev/next will re-query based on the custom selectors once the limit has been reached. Unfortunately I don't know how to make myself make more sense and the only solution I can see at this point is re-running the query on every single sub-page. It seems crazy there isn't a simple solution to this. I know there has to be... just out of my grasp. What do people do with blogs and need to display multiple categories at once? Just not use prev / next on articles?

Nearly there! Teppo's solution has worked perfect (not sure how I messed it up the first time) - thanks Teppo! However, my problem now is how do I paginate the results without limiting the original query? On my listings page I only want to show 10 results at a time. If I use the proper approach for paginating and set a limit (ie: limit=10), paginating works but then next/prev (ie: Teppo's solution) will only work for those 10 results, even if there's 1000 pages that match the initial query. It's almost like I need to do 2 queries, one that has no limit to provide proper next/prev links and one that generates the paginated list. Obviously a 10k+ unlimited pages query would suck. I hope I'm making sense.

I thought I had tried that without success. I'll give it another go. For the record, I just finished my crazy idea and it worked! Teppo's suggestion is of course far superior, but I'm just glad my old brain can still come up with creative solutions once in a while Edit: ugh, just realized my solution is identical to Teppo's, however his is far more elegant and he thought of it first! Will report back once I play with Teppo's suggestion some more.

Good point Diogo. However, I think I actually just came up with a crazy solution that may work: Since passing the pageArray as a session variable doesn't work, how about creating a loop that extracts all the page ID's from the pageArray, keeps them in the same order as the pageArray and assigns them as a comma delimited string to a session variable. Then, on the sub-pages, turn the session variable in to an array, find the current sub-page's ID in the array and then go back/forward one place in the array for the ID's of the next and previous pages. Use those page ID's to grab the URL's of the next/prev nav and boom! That way I'm only looking up 2 additional pages on any given sub-page. Sound feasible? This would eliminate a ton of overhead. I'll give it a whirl and report back.

Yeah, this is what I'm thinking. However, I'm really worried about the overhead with re-running the query on every sub-page for every visitor. I'm not joking when I say every query is going to be hitting 10k+ pages.

Essentially I have multiple categories that a sub-page can be assigned to. I'm allowing visitors to specify which categories they want to view via a form with checkboxes. Those checkboxes directly translate to selectors for the $pages->find query. Hence every visitor's results are going to be different depending on what selectors they have used. Therefore, I need a way on the sub-pages to navigate next/prev based on the unique user's selectors they specified on the listings page. I'm thinking I either have to session the results or I session the selectors and re-run the query on every sub-page. I'm reluctant to re-run the query as I have 10,000+ pages to query and I'm worried about overhead. When I tried to session variable the pageArray results, it didn't seem to work (see posts above).

Ok, tried this and it's not working. I think I'm missing something? My Listing uses a different template than my detail pages. Do they both need to be the same template? I don't think I'll be able to do this as the presentation I require is quite a bit different for both of them. I don't understand how $page->next($test)->url would know to use the previous listing page's variable as it's not present on the detail page. Maybe I'm not explaining myself well and saying "previous" page is misleading. I have a listings page that has multiple sub-pages (detail pages). Kind of like a blog. I do a dynamic $page->find on the listing page and then when someone clicks one one of the listings and goes to the sub-page, I need the next/prev to navigate based on the listing page's dynamic $page-find results rather than admin's page order. I can't duplicate the $page->find call on the sub-pages as it's never static. I'm thinking I either need to session variable the results or session variable the dynamic criteria for the $page->find call.

Ok, getting closer but still not there. I have done the following: On Listing Page: $test = $pages->find("template=test, limit=2"); $session->testResults = $test; $content .= $test->render(); On Individual results pages: $test = $session->get(testResults); $prev = $page->prev($test)->url; $next = $page->next($test)->url; This doesn't seem to work. However, if I make $test a string instead of the pageArray, the individual results pages then work for pulling the session variable. Lost at this point.

Unfortunately it needs to be dynamic. The pageArray is built on user input for the selectors and therefore not a static set of selectors. I haven't worked with session variables before, so I'll take a look at that. Thanks for the help!

I've poked around the forums and can't figure out the following: I have a page that uses a $pages->find to generate a pageArray called $test. I am then using $test->render(); to create a list of page links for returned results. When I click on one of the page links it takes me to the correct page (let's call it Page1). So far so good. Now, on Page1 I have some $page->prev and $page->next stuff going on. My problem is that it is creating links for direct siblings to Page1 based on PW's Page Tree and not my previous page's $test pageArray of links. I tried the following: $page->next($test); but this didn't work because I presume $test doesn't actually exist as part of Page1 (the pageArray was generated on the previous list page). I don't know how to make my initial pageArray pass through to subsequent pages and then have a prev / next nav that cycles through my pageArray results. Or am I thinking and going about this all wrong? Thanks.

Ugh, yes sorry. I should have actually tried it before posting. Sorry, new to PW and still wrapping my head around how everything works. I'm amazed at the functionality of the page field. I'm so used to other CMS variables that are basic and need all sorts of functionality built on top to do simple things like allow multiple selection, etc. PW is amazing.

At the risk of bringing this "hippy" conversation back down to the ground, I have the following question: So, let's say I set up a bunch of pages as categories as per Ryan and other's recommendations for using Page Field Reference. How do I go about allowing an article to have more than one category? I presume a repeater field? Or a new fangled page table thingie in 2.5? I think I'm missing how someone selects more than one category when adding / editing an article? Thanks. Solved. Lesson: actually try stuff before posting

While my understanding of some aspects of ModX is top-shelf, my database knowledge and experience is woeful. I can get around in phpMyAdmin and understand ModX's table structure, but writing custom SQL queries, etc. is something I've never done. Trying to create a plug-in for Migrator seems like an unachievable task for me. I think I'm going to have enough trouble as it is just trying to get my database converted properly. Thanks for the responses.

Hi Ryan (and others), thank you for this great module. I'm looking to transfer an old ModX Revo site that is currently using latin-1 encoding. My understanding from the thread here: https://processwire.com/talk/topic/1735-get-data-from-a-latin-1-encoded-db-and-insert-it-into-pw/ is that the following code: $newPage->title = iconv("ISO-8859-1", "UTF-8", $row['HEADLINE']); should convert to utf-8 first. Does your import module take this in to account or will I have to somehow add this in to your module code? Or should I just somehow create a separate php file that will cycle through my CSV and do this first, then use your module to import? I have approximately 12,000 pages of varying types to import, including user accounts. Thanks, K.