OviS Posted October 6, 2015 Share Posted October 6, 2015 As the title states, this issue is a slippery one, as it doesn't happen immediately when creating and using a field. Problem description: After I create an image, cropImage or croppableImage field (they all share the problem) it works as intended, I can upload, crop and edit the description as I please. After a while (editing a few pages i guess) the description field for each image stops saving, when I save the page, it remains "stuck" to whatever value it had (or empty). Uploading and deleting images still works as normal, just the description field and any other text fields I add via "imageextra" stop working. Steps to reproduce: I don't know what steps to take to reproduce it exactly, but it has been happening with every field I have tried using. So far. Solutions tried I have tried using different image fields, and even using the "imageextra" plugin - nothing helps, they all stop working after a few minutes. I have no errors in the chrome js console, no errors in the PW log. Running "check field data" on the problem fields returns no errors or problems. Configuration: This last issue is on a live website running PW 2.6.1 Master. Server is running Apache 2.2, PHP 5.5. What's worse, this has been happening over the course of the last cople of months on other websites, on the same server, on multiple PW versions. Thanks in advance for any help, if I can't get this to work I will have one angry client Link to comment Share on other sites More sharing options...
LostKobrakai Posted October 6, 2015 Share Posted October 6, 2015 Maybe a long shot, but are those pages multi language? Link to comment Share on other sites More sharing options...
OviS Posted October 6, 2015 Author Share Posted October 6, 2015 Nope, not using multi-language at all Might have something to do with deleting images though, that might trigger the bug. Link to comment Share on other sites More sharing options...
OviS Posted October 7, 2015 Author Share Posted October 7, 2015 Update: if i create a new field for an image field using "imageExtra" plugin, the new field works as intended. If I remove and add a field that wasn't working before, that does nothing (it still doesn't work when I re-add it). So the image text fields are somehow getting corrupted after being used in some scenarios. Update2: Also, if i add the image field to another template, it still behaves the same way (not saving description) so the problem is at field level. Update3: I've just noticed another problem: I can't delete images from the image fields exhibiting this bug anymore. I mark them for deletion and save the page - they appear right back after the page reloads. Link to comment Share on other sites More sharing options...
OviS Posted October 8, 2015 Author Share Posted October 8, 2015 Anyone? Any ideas please? Link to comment Share on other sites More sharing options...
adrian Posted October 8, 2015 Share Posted October 8, 2015 Anyone? Any ideas please? Ryan has been notified of this thread, so hopefully he will be able to give you an answer shortly. Although I see that you mention "ImageExtra" - is the problem only related to sites with this module? Link to comment Share on other sites More sharing options...
OviS Posted October 8, 2015 Author Share Posted October 8, 2015 Thanks for that Adrian! No, the issue is not tied with the ImageExtra module, I installed that one in an attempt to find a workaround - adding another field to hold the description, but those fields started malfunctioning as well. Most recently it's happened on a website which had the CropImage Module installed, with ProcessWire version 2.3. But the issue is not affecting only CropImage fields, but normal image fields too, which leads me to believe it might be a problem with the core image field, which all of these other fields extend (if I understand correctly how modules work). Upgrading PW and all modules to the latest stable version did not fix things (as I hoped), btw. EDIT: right now I have created a new CroppableImage field and copied all the content for each page into it, but I left the malfunctioning field in place, to provide a subject for analysis. So far the new CropImage field is holding, but it did bug out the first time I was copying the content over about half-way through - and I had to start over again by deleting it and creating a new CropImage field. I learned something that way - if I delete a bugged image field and then re-create it with the same name, the problem persists (the description field still doesn't work) - I had to give the new field another name. 1 Link to comment Share on other sites More sharing options...
OviS Posted October 17, 2015 Author Share Posted October 17, 2015 Two weeks later and still nothing Sorry but this is ruining our business. I'm biting the bullet and converting all our affected websites to Craft CMS. Link to comment Share on other sites More sharing options...
tpr Posted October 17, 2015 Share Posted October 17, 2015 Have you tried tweaking php settings, eg. max_input_vars? See for example https://processwire.com/talk/topic/8345-deleting-large-number-of-images-silently-fails/ 1 Link to comment Share on other sites More sharing options...
arjen Posted October 17, 2015 Share Posted October 17, 2015 Hey OviS, Sorry to hear you are running into this weird issue. I hadn't noticed the thread before, otherwise I would've responded earlier. At my previous company we had exactly the same issue. I never could really reproduce it. But when we migrated our servers the issue went away. We came from a rather old MySQL version (5.0.x.x) to a new one (5.6.x.x). I didn't noticed at once because we were using a temporary solution. We created a repeater with an Image field and a Text field per row. In the Image field setting we set the row to 0 so the description didn't show. Not really nice, but workable and our clients didn't really bother after a while. After the migration I did some work for a smaller client with images. I tried to see if the issue had been resolved. After a few edits and some time, it kept working. We took the plunge and converted them all back. No problems since. I don't know your setup and the way you guys work, but I would say a full site convert seems a lot more work then to create a temporary workable solution. Also you could try to reproduce with another MySQL version. 2 Link to comment Share on other sites More sharing options...
OviS Posted October 19, 2015 Author Share Posted October 19, 2015 Thanks so much for your reply @arjen ! We created a repeater with an Image field and a Text field per row. In the Image field setting we set the row to 0 so the description didn't show. Not really nice, but workable and our clients didn't really bother after a while. We've been doing it on a number of websites as well, believe me, but some websites get to the point where you can't delete an image to replace it with another, and that's just un-workable. At my previous company we had exactly the same issue. I never could really reproduce it. But when we migrated our servers the issue went away. We came from a rather old MySQL version (5.0.x.x) to a new one (5.6.x.x). Glad to see I'm not going insane here, was starting to doubt myself . We are on a managed VPS from Servint so we should be able to switch MySQL versions. Thanks so much for the tip! As for migrating - the problem is not only this bug, but the way it's been addressed. We need a reliable way of getting some support if something like this happens in the future. The more websites we make the more support becomes an issue, and if something like this were to affect a large number of our websites and break them then we couldn't afford to wait for 2 weeks and hope for help on the forums. I LOVE the PW community and PW itself, but this is is becoming too big a risk to our business, that's why we're considering migrating (and yes that is a lot of work indeed). Will let you know if I can get to the bottom of this. Link to comment Share on other sites More sharing options...
OviS Posted October 19, 2015 Author Share Posted October 19, 2015 Have you tried tweaking php settings, eg. max_input_vars? See for example https://processwire.com/talk/topic/8345-deleting-large-number-of-images-silently-fails/ We don't have anywhere near the amount of variables discussed there, but I will definitely look into both post_max_size and max_input_vars. Thank you so much for your suggestion. Link to comment Share on other sites More sharing options...
arjen Posted October 19, 2015 Share Posted October 19, 2015 Thanks so much for your reply @arjen! You're welcome. Glad to see I'm not going insane here, was starting to doubt myself . We are on a managed VPS from Servint so we should be able to switch MySQL versions. Thanks so much for the tip! As for migrating - the problem is not only this bug, but the way it's been addressed. We need a reliable way of getting some support if something like this happens in the future. The more websites we make the more support becomes an issue, and if something like this were to affect a large number of our websites and break them then we couldn't afford to wait for 2 weeks and hope for help on the forums. I feel ya, I really do. That's the thing with this open source stuff we all like. I've have some outstanding issues (1, 2) as well. But we've created workarounds. When a solution pops up we fix it for good. Using open source software is an risk to be assessed, but than again I have never ever used software which didn't have it's bugs/complications. Even commercial software has its quirks or bugs which might not be a top priority to the company which owns the software. addition #1: I have to state here that I've never ever had any business critical trouble with ProcessWire that didn't was solvable in one way or another. I've build shops, imported or exported all kinds of stuff, connected ProcessWire through all kinds of API's, made websites which generated massive income either direct of through lead generating. They are all up and running and performing really good. That being not a real web developer says a lot about the system. Therefore I accept a few quirks here and there. In the end they are likely to be solved or we outgrown into another solution based on ProcessWire. 3 Link to comment Share on other sites More sharing options...
OviS Posted October 19, 2015 Author Share Posted October 19, 2015 Just updated to MySQL 5.6.23 from 5.1.73 - problem still persists. Link to comment Share on other sites More sharing options...
OviS Posted October 19, 2015 Author Share Posted October 19, 2015 max_input_vars was set to 1000 and post_max_size was set to 100M all along, so this lead is a no go as well. Link to comment Share on other sites More sharing options...
Macrura Posted October 19, 2015 Share Posted October 19, 2015 @OviS, i'm also sorry to hear about the troubles you are experiencing. I can only comment on the steps I would take if I was in your situation, and that is I would copy the whole site to a different server and see if the problem still happens. In your description of the problem, you said this was happening to many sites on one server, and if we assume that your situation must be unique, as no one else has reported anything similar, then the server would be my prime suspect. In addition, Arjen reports the same issue was solved by migrating servers. But when we migrated our servers the issue went away. Link to comment Share on other sites More sharing options...
OviS Posted October 19, 2015 Author Share Posted October 19, 2015 @Macrura thanks for the advice, but we're usinng a managed Cloud VPS server on ServInt. We have full control over the server, and honestly I don't want to switch from using ServInt since they have been an amazing host so far. All server installs and upgrades were done by ServInt MST professionals at my request so I'm sure I haven't messed anything up on that regard. Currently we're running Apache 2.2.31 on CentOS 5, PHP 5.5.30 and MySQL 5.6.23. Thinking of upgrading the OS and then Apache to 2.4.17, seeing if that helps. Also I detected we're actually running a buggy version of iconv, seeing if fixing that might help. As you can see I'm really trying to cover all the bases hunting down for this thing, and I still haven't lost hope (although we are migrating some of our key websites as we speak, unfortunately). Other CMS we've tried running on the server has worked flawlessly. There must be an bug / missconfig somewhere that's being missed I think. Link to comment Share on other sites More sharing options...
Macrura Posted October 19, 2015 Share Posted October 19, 2015 @OviS, IMHO it wouldn't make sense to migrate a site off of processwire prior to doing a simple alternate server test, b/c once you know it's the server and not PW, won't you regret that decision? Link to comment Share on other sites More sharing options...
arjen Posted October 20, 2015 Share Posted October 20, 2015 Good to hear you are not giving up! One thing to note: we migrated our sites with the workaround. After our discovery we created the new image fields. So a one-on-one migration might not work out of the box. There are a lot of variables at stake so it's really hard to debug. It could be serverside, MySQL versions, something corrupt in the database... 2 Link to comment Share on other sites More sharing options...
horst Posted October 20, 2015 Share Posted October 20, 2015 One thing that I spotted in this thread is the change and cycle through different image fields and PW version on one Site at least, PW 2.3 to PW 2.6 now. Also the use of cropableimages, what is clearly signed as alpha state. There were some changes needed and done to the naming scheme of image variations between PW 2.4 to 2.5 and also 2.5 to 2.6. So I believe that not all 3rd party image fileds are up to date with that. And that switching between different versions, forth and back, and than change PW versions too somewhere in between, maybe this can render a DB corrupt in some parts. At least I have had some weirdness with image fields too in the past, but that definetly was produced by switching and hoping through different image fields and PW versions, including the use of third party alpha modules. (not proper functional install / uninstall routines, maybe a server - / DB connection interrupt at the wrong second, all this can be an initial point for a damage in the DB) I don't think it has to do with the base core image field (since) PW 2.3 or earlier. How many installations out there with PW? How many people are arriving here with a problem like that? Not to be able to change / save images and / or descriptions, there would be more reports here to read. Sorry that it doesn't help in any of the problems 1 Link to comment Share on other sites More sharing options...
Soma Posted October 23, 2015 Share Posted October 23, 2015 What I would try is install a fresh PW with intermediate profile and edit images, and see if it happens. If not, it may some problems of you're install, third-party module or your own code somewhere. 99% of the cases when such things happend it was a fault of myself or another module and not PW. I've never experienced image saving problems, unless I made my own image field. I remember someone having same problems, so a search turns up: https://processwire.com/talk/topic/3363-image-field-description-not-saving/ Coincidence that there same issue and no solution with a user Ovi? 3 Link to comment Share on other sites More sharing options...
ryan Posted October 24, 2015 Share Posted October 24, 2015 Ovi, I'm in agreement with Soma here that you need to try out a fresh PW install with no 3rd party modules to see if you can still duplicate the issue. If so, it would point to something with the server, since nobody else has ever reported a similar issue. Sometimes extra Apache modules like mod_security can cause strange stuff in this respect, so that would be something to ask ServInt to look at removing or disabling temporarily. But if you do have a default/unmodified PW installation reproducing the issue, and don't mind providing me access to it, I'd be happy to login and take a look to see what I can find. 2 Link to comment Share on other sites More sharing options...
OviS Posted March 4, 2016 Author Share Posted March 4, 2016 The solution is here: https://processwire.com/talk/topic/12375-urgent-will-pay-help-debugging-image-fields/ 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now