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.

I can give more info for sure, thanks for your help guys. PW 2.4.0 PHP 5.3.22 MySQL 5.1.53 Apache 2.2.17 This issue has been seen across other servers too, some windows (local devs) and some linux (staging / live). I've upgraded my local dev version to the spec above to try and sort this issue out basically - so I have some freedom to play around with testing etc. As I mentioned before it's only on some pages this is happening - some of the pages edit absolutely fine that use the exact same template, so I'm thinking there might be something in the content iteslf that might be affecting it. Can anyone guide me to the right part of the PW code that is triggered when you hit save in the CMS editor (client or server side pointers are all helpful). Thanks again s

Well the pages and repeaters across the site have been working fine for a while, it's only now that our editing team are using it properly that this issue was noticed. The saving works fine when editing some pages using exactly the same template - so I'll do some more testing and try and find out what the broken pages that won't save have in common.

Well I've got the latest version of PW in there, but not sure I want to go for the complete fresh install route quite yet - this is a mature site back-end and there's a tonne of content in there too. Sounds like it might be related to a 3rd party module or some of our own code somewhere though, if this hasn't been a well-known problem in the past. I'll debug on the browser side to see what might be going on when saving - something in there isn't registering the fact that input field(s) have changed their content I'm guessing, or it could be on the database / back-end saving side too I guess, but perhaps less likely.

Yes my PHP and mySQL are all over the required minimums too.

Hi guys OK - so I've eventually got round to upgrading my ProcessWire install to the latest version, and I'm still seeing this issue - repeaters in certain templates not saving at all, unless I edit the amount of repeaters or a different field elsewhere in the page - see my original description above. Also I've noticed that if I change the "ready-edit-items" number in the settings for the repeater, this seems to have no impact at all, i.e. it always just gives me the default 3 items? Can anyone suggest a fix or way of debugging this? Thanks s

OK cool - thanks for the advice, I will try upgrading PW and PHP and let you know if it solves the issue.

Has this been a known issue in the past then that you've heard of? Would be kinda cool to know if an upgrade will sort this before I go there.

Hi all I've just taken over the codebase for a new site in development that uses ProcessWire, and so far I'm really impressed with it all, and have managed to find solutions to all my problems to date. Thanks so much for everyone who has contributed to the project so far. However - there is a problem that has cropped up with some of our pages and I can't find any mention of it anywhere online. When editing in the CMS, some repeaters get into a state where new edits are no longer saved. So you make an edit, hit save, get the "page has been saved" message, but they are just as they were before. Interestingly though, if you add or delete a new repeater block at the same time as editing any of the repeater blocks, the changes are then saved properly. Similarly if you edit any other normal field on the page, along with one of the previously "unsaveable" repeater fields, the changes are saved properly too. Has anyone seen this problem in the past? We are running a fairly old version of PW (2.2.12), so I'm happy to upgrade if this was a known issue that has been sorted. Thanks s