Recent content by Chris D

I did notice some of your own resources were deleted that I believe you acquired from another developer. While you are not incorrect to recommend a greater level of scrutiny from our side, I was surprised that you agreed to take those add-ons on, only for you to later realise they had problems...

Are you referring to any developer or situation in particular?

Okay so this probably isn't the outcome @Weppa333 asked for but I think it's the right solution. Starting with Beta 6 the following has changed: We are no longer shipping the utf8.php code that provided functions including (but not limited to) utf8_substr, utf8_romanize, utf8_deaccent...

It's worth keeping in mind for literally anything. I've noticed over many years, forum admins like to exert a certain amount of control over their users. Sometimes this can be for their own good - it can benefit some communities to have things simplified. Often, however, I feel that it's just...

From a PHP perspective, it is quite similar. PHP has a long history and it hasn't always cared about what types are passed in where, and often it relied on assumptions, much like OP is suggesting, to automatically cast values to the expected value. As we can see here, that behaviour is now...

Heh, we have started discussing this code more generally in Slack just now and I just made basically the same point. The true bug here is not actually the errors that might happen if someone passes in a non-string. The bug here is people passing non-strings to it at all. Type safety as I am in...

Post separate suggestions please

Of course it's not supposed to be used on a working forum... We're a little confused by this. We are going to look into it, but very odd we've had no other reports of this and, clearly, this is also a working forum and we've not had such an issue. Do let us know if the situation changes though.

An add-on ID is required for this command but it wasn't enforced correctly.

We'd already caught the Templater change but otherwise thanks @PaulB. This has been backported to XF 2.2.16 too.

This was one of the fixed issues in the patch os all sorted.

Yes - that's the default for existing styles anyway.

The default will always be "System" because that's the most sensible default and aligns with what the user already has set in their operating system/device preferences. There is no good reason to force a user's preferences to be specifically "Light" or specifically "Dark". Whatever the "System"...

It’s not really designed to be disabled. Is there a particular issue you are running into?

Do you have a full stack trace?