Mon, Aug 3
Sun, Aug 2
It would also be a good way to avoid issues like T5827.
Adding subscriber per request on Discord
Latest stable version from 2013. No updates to the code whatsoever since 2018. Unmaintained.
Sat, Aug 1
The issue described here has now been resolved and the backlog has been cleared. As an actionable T5994 has been created and therefore the discussion for how to prevent this from happening again can be taken over there.
Fri, Jul 31
@RobLa: I'll talk to @Southparkfan about how we don't get here again but it looks to be just a case of bringing the backlog under control now.
I learned a lot via DM about the not-quite-outage. The most interesting theory I've heard (and I *think* that @RhinosF1 gets credit for this) is that the job for updating global user pages is dying for some reason. However, it could be that something other process (which is trying to be helpful) is killing those processes.
my runJobs script was accidently on mw7 but load looks fine so I'm leaving it there to avoid restarting it. I'll move if it causes an issue.
A restart of jobrunner1 seems to have stopped it failing. Let's hope runJobs.php clears the backlog and it stays this way.
@RobLa its still failing... my inital guess is it may be hitting mem limits, regardless this needs immediate fix, I suggest we do manual job runs until then.
This makes me hopeful:
It's my understanding from chatting with @RhinosF1 that some of the jobs in the job queue are getting backed up. I'm pretty rusty on my MediaWiki skills, so I'm not yet familiar with with which set of jobs, and whether the problem is with something in MediaWiki core or with one of the many Miraheze custom jobs.
It's anything ran by the jobrunner
It's my understanding from chatting with @RhinosF1 that some of the jobs in the job queue are getting backed up. I'm pretty rusty on my MediaWiki skills, so I'm not yet familiar with with which set of jobs, and whether the problem is with something in MediaWiki core or with one of the many Miraheze custom jobs.
Thu, Jul 30
@Paladox, what was the reason this extension was declined as 'hard/impossible to install'?
Following an internal discussion, we thought it was sufficient to clarify what shouldn't be done and the consequences in the current pages rather than create a new policy. I have done accordingly and updated https://meta.miraheze.org/wiki/Custom_domains/Cloudflare to make it more clear what shouldn't be done and that it may result in removal.
Extension has been enabled by RhinosF1 and myself and now works globally.
Wed, Jul 29
Thank you for your help.
There are agreements in the top topic "#ライセンス変更について#許諾" of link page above.
I deleted the post of users who have not yet allowed to change the license.
Oh.sorry.
@Reiwa-Boy Could you please give us a link to the page where all the users have agreed to the license change?
Tue, Jul 28
The table needs to structured the same way, so implementing this change means we list the newest unreviewed requests first, not the oldest which is more logical.
While it could be useful to default it to that, I would like to point out that clicking on "Requested At" manually will allow you to view the most recent requests instead of the oldest.
lh3.googleusercontent.com is now whitelisted.
Mon, Jul 27
That would make tasks such as checking for duplicate requests easier.
I simply killed redis-server using pkill -9 <pid>.
Hello,
so my question is how can we now dispaly " like:
Sat, Jul 25
Can this be closed?
Fri, Jul 24
I'll also note that attempting to change the status of deletion/locking requires multiple submissions in order to go through without error. The ManageWiki page throws an error, but no actual error code or information is provided.