Project for issues affecting the CreateWiki extension.
Mon, Jul 19
Sat, Jul 17
Thu, Jul 15
Can you please tell me what actions led up to receiving this error?
Mon, Jul 12
Sun, Jul 4
htmlspecialchars( "The database name doesn't end in a valid suffix (e.g. 'wiki').", ENT_QUOTES, 'UTF-8', false );
works, which tells me it has nothing to do with wfMessage()->escaped() as that's basically exactly what Message::escaped() uses when you go back to the source. Also using wfMessage( 'createwiki-error-notsuffixed' )->escaped(); directly in eval.php seems to work as well. (returns the correct escaped output)
As far as I see this had nothing to do with the recent changes. The "notsuffixed" message wasn't even touched/used in change.
Sat, Jul 3
I had Redis issues on an import last night
It's happened again in this wiki request. No farmer log creation log entry created, but the user's bureaucrat and sysop rights were added. Main Page was created, but still we have Exception experienced creating the wiki. Error is: Redis server error: socket error on read socket. I agree with @Void above that while the lack of a farmer log entry is relatively minor (we should be able to manually add these via the database as they occur), the fact that the CreateWiki job is not completing with full success is problematic. I suspect there's likely a communication problem or conflict of some sort between the way the CreateWiki extension/MediaWiki "talk" to the Redis server. Not sure what that problem is, but this should definitely be investigated thoroughly, tough as a nut to crack as it may be...
Fri, Jul 2
Thu, Jul 1
I guess MWException escapes the message so there's no need to use ->escaped() on the return when building the message.
Jun 30 2021
Merged fix, and modified the dbname of the affected request.
This is not really a security issue. There is validation upon attempting to create the wiki that will fail if validation fails.
The check for an initial submit is done https://github.com/miraheze/CreateWiki/blob/master/includes/RequestWiki/SpecialRequestWiki.php#L121 but when editing the form that check isn't happening.
https://github.com/miraheze/CreateWiki/blob/master/includes/WikiManager.php#L253 - has a check in place for technical limitations it seems.
See https://github.com/miraheze/CreateWiki-ghsa-3p5g-25fw-r6p3 & https://github.com/miraheze/CreateWiki/security/advisories/GHSA-3p5g-25fw-r6p3 for patches if you have any
Void has also raised blacklisted subdomains etc
By definition this is a security issue. We've got missing validation with the ability to take the site partially down.
Jun 28 2021
Jun 20 2021
IMO this task is still valid, but not for the focus it has. I don't particularly care about the wiki creator statistics being accurate. But I do care about the implication that a failure in the wiki creation process leaves the wiki in an incomplete status. IMO the proper solution here is to have a wiki creation failure clear the incomplete wiki and report the issue somehow.
Reopening per private dialogue with Reception123 on IRC. Please leave this for him to close. Thanks!
As Reception said, if it didn't create successfully then it won't log.
@Reception123, this is reproducable as it has happened multiple times now. I suspect it's something to do with the way in which the updated CreateWiki extension "talks" to the now locally forked jobrunner/redis server process. As you told me privately this would definitely be looked into with a view to resolving, if you have no objections, I'd rather prefer to reopen this task, and lower its priority to low as it's a bit niche. I get that you're trying to reduce the task backlog, but as this is happening with increasing frequency and since the wiki creator statistics are based on created wiki farmer log entries, it does need to be resolved as it never happened before (i.e., late last year).
The reason why the log wasn't created was because something went wrong with the particular wiki creation, and the log entry is the last thing that's executed. Unfortunately, we can't reproduce that error or investigate it really especially since a month has passed. CreateWiki errors can happen for all kinds of reasons but they are very rare in nature but are bound to happen every once in a while because of different factors. For that reason this task should be declined as there is nothing that can be realistically done to investigate that particular issue (which isn't the log not creating in itself)
Jun 15 2021
Jun 12 2021
May 27 2021
Redis-JobRunner is additional software. It’s like saying MediaWiki is the cause of Matomo’s SSL certificate failing just because they have the same certificate - they’re entirely unrelated but confirmation bias suggests there’s a link because it’s easier to explain than an unknown cause.
Note: On this occasion, we got an actual error in the description whereas T7338 was a silent fail.