http://imaginary.org/projects disfunctional?

[andreasdanielmatt]

The page http://imaginary.org/projects does not load (even if the rest of the site is working). It is linked from the small main menu on top of the imaginary.org page. Could you please check? (maybe it is related to our other server issues?)

[elondaits]

The problem was the Typogrify 3rd party module, which I had to update recently due to problems in its unicode support. The "widow removal" function is running for a VERY long time (it's a regexp, so I assume it's not infinite... but it's probably backtracking like crazy).

This was almost certainly yesterday's problem (high CPU, no disk or database access). I'm not sure it was the cause for the previous outages which were low-cpu, high disk (I was logged in and didn't see processes locked at 100% cpu like with this bug) although it could be somehow related.

I disabled the widow removal functionality so the page is accesible again. I'll see if I can find what the problem was, exactly.

[andreasdanielmatt]

ok, perfect. It seems that we are finding some of the "bad guys" causing troubles.

[elondaits]

What I found:

• When processing the Projects page the Surfer user interface node (http://www.imaginary.org/content/surfer-user-interface) is processed. That page contains a 75k img inlined inside the text, coded as base64 data. Something quite atypical for a simple "Description" text field.
• A recent Typogrify update changes a regexp that was used to avoid widowed lines. The new regexp chokes on the Surfer UI page data because of the base64 content in the img. It's not an infinite loop... it eventually ends... but then the french version is apparently processed for some reason and perhaps other translations after that and eventually you grow tired or the max execution time limit kicks in.
• I'm switching the regexp back to the older version for the time being. I created an issue in the Typogrify project: https://www.drupal.org/node/2618056#comment-10581060 . Perhaps they'll fix it and perhaps it'll be necessary to disable the functionality entirely as a non supported case.
• ... Having said that, I wouldn't recommend having that amount and type of content inside a text field because there are a lot of regexps and filters running because of all the different modules and even if they seem "fast" they're doing a lot of extra processing.

[elondaits]

Fixed in f97538a67f26b4f913ffedd3f5daa048e31e019c

[andreasdanielmatt]

Just to understand: how does the 75k image get into the description text? (it was included with the "insert image" option of the html-text-menu? Or somewhere else?). I am just wondering, if this could happen also in other occasions? (and we should let our editors know, not to do that).

[elondaits]

The image was converted into base64, which is a scheme that lets you convert a binary file into a text representation that uses only letters and numbers (it's the way in which images and other binaries were transferred through text-only media in the past, such as usenet, text terminals, etc.)

Once you have the image in base64 you can put it in the src attribute of an img HTML element instead of an URL:

<img alt="Embedded Image" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADIA..." />

That's the way it was loaded. I don't know if one of the tools in the editor facilitates it, if it was brought in through copy+paste or how. It's not the greatest idea in the world because it gets binary images in the database instead of storing them as files.