sharpenator

Yeah - It just logs out, hence why I think it's probably a session fail rather than anything more server-related.

OK - thanks Any advice on error logs where I can try and pick up what's causing it to bomb out?

And one more final thought. Some of our pages are very big and have many fields. Could this log out occur due to PHP max_input_vars limit being reached?

Some more on this - is there a way I can tell which reason the user was logged out, e.g. if it thinks the session time has expired vs other reasons? - it seems to happen more when someone is making lots of little edits - should it matter that editors are using multiple tabs and copy content between each one? Also of note: We are using an in-house module that saves the collapsed states of the page hierarchy into the session variable - i.e. helps the editors by remembering which fields were collapsed for next time, so they don't have to go in and out of a big hierarchy each time they make and edit - could this be the culprit here? - it uses ajax to save the "fold status" on the fly to the session while editing, using the page id - could there be an issues if the session is malformed or being access in a bad / insecure way? Cheers S

OK - cookies all removed and this is still happening. Is there anywhere I can look like a log that might show the error that forces the throw-out? Thanks S

Cool thanks. That thread was helpful - I'll instruct them to remove cookies relating to the site and see if a cookie conflict might have been at fault, perhaps left over from a previous version. S

Hi A couple of my content editors seem to have an issue I've not seen before. When they're working full pelt at editing stuff, sometimes they hit "save" in the processwire CMS and it throws them out instantly and they lose their changes. They are then asked to log in again. I thought this might be session related so I've set sessionExpireSeconds to a whole day (86400), sessionChallenge to false, and sessionFingerprint to false too. One editor in particular sees this issue at least a couple of times a day, and it normally happens around the same time of day too, which is 5:30-6:00pm UK time, so towards the end of his working day. Anyone else seen this or got any tips to try and prevent this? Thanks S

Hi K I have actually seen this again in another page now, so I think there is still something fishy going on with pages with repeaters and page fields in in general. The repeater I'm now seeing the issue with has 3 or 4 text fields and am image, and not all pages are affected. Seems to be only pages with certain page fields set. For the moment, my content editors are using the workaround where they edit a repeater and then add and delete a fresh one at the same time to "wake up" the "something has changed" status. It sounds like this isn't working for you though K. Sorry I can't be of more help, I'll let you know if I spot anything else. It might be worth trying to recreate this issue constructing new fields and a template from scratch K?

Great - thanks for the suggestions, I'll have a play with these s

Hi there, wasn't sure of best place for this, so thought I'd try general support. I'm working on a site that has a load of products all with their own page. Each product can have one or more formats, let's call them CD, DVD and USB. On each product page I'd like to be able to show an icon under the product's title which shows the product's format. I'd like these images to be manageable in the CMS. Thus what I'm after is as follows: - Ability to add images to a "format image" icon management page - Then on the product template, editors are presented with a multi-select style list which pulls the image names from the management page, and lets them pick which product formats are supported - The page is then rendered accordingly The only way I can think of doing this without module coding is to have a separate page per format, add an image in on each page, and the use a page select field. I'd really like to come up with a solution where the editor can see all of the images in one view though via a image management kind of template. Any suggestions in general here? It's likely I'm missing a more obvious way of doing this! Thanks, s

Cool thanks for your help guys. @teppo I'll let you know if the "cloning all the pages from scratch" strategy works in the long run anyway.

OK final say on this one, I have a workaround now - When going through the affected template in more detail, I found a nasty repeater-within-a-repeater part of the structure that wasn't actually being used when rendering the page, but was in there nonetheless. - I removed this from the template, which didn't fix the bug straight away - But - I then cloned one of the pages affected, so forcing a freshly created version to be made from scratch - The bug was then fixed in the fresh clone - i.e. repeaters seem to save ok again now, no matter what page field settings I had set - So my plan is to go through all the pages, clone them, delete the old ones, and the rename the new ones to take their place - I may do this programmatically using the API - One thing I'm wary of too: obviously when deleting pages, any references to the deleted page from elsewhere in the content will get broken, so I'll need a way of fixing these, hopefully via the API too Hope this helps anyone seeing similar weirdness s

HI there So I haven't been able to recreate a simpler test page for you to try and recreate this issue yet, but some more observations as I work through this - Once the "naughty" page select item has something selected within it, the repeater save issue is there for all repeaters on the page - It doesn't matter what type of selector I use, the bug is there for all types (.e. Asm vs select vs whatever) - It doesn't matter if the page item is a multiple or single, or null vs boolean in those options - The position of the page item within the page content structure has no bearing on the bug - I have deleted and recreated the page field from scratch and the bug is still there - There are other page items on the page, so there might be something in teppo's suggestion that multiple page fields could cause this - From a quick debug, it looks like the new repeater edit data gets through to the backend, but for some reason it doesn't register as a field that has changed when the page field elsewhere in the page has something selected Will keep you posted on further investigations, but if anything here sparks a light bulb or something I can test out, please let me know - I don't actually have a workaround for this issue yet, other than getting content editors to add and delete a new repeater item each time they edit, which is not great really. Thanks s

OK - update on this, thanks to teppo for getting me curious about page type fields. I can now recreate the bug - there is a certain page field in the template involved, which uses the PageListSelect input type for a single page. If there's something selected in there, the repeater lower down the page doesn't save properly. If I unselect the page, bingo - the repeaters lower down in the page save fine again. To be clear - the page field is not in the repeater, it's in a completely section of the content. Will do a bit more investigating and come up with a simple recreatable case soon. Thanks everyone for your help thus far

Ah ok cool. Yes - in my current set up I have some pages that it always happens for, and some that seem to save fine, so I'm trying to spot patterns now in the ones that don't work, and creating pages from scratch to try and get some repeatable steps here for other people to try. No luck yet, but early days. It would also be good to establish if it's a client side issue - i.e. is there something in the "this field has changed" js code that that is breaking in certain circumstances.