Wedge

[Commit revision 660aa41]
Author: Nao
Date: Sun, 09 Oct 2016 23:53:23 +0200
Stats: 3 files changed; +8 (insertions), -1 (deletion)

• It's hack day for me. When logging an error, I'm now adding a small indicator if the error was possibly triggered by a search engine (for instance visiting a page that's not always accessed by humans.) (Errors.php, ManageErrors.php, Errors.template.php)

---

[Commit revision e8cb752]
Author: Nao
Date: Sun, 09 Oct 2016 23:53:42 +0200
Stats: 3 files changed; +12 (insertions), -9 (deletions)

• If a scheduled task function can't be found, try to find it without the 'scheduled_' prefix before giving up. This is mostly to keep in line with the fact that if the function is inside an object (like weobject::random_task), that prefix isn't expected/added at all. (ManageScheduledTasks.php, ScheduledTasks.php)
• Also, if a scheduled task isn't found and Wedge gives up, then at least let the admin know through the error log... (ScheduledTasks.php)
• Minor user box tweaks. (index.css)

[Commit revision 810186f]
Author: Nao
Date: Sat, 08 Oct 2016 13:56:14 +0200
Stats: 2 files changed; +2 (insertions), -2 (deletions)

• Added auto-focus on quick reply box when unfolding it. Because usually the next step is typing into that box, isn't it..? (topic.js)
• Some weird placement in the user box CSS. I dunno if this'll break something else. (index.css)

Yes, unless your file dates weren't modified.

[Commit revision 904a392]
Author: Nao
Date: Sun, 02 Oct 2016 15:41:32 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)

• Avoiding a minor error when browsing the error log and for some reason the URL wasn't recorded. Need to find out why they wouldn't, too... (ManageErrors.php)

---

[Commit revision 23cb8a3]
Author: Nao
Date: Sun, 02 Oct 2016 23:25:51 +0200
Stats: 1 file changed; +1 (insertion), -1 (deletion)

• Is this a new jQuery 3 bug..? Lazy loading of pages would now show the JavaScript code in plain view (I guess that fadeIn() now applies to all tag types, including script tags, making them get a block display style, which apparently in the latest Chromium is enough to show the code). I added a safety check for that. It works, so I won't bother with the rest. (topic.js)

Did you enable everything in the admin area, debugging section?

Testing...
Nope, no errors posting for me.
Anywhere else..? I need to know where to reproduce. ;)

I've double-checked the error_backtrace function, and it doesn't seem to be incompatible with ::get_* functions, and I've even forced a fake error (setting an int to empty string before I pass it), and the error shows up in the error log, complete with file & line number... :-/

Merged your pr, thanks.
Can you debug that new thing? ;)

I promise I'll get to it next week. This has just bern the shittiest week ever... :(

Sorry. Only need to add the connection variable before the str variable in the new function definition.

And yes I'm not using that code on my current websites sorry.

Well, MySQL added support for 4-byte UTF8, which is used mostly by new smileys. If you try to insert such a character into a regular UTF8 database, it'll be inserted as a ? (question mark). Which isn't great. Of course, it's only for those smileys.
There are two ways to fix that:
- Either catch all utf8mb4 characters at MySQL insert time, and turn them into HTML entities (which is what Elk does, so that's emanuelle's recommended solution),
- Or ensure that the database uses utf8mb4 from the start, if supported. That way, the character will only take 4 bytes in the database, rather than the length of an entity... Which, okay, is barely twice that number.

I'm not a big fan of parsing all messages for character recognition. I don't know if the array_split followed with an ord() call on all array items would be really fast. (Probably faster than a regexp, but still...)