Re: [Wikitech-l] content_models table only contains wikitext content model on fresh MW 1.32.3 install
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
>
> 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 .
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 :)
--
Daniel Kinzler
Principal Software Engineer, Core Platform
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] content_models table only contains wikitext content model on fresh MW 1.32.3 install
Why don’t you use the existing import/export tools?
On Thu, Sep 19, 2019 at 8:18 AM Tom Schulze <
t.schu...@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#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?
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] content_models table only contains wikitext content model on fresh MW 1.32.3 install
> 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
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
Re: [Wikitech-l] content_models table only contains wikitext content model on fresh MW 1.32.3 install
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! -- Daniel Kinzler Principal Software Engineer, Core Platform Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
