Urgent, WILL PAY: Help debugging Image fields

[Ovi_S]

We have been having this huge issue for a year or so and despite repeated posts on the forums I am unable to find a solution. 

Our inability to fix this is ruining our business and the reputation we have built with our clients.

The problem is that an image field will sometimes will break with no visible cause. It will either:

- stop saving image descriptions (first simptom)

- stop saving any image files that are uploaded to it. The image files seem to be uploading just fine, but when you save the page they disappear. 

It started with just a single field on a single website. Over time, the issue has begun appearing all over our websites that are using Processwire. We've had to do workarounds such as creating a new image field and manually re-uploading all the files for all the pages, but it doesn't take long before the new field breaks too (and it's very time consuming to do).

As I've said, I've posted about this before, each time it was considered a freak occurrence, not worth investigating further, since no one else seems to be having the same issue. 

I have tried all I can to fix this (creating new fields, creating new Processwire installs, changing server configurations, updating Processwire, using different image fields) - nothing works.

I use to love Processwire, now I fear I've made a big mistake choosing it as our main CMS. We've built many websites around it, and it seems all of them are susceptible to this bug.

I am willing to pay for the time of someone how can fix this. I will provide access to whatever they need (Processwire, FTP, database, even server configuration - we have our own VPS with Servint and can pretty much do anything to it).

Please, anyone who can help, let me know here as soon as possible.

We can't afford to put the time in to switch all our websites to another CMS. There's too many of them and some are pretty complex. I love Processwire for everything it can do, but this bug is killing us.

[WillyC]

ovis u post.here same thng 3 yrs 

same ,,bug,, nobodys ever else seen

peoples helps u ands u.no replys

if u needs help.go back und first 

reply to peoples.thet helpd u here 

https://processwire.com/talk/topic/3363-image-field-description-not-saving/

and.here (!)

https://processwire.com/talk/topic/11102-image-fields-stop-saving-descriptions-after-a-while/page-2

[Ovi_S]

As I said, I have had this issue before. I didn't want to do thread necromancy so I opened up this new one offering to pay for a solution.

For some reason I missed Ryan's reply on the second thread you mentioned. As you can see in that thread I did respond, provide details and updates on attempted fixes, but none of them worked. 

I'm sorry if I offended anyone, that was not the intention. I'm not looking for any trouble, I'm just trying to save our company's websites.

We have had this problem on fresh installs of version 2.7 and above on our server. It doesn't occur right away, and that's the problem. If I knew of a sure-fire way to reproduce this I would file a bug. 

Please let me know what I should do at this point.

[Peter Knight]

I didn't read your previous posts but it seems this happens on a particular server?

Can you post as much details as possible about that server configure and your environment?

[Pete]

I would suggest considering moving a smaller site where this happens regularly to another server with a different host if you can to see if that resolves things. That would pinpoint a server config issue right away if the issue is happening a lot.

[Ovi_S]

Thanks, here it goes. I've attached the full PHP config as an image, here: http://ucw1.dvsdev.com/php-full-config.png (couldn't figure out a way to attach it to the post without embedding it, and it's quite large) . Please let me know if there's anything missing:

server: CENTOS 5.11 x86_64 virtuozzo

 

Default PHP Version (.php files): 5

PHP 5 Handler: suphp

Apache suEXEC: off

Apache Ruid2: off

 

Apache 2.2 with modules:

Asis 

AuthnDefault 

Deflate 

Env 

Expires 

Fileprotect

Headers 

Mod FastCGI v2.3.9 

Mod SuPHP 0.7.2 

Proxy 

Version 

PHP 5.5

Bcmath 

CGI 

Calendar 

CurlSSL 

FTP 

GD 

Iconv 

Imap 

MailHeaders 

Mbregex

Mbstring 

Mcrypt 

MySQL "Improved" extension. 

Mysql 

Openssl 

PDO 

PDO MySQL 

POSIX 

Pear 

Safe PHP CGI

Sockets 

TTF (FreeType) 

Zip 

Zlib 

Additional OptMods

Suhosin %s for PHP 

[Pete]

Can you let us know the web host too?

[adrian]

Two things stand out to me: Suhosin and suPHP. Neither of which may be the issue, but might be worth investigatng a little.

I know that suhosin can be a pain - I used to use it but eventually found I was spending too much time configuring it to extend its limits anyways.

As for suPHP - there is this thread: https://processwire.com/talk/topic/6088-cannot-allocate-memory-errors/

We never got a final resolution from the OP, but I did note that the error he was getting was common amongst suPHP users. Is there by chance anything in your error logs that mentions memory errors?

[Ovi_S]

@Pete, the host is ServInt, we have a VPS there. 

@Adrian, looking for errors now, will post back shortly.

Thanks for the help!

Also, I have tested multiple PHP handlers in hopes of fixing the issue and it persisted on all of them.

[Peter Knight]

I would suggest considering moving a smaller site where this happens regularly to another server with a different host if you can to see if that resolves things. That would pinpoint a server config issue right away if the issue is happening a lot.

Yep - would have been the first to try. Sounds like the common denominator is your host so a 30 min job could save you months of anxiety.

The only issue I've ever had with PW image fields was an image upload making the image appear twice in the image field.

I never got to the bottom of if but one of the subsequent releases seemed to solve it. 

I wonder what version of PW he's running too. Ovi_S ?

[Ovi_S]

I looked at the error logs of two of the affected websites, the logs contain no errors at all being generated when I save the affected pages.

I'll try moving an install to another host, but if the problem goes away, how do we know what caused it? Do we compare server settings? i wouldn't know where to begin. There might be a lot of differences and only one might be causing the issue.

As for the PW versions, this has been happening from 2.3.0 al the way to 2.7. With normal, core image fields, CropImage fields (deprecated plugin - talking about the older versions of PW where we used it) and CroppableImage plugin.

What host do you recommend for moving one of the affected websites to?

[Craig]

What is the environment like for the sites during development? Local *AMP on a Mac/Windows workstation, or some Vagrant type of setup? And, crucially, do these development versions have the same sort of problems?

[Ovi_S]

We develop on the same server, on development subdomains. 

Could I please get a recommendation for a host that runs without problems? Thanks!

[pwired]

We develop on the same server, on development subdomains.

So you only develop online outside the company ? Not local/intranet ?

[kongondo]

Could I please get a recommendation for a host that runs without problems? Thanks!

All the other hosts!  . Just kidding. I doubt this is a host issue but rather a server configuration one. processwire.com runs on the same host as yours - ServInt - without problems. If you want to try other hosts, there's several other threads in the forums with several recommendations. Please search..

[Ovi_S]

So you only develop online outside the company ? Not local/intranet ?

Correct.

All the other hosts!  . Just kidding. I doubt this is a host issue but rather a server configuration one. processwire.com runs on the same host as yours - ServInt - without problems. If you want to try other hosts, there's several other threads in the forums with several recommendations. Please search..

 I won't be getting a VPS but a shared account, so I won't be having access to server configurations, that's why I was asking for a shared hosting recommendation. I already have a VPS which I can configure - that's my initial problem, finding the correct config.

I'm in a situation where ServInt support says it's a Processwire issue, and the Processwire community says it's a hosting issue 

I know processwire.com is on ServInt, that's why we chose them initially, because I saw a forum post from Ryan recommending them. Was hoping to avoid this kind of issue. Guess that didn't work out quite as planned

[Ovi_S]

On a related note: can anybody send me their server configuration (especially if you are hosting on ServInt)?

I can pass it along to ServInt support and ask that they configure the server exactly the same. Worth a shot?

[LostKobrakai]

A quick option could be a pre-build LAMP instance on digitalocean. It's created in minutes and payed on demand, which is probably a nice thing if you're just testing stuff out. And I want to support adrian. I've only read bad things about suphp and suhosin. 

[diogo]

I'm building a image heavy site on Digital Ocean with a default Server Pilot configuration. Although the site is still not published, the team from the client is uploading content for at least 4 months and everything seems to be fine. You can for instance create a new VPS on Servint and let Server Pilot do the configuration, if all seems well, you just have to compare both configurations.

Edit: strike that, Servint doesn't serve unmanaged VPSs. Maybe you can do it on Digital Ocean or Linode in that case.

[ryan]

@Ovi_S we run on a ServInt server here too, and actually so do all my clients… and pretty much every site I work with, for the last 10 years. I can't say I've ever observed the issue you've mentioned. So I doubt it's a ServInt issue, and instead must be related to something about the server configuration. For instance, none of the servers I use at ServInt have suhosin or suphp active. Now I doubt that suphp would be an issue, but suhosin–maybe. It would be worth trying to disable that at least temporarily if you can. Since the issue you've described seems a little random and no errors are involved, it has that sound of something interfering with the normal requests, which I think suhosin might do. Based on available info so far, I'm inclined to think this is the first thing that should be looked at. 

I'm sure you've tried this, but does using a different browser make any difference?

If you look in your /site/config.php file, what settings are you using for $config->chmodFile and $config->chmodDir?

Are you able to duplicate the issue on completely stock installation of PW 2.7.x or 3.0.x using one of the default profiles? (with no 3rd party modules installed). If so, I'm happy to take a look at it if you don't mind PM'ing me the PW admin login and FTP (or SSH) login to the installation. I would also need instructions on exactly what steps to take in order to reproduce the issue. 

[Ovi_S]

Thanks so much for your help Ryan! To address your suggestions:

1. I will disable suhosin and see if it makes any diference.

2. changing the browser didn't help as far as I know but I will test again. We normally use the latest version of Chrome.

3. $config->chmodDir = '0777'; $config->chmodFile = '0666';

4. If I could reliably reproduce this on a clean install I would have filed a bug ages ago.  Unfortunately it seems to appear after some undetermined amount of time, under unknown conditions, for unknown causes. That's what makes it so frustrating and so hard to debug. 

A quick option could be a pre-build LAMP instance on digitalocean. It's created in minutes and payed on demand, which is probably a nice thing if you're just testing stuff out. And I want to support adrian. I've only read bad things about suphp and suhosin. 

I'm building a image heavy site on Digital Ocean with a default Server Pilot configuration. Although the site is still not published, the team from the client is uploading content for at least 4 months and everything seems to be fine. You can for instance create a new VPS on Servint and let Server Pilot do the configuration, if all seems well, you just have to compare both configurations.

Edit: strike that, Servint doesn't serve unmanaged VPSs. Maybe you can do it on Digital Ocean or Linode in that case.

Thanks so much for the hosting suggestions guys, I will definitely give those a try, I also bought a cheap Godaddy hosting account before I saw your posts (bluehost was only allowing yearly plans for non-VPS) so I will also try it there.

[ryan]

1. I will disable suhosin and see if it makes any diference.

Just looking at all the things Suhosin gets involved with (https://suhosin.org/stories/configuration.html), it seems likely to me something with your files field(s) are generating a false positive with Suhosin. For instance, maybe it doesn't like something about the property name used by file descriptions or some combination of factors. It looks like there is a whole lot of stuff that can be configured with Suhosin that could cause all sorts of problems with different web applications. So after looking closer at Suhosin I stand by what I said earlier of this probably being the first thing to look at. 

2. changing the browser didn't help as far as I know but I will test again. We normally use the latest version of Chrome.

If you are using Chrome, it's definitely not the browser. I think the majority of us here are using the latest Chrome as well. 

3. $config->chmodDir = '0777'; $config->chmodFile = '0666';

These permissions are usually considered to be far too open. It's certainly possible suhosin is having a problem with this. Though since you are on a dedicated VPS, maybe it doesn't matter much for your situation, but perhaps it does to Suhosin. Since you are using suphp, you can actually lock those permissions down quite far... the files likely don't even need to be readable outside of the user account. Whereas, your current permissions have them globally readable and writable to everyone (even if everyone is just you, since it's a dedicated environment, it's still likely to trip security-related things like Suhosin). 

4. If I could reliably reproduce this on a clean install I would have filed a bug ages ago.  Unfortunately it seems to appear after some undetermined amount of time, under unknown conditions, for unknown causes. That's what makes it so frustrating and so hard to debug. 

If disabling Suhosin doesn't do it, see if you can just find any installation producing the issue reliably on a core Images field, and we can take a look at that. 

[ryan]

Just found a Suhosin setting that will definitely interfere with PW files fields:

suhosin.post.max_name_length

• Type: Integer
• Default: 64

Defines the maximum length of variable names for variables registered through a POST request. For array variables this is the name in front of the indices.

 

 

Note that 64 as the default setting for "max length" of variable names in POST requests. This appears to be ON by default with this value in Suhosin. That's going to cause issues all over the place in PW.  If you have a files field with a name more than 18 characters, or any files field in a repeater, then Suhosin is going to block any data in it. It looks to me like Suhosin's default settings will potentially interfere with most of PW's multi-value inputs, not to mention some of Suhosin's other default rules will interfere with other parts of PW (and I'm guessing almost any powerful CMS other than perhaps WordPress). 

[LostKobrakai]

It looks to me like Suhosin's default settings will potentially interfere with most of PW's multi-value inputs, not to mention some of Suhosin's other default rules will interfere with other parts of PW (and I'm guessing almost any powerful CMS other than perhaps WordPress). 

That sounds exactly like the things I've read about suhosin by now. And I've always wondered, why this thing is still alive.

[ryan]

That sounds exactly like the things I've read about suhosin by now. And I've always wondered, why this thing is still alive.

Probably WordPress. I'm guessing its default configuration has at least something to do with WP. There doesn't seem to be anything inherently wrong with Suhosin (rather, just how it's configured), and in fact it seems like it could be quite a useful security tool. But it would have to be configured for the software it's running with, otherwise seems like it's very likely going to interfere with that software.