Topic on Project:Support desk

Johnnywhy: New install fixed the problem

cuppajoelad: V.E. inserted incorrect link to page

Categories do not appear to be working on my wiki. I have a page called "Test" and I edit it and add the following line to the bottom "[[Category: Testing]]". After saving the page, the category link appears at the bottom like this: "Categories: Testing". When I click 'Testing', however, the category page contains the words "This category currently contains no pages or media." This text appears regardless of whether the 'Testing' Category page has been created or not. I have tried adding multiple pages to a category but with no luck.

MediaWiki 1.27.0

PHP 5.5.37 (cgi-fcgi)

MySQL 5.5.50-cll

Thanks in advance,

Ben

Try running the rebuildall.php maintenance script!

Thanks for the help. This seems to have built the categories correctly for existing pages and categories but I just created a new category (adding "[[Category: Testing2]]" to page "Test") and clicking through gives me the "This category currently contains no pages or media" message again. Existing categories are also not being updated if I add a new page to them.

I assume that I'm not supposed to run this script every time I create a new category or add a page to a category?

Use: https://www.mediawiki.org/w/api.php?action=query&meta=siteinfo&siprop=statistics&format=jsonfm

where replace, https://www.mediawiki.org for your own wiki name. This will show you how many "jobs" are remaining. Your updated categories will not show until the jobs have been finished.

If there are a lot of jobs left, you may have to run: php maintenance/runJobs.php

See Manual:RunJobs.php

Note that for edits that result in changes to a large number of pages (like when changing which categories a page belongs to) can cause a high number of remaining jobs.

Going to that URL gives me the following results:

{

   "batchcomplete": "",
   "query": {
       "statistics": {
           "pages": 22,
           "articles": 12,
           "edits": 207,
           "images": 3,
           "users": 3,
           "activeusers": 1,
           "admins": 3,
           "jobs": 262
       }
   }

}

There are very few pages in my wiki so it seems surprising to me that mediawiki can't cope with automatically updating categories already.

You can use the runJobs.php maintenance script to get all jobs executed in one go. This will run all the 262 jobs, which you still have open. You also can set up a cron job to regularly run that scipt, e.g. every 5 minutes or so. Categories would then be updated again no later than 5 minutes after the according edit has been saved.

Another possibility is to change the value of $wgJobRunRate in LocalSettings.php, so that more jobs get executed automatically during page views. The value, which you currently have for $wgJobRunRate, is too low for the way how you are using MediaWiki.

Thanks. I'd like category updates to take effect immediately so rather than relying on a cron job, I tried increasing the value for $wgJobRunRate to 3 (from the default which seems to be 1) but it still didn't work when I tried adding a category to a page. Btw, I am not using MediaWiki intensively at all atm, the site is not a production site and I am just testing creating, editing, and categorising pages.

Could there be a bug that means jobs are not getting processed for me at all? I didn't have any such problem with a previous version of MediaWiki (1.25.1).

You can check, if jobs are run by visiting the api.php URL, which you quoted from in one of your posts above. After you have visited a number of wiki pages without editing them, refresh the api.php result and look at the number of unfinished jobs to see, whether there is any progress.

Generally, jobs are executed one after the other in the order in which they are in the jobs table inside the database. New jobs get added to the end of that table. So, if you now add a category and it e.g. is the 264th job, then 263 jobs will have to be run before your category update happens. If you have only very few page hits, it is still possible that more new jobs get added than old jobs get run effectively producing a growing number of unfinished jobs, which will force you to wait longer and longer until they finish.

The "jobs" value of api.php is staying at 8 no matter how many times I visit pages without editing them (e.g. by clicking "Random page") so I have a feeling that $wgJobRunRate is not working properly for me. Any ideas?

The job queue i notoriously broken. There always were situations, in which it did not work correctly. And obviously with 1.27, the same problem came back in a slightly different way.

You could now figure out, what is going wrong in your case and fix this either in your environment or by opening a bugreport. At least that is what I once did - in my case it was a superfluous /bin/bash call, which made the code fail silently. And that call was not even necessary; apart from throwing a fatal error, it would have worked. That is how the job queue is...

In Manual:Job queue I documented most of the failures on the job queue, see if any of the workarounds works for you.

I've just tried setting up a fresh new wiki and still get the same issues with Categories. I cannot work out how to use Phabricator (the bug tracking system) so I cannot make a bug report. Could someone check for me whether this is a known issue please? If I cannot get job execution on page requests to work successfully, I may go back to using an old version of mediawiki. Could anyone recommend one where the job queue is known to work? Thanks in advance, Ben

