Dear all,
for our deployment procedure we're setting up a clean database with some prefilled content. I use MW 1.32.3 for that. When I did the fresh install (minimal installation method) I realized that the 'content_models' database table only contains one row with model_id = 1 and model_name = wikitext.
I then install extensions, run update.php, and import a couple pages, templates, etc. When setting up Cargo's _pageData table using the setCargoPageData.php script at a later stage I get the following error (see backtrace at the very bottom).
Failed to access name from content_models using id = 2
I get this error fixed by inserting the core content models https://www.mediawiki.org/wiki/Content_handlers into the 'content_models' table manually. Accessing the pages afterwards works fine (Widgets in this case). The widgets themselves work fine, too.
Am I missing something that the core content models are not in the initial database table 'content_models'? Is this table not filled during the installation procedure?
Is it actually bad advice to insert the rows manually?
Kind regards and thanks for your support,
Tom
[12081d263c4cc289d8a144d8] [no req] MediaWiki\Storage\NameTableAccessException from line 42 of /var/www/mediawiki/lib/includes/Storage/NameTableAccessException.php: Failed to access name from content_models using id = 2 Backtrace: #0 /var/www/mediawiki/lib/includes/Storage/NameTableStore.php(308): MediaWiki\Storage\NameTableAccessException::newFromDetails(string, string, integer) #1 /var/www/mediawiki/lib/includes/Revision/RevisionStore.php(1625): MediaWiki\Storage\NameTableStore->getName(integer) #2 /var/www/mediawiki/lib/includes/Revision/RevisionStore.php(1671): MediaWiki\Revision\RevisionStore->loadSlotRecords(string, integer) #3 [internal function]: MediaWiki\Revision\RevisionStore->MediaWiki\Revision{closure}() #4 /var/www/mediawiki/lib/includes/Revision/RevisionSlots.php(165): call_user_func(Closure) #5 /var/www/mediawiki/lib/includes/Revision/RevisionSlots.php(107): MediaWiki\Revision\RevisionSlots->getSlots() #6 /var/www/mediawiki/lib/includes/Revision/RevisionRecord.php(192): MediaWiki\Revision\RevisionSlots->getSlot(string) #7 /var/www/mediawiki/lib/includes/Revision/RevisionRecord.php(175): MediaWiki\Revision\RevisionRecord->getSlot(string, integer, NULL) #8 /var/www/mediawiki/lib/includes/Revision.php(932): MediaWiki\Revision\RevisionRecord->getContent(string, integer, NULL) #9 /var/www/mediawiki/lib/includes/page/WikiPage.php(801): Revision->getContent(integer, NULL) #10 /var/www/mediawiki/lib/extensions/Cargo/includes/CargoPageData.php(107): WikiPage->getContent() #11 /var/www/mediawiki/lib/extensions/Cargo/maintenance/setCargoPageData.php(88): CargoPageData::storeValuesForPage(Title) #12 /var/www/mediawiki/lib/maintenance/doMaintenance.php(94): SetCargoPageData->execute() #13 /var/www/mediawiki/lib/extensions/Cargo/maintenance/setCargoPageData.php(103): require_once(string) #14 {main}
Am 18.09.19 um 16:27 schrieb Tom Schulze:
Am I missing something that the core content models are not in the initial database table 'content_models'? Is this table not filled during the installation procedure?
No. The table is filled on demand, when the first revision using that model is written to the database.
Is it actually bad advice to insert the rows manually?
Generally, yes. But adding things to that table should not do any harm. Modifying things would, however.
I then install extensions, run update.php, and import a couple pages, templates, etc. When setting up Cargo's _pageData table using the setCargoPageData.php script at a later stage I get the following error (see backtrace at the very bottom).
Failed to access name from content_models using id = 2
This implies that *something* got the ID 2 for that content model already from somewhere. That ID can really only come from an insert to the content_models table - if it's not in the table, that's an indication that it was somehow lost.
There have been reports of similar problems with the slots table. Please add your experience to the ticket here:
https://phabricator.wikimedia.org/T224949
There is a patch up that should safeguard against my best guess at the cause of this. If you can provide additional insights as to exactly how this may happen, please do!
There have been reports of similar problems with the slots table. Please add your experience to the ticket here:
https://phabricator.wikimedia.org/T224949
There is a patch up that should safeguard against my best guess at the cause of this. If you can provide additional insights as to exactly how this may happen, please do!
Thank you for your quick reply and for pointing me to the right direction. I am not sure if it's a mistake on my side, otherwise I'll gladly contribute.
I assume that the content_model id is lost/not generated somewhere between my clean MW install and the import of my templates via a script. I import pages using a custom maintenance script which reads a files' content from the file system and saves it to the mediawiki db using:
$title = Title::newFromText('Widget:MyWidget'); $wikiPage = new WikiPage( $title ); $newContent = ContentHandler::makeContent( $contentFromFile, $title ); $wikiPage->doEditContent( $newContent );
In the MW Class reference https://doc.wikimedia.org/mediawiki-core/master/php/classContentHandler.html#a2f403e52fb305523b0812f37de41622d it says "If [the modelId parameter for ContentHandler::makeContent() is] not provided, $title->getContentModel() is used." I assume, that it checks the namespace among others and uses javascript for Widgets? Because in my case it's a widget that causes the error. The extension is installed prior to the importation and the namespace 'Widget' exists.
Is there something wrong with the snippet?
Why don’t you use the existing import/export tools?
On Thu, Sep 19, 2019 at 8:18 AM Tom Schulze < t.schulze@energypedia-consult.com> wrote:
There have been reports of similar problems with the slots table. Please
add
your experience to the ticket here:
https://phabricator.wikimedia.org/T224949
There is a patch up that should safeguard against my best guess at the
cause of
this. If you can provide additional insights as to exactly how this may
happen,
please do!
Thank you for your quick reply and for pointing me to the right direction. I am not sure if it's a mistake on my side, otherwise I'll gladly contribute.
I assume that the content_model id is lost/not generated somewhere between my clean MW install and the import of my templates via a script. I import pages using a custom maintenance script which reads a files' content from the file system and saves it to the mediawiki db using:
$title = Title::newFromText('Widget:MyWidget'); $wikiPage = new WikiPage( $title ); $newContent = ContentHandler::makeContent( $contentFromFile, $title ); $wikiPage->doEditContent( $newContent );
In the MW Class reference < https://doc.wikimedia.org/mediawiki-core/master/php/classContentHandler.html...
it says "If [the modelId parameter for ContentHandler::makeContent() is] not provided, $title->getContentModel() is used." I assume, that it checks the namespace among others and uses javascript for Widgets? Because in my case it's a widget that causes the error. The extension is installed prior to the importation and the namespace 'Widget' exists.
Is there something wrong with the snippet?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Tom!
The snippet looks fine at a glance, though I wonder why you are not just using maintenance/edit.php.
Am 19.09.19 um 14:17 schrieb Tom Schulze:
I import pages using a custom maintenance script which reads a files' content from the file system and saves it to the mediawiki db using:
$title = Title::newFromText('Widget:MyWidget'); $wikiPage = new WikiPage( $title ); $newContent = ContentHandler::makeContent( $contentFromFile, $title ); $wikiPage->doEditContent( $newContent );
In the MW Class reference https://doc.wikimedia.org/mediawiki-core/master/php/classContentHandler.html#a2f403e52fb305523b0812f37de41622d it says "If [the modelId parameter for ContentHandler::makeContent() is] not provided, $title->getContentModel() is used." I assume, that it checks the namespace among others and uses javascript for Widgets? Because in my case it's a widget that causes the error. The extension is installed prior to the importation and the namespace 'Widget' exists.
So what should happen is that Title::getContentModel() decides that the default model for the Widget namespace should be javascript (based on an entry in $wgNamespaceContentModels made by the extension), and return the string "javascript".
When recording the model of the content in the content table, that string gets normalized by creating an entry in the content_models table, if no such entry exists yet for "javascript", generating a unique integer ID (in your case, this appears to be 2). This integer gets recorded in content.content_model_id.
When reading the page's content later, the model name associated with 2 is looked up in the content_models table (actually, in a cached version of that table), returning "javascript". This however fails in your case.
The question is: since the number 2 was generated by an auto-increment key when inserting into content_models, why is the row now missing from the table? How can that be?
Is there something wrong with the snippet?
Not in an obvious way.
The only explanation I have is that the edit actually fails for some reason, and the database transaction gets rolled back. This would result in a situation where the row for "javascript" is not in content_models, but it's still in the cached version of that table (in APC memory or memcached or whatever you have your object cache set to).
So perhaps you retry after the initial failure. Since the cached table has an entry for "javascript", MediaWiki will just use that, and not write to the table again. Your edit succeeds - but now you have the number 2 in content.content_model_id, but no row for 2 in the content_models table. You can still read the page as long as you have the cached version of the content_models table in memory - but as soon as the cache expires, things blow up.
As I said in my earlier response, I'm working on a patch to avoid this situation, see https://gerrit.wikimedia.org/r/c/mediawiki/core/+/514245.
However, I'm still not 100% sure that what I described above is what actually happened. Did you have some kind of failure when you first tried to import the widget (or any javascript, such as MediaWiki:common.js?)
If you didn't, I'm back to having no clue as to what might be causing this problem. Which of course would not be good at all :)
wikitech-l@lists.wikimedia.org