@Freñiçh did you do any custom changes to those files on your own?
This is the commit which most likely makes trouble for you. I didn't roll it out on my installs, no time in the moment.
https://github.com/Wedge/wedge/commit/14c4ea60a02c04787834ad73ccaa86e793b3cc18
No i do not have made any custom changes.Quote from CerealGuy on September 22nd, 2016, 06:30 PM @Freñiçh did you do any custom changes to those files on your own?Yeah that comment is known by meQuote from CerealGuy on September 22nd, 2016, 06:30 PM This is the commit which most likely makes trouble for you. I didn't roll it out on my installs, no time in the moment.
https://github.com/Wedge/wedge/commit/14c4ea60a02c04787834ad73ccaa86e793b3cc18
What really makes me wonder is that you don't get any errors. Can't believe that you just can't connect to your *sql server and that's it. The changes are on the Class-DB file, but not in the connection parts.
Are you sure you uploaded all of the files in the new revision..? If you missed one, it may have triggered an incompatibility.
! Some PHP installs prefer, by default, to give you blank pages or Apache errors instead of showing you an unfinished page when errors are met. I never realized that. Putting things back to normal. At least it'll make debugging easier now... (index.php
Parse error: syntax error, unexpected 'handle_utf8mb4' (T_STRING), expecting variable (T_VARIABLE) in /usr/share/nginx/www/wedge/gz/app/Class-DB.php on line 621
return sprintf('\'%1$s\'', handle_utf8mb4(mysqli_real_escape_string($connection, $replacement)));return sprintf('\'%1$s\'', self::handle_utf8mb4(mysqli_real_escape_string($connection, $replacement)));
public static handle_utf8mb4($str)public static function handle_utf8mb4($str)Fixed untested utf8mb4 placeholder code. Note, this still doesn't support 4-byte UTF8... I still don't know exactly what I should do with those. (Class-DB.php)
Yeah, I should have split the three different changes to that file into three commits (variable renaming, function renaming and adding a placeholder for it)... sorry about that.
I'll commit it.
Took me some time to get things right,but it seems to be oké now,suppose you have not incorporated the final addition of :at: Cereal Guy ?,because i had to add this lines manually into the newest revs of Class-DB.PHP.
@Nao, Can you explain what's the problem with 4-byte UTF8?
Firefox fix for Overflow bug:
http://wedge.org/pub/bugs/8819/overflow-bug/msg297352/#msg297352
Don't ask me why this got committed too, normally I seperate all changes in different branches and let the master branch untouched. Maybe i committed this stuff once to the master branch, i don't know. Can reset my master, create a new branch and do a new pull request if you want, or you just change those two things on your own :D
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...)
Regarding Firefox, I'm on the fence. You're using hardcoded values (min-width: 49em, another one like that, and a final 'padding: 0 15px' that wasn't in the original css), it's usually bad practice for future browser versions & screen resolutions.
I'd need to test and see if I can find something better, but I'm having so many problems with Firefox in general, I'm not in a hurry.
public static function escape_string_replacement($str, $connection = null)
{
$connection = $connection === null ? self::$_db_con : $connection;
return mysqli_real_escape_string($connection, $str);
}
Didn't try it yet, but something like this should work.
Well i'm done with it,deleted the last revs and get back to a working forum before the new revs.....even media gallery give's me all kind of errors and troubles.
I'm sorry but I can not afford to have a malfunctioning forum.
Did you enable everything in the admin area, debugging section?
I promise I'll get to it next week. This has just bern the shittiest week ever... :(