Have you tried setting $wgRunJobsAsync to false?

I just set $wgRunJobsAsync to false, added a category to a page, and the page showed up in the category page straight away.  :-) Are there any serious side effects for leaving this setting in effect for a low traffic, private wiki?

With $wgRunJobsAsync set to false, if a job gets executed, you will have to wait for this job to complete, before you get the requested page returned. In case of an error during the job (e.g. a fatal error or so), the page request will be aborted as well, so that in this case, the page will not load. However, I do not really expect jobs to throw fatal errors, if the job queue itself is basically working.

I would say the most serious effect of changing this setting is that it works for you. ;-)

Excellent. Thanks a lot everyone for your help. Hopefully someone with a little more understanding of Phabricator than I will file a bug report for this issue so that it can be fixed in future versions.

And should the jobs need so long hat you don't want to wait for them, then you can still set up a cron job as detailed above.

(Thinking about it, I still think it's a bug: I mean it is nice that jobs are working for you, if run in sync with the request, but that means that they actually do get executed. And in that case, they should also be run, if the setting is to run them async. That they don't in your case, should not be that way.)

I also consider it's a bug, the current async implementation has many edge cases (there are some bugs open about it in phabricator), because doing an HTTP request to itself is not a good idea, but since WMF wikis have the on-request job run disabled this doesn't get so much attention. It works for me but maybe on some restricted environments it doesn't. Maybe the debug log would display more information about the error.

Hi,

sorry for reopening this, but I am facing the same issue after an upgrade from 1.27.1 to 1.27.4. I've tried all the methods:

• $wgRunJobsAsync = false;
• increasing $wgJobRunRate
• runJobs and rebuildall scripts

Nothing seems to work., new pages in categories are not shown.

Any other ideas?

In your .../api.php?action=query&meta=siteinfo&siprop=statistics&format=jsonfm, are there any jobs left?

the API returns 19 jobs left. If I run runJobs.php they should disappear, am I right?

They should, but the fact that they aren't, probably means that there are a few jobs that are failing which are therefore preventing rest of the jobs (like those supposed to update categories) from going through either.

When you run runJobs.php from SSH, the SSH console should output the names of the failing jobs. Those particular jobs might have to be manually deleted to allow the remaining jobs to get through.

Hi,

I run showJobs.php and it returns 0 pending jobs; the API, instead, continues to return 19 pending jobs. This is weird...

i am also experiencing this issue. 0 jobs remaining. version 1.3. Category has a page (because i created the category by putting category tag into a page). I created the category page. But, category page still shows "no pages".

Any fix? -thx

@Ciencia Al Poder@AhmadF.Cheema

What do you mean by "version 1.3"? Exactly whose version is it?

And is the "0 jobs remaining" in your .../api.php?action=query&meta=siteinfo&siprop=statistics&format=jsonfm page or through showJobs.php?

myWikiUrl/api.php?action=query&meta=siteinfo&siprop=statistics&format=jsonfm

returns:

{

    "batchcomplete": "",

    "query": {

        "statistics": {

            "pages": 3,

            "articles": 1,

            "edits": 9,

            "images": 0,

            "users": 0,

            "activeusers": 0,

            "admins": 1,

            "jobs": 0

        }

    }

}

When i try to execute showjobs.php from command shell, i get:

Could not open input file: showjobs.php

I'm running MediaWiki 1.30.0, which i downloaded from this page.

A day after creating the category, still shows "no pages".

https://www.m1a.bayviewboom.org/wiki/index.php?title=Category:Teardown

Here's the page from which the category was created:

https://www.m1a.bayviewboom.org/wiki/index.php?title=Test

i successfully ran "rebuildall.php", but Category page still not showing pages.

thx

Update: my site temporarily down. Will post back here when up.

i've reinstalled my wiki. Categories are now working. I don't know why it failed on previous install, but can close this incident.

thx

I was having an identical issue to Johnywhy, for me the solution was that the visual editor was inserting links that looked like this: [[:Category:Topic|Category:Topic]], which made it so the current page wasn't added to the category page because of this rule:

To link a category page within a page as a normal wiki link (without adding the page to the category), prefix the link name with a colon. For example: [[:Category:Not in this category

The solution for me was to go in to the source editor and make the link proper, that is, changing it to this: [[Category:Topic]]. I have also learned that one may add categories through the hamburger menu on VE.