[Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Marcin Cieslak]

I am kind of late to the party but I have upgraded one of
my throaway development wikis with the usual 
"git remote update && git merge && php maintenance/update.php" process
and after the above succeeded I was nevertheless greeted by:

Fatal error:  Class 'Cdb\Reader' not found 

exception coming out of includes/cache/LocalisationCache.php on line 1263

It seems that I just forgot to update the "vendor" directory
(I am somehow reluctant to run composer due to allow_url_fopen=1)
requirement

Would that be reasonable to add some basic external libraries
checks to update.php to remind users to update those core
components prior to accessing the wiki?

Btw. I think UPGRADE doc does not (yet) mention the new process.

//Marcin


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Tyler Romeo]

I know we just added some new maintenance scripts for checking things with 
composer. I’m sure it wouldn’t be that bad having update.php check first and 
tell the user to run “composer install” before doing update.php.

-- 
Tyler Romeo
0x405D34A7C86B42DF

On January 13, 2015 at 08:07:34, Marcin Cieslak (sa...@saper.info) wrote:

I am kind of late to the party but I have upgraded one of
my throaway development wikis with the usual  
"git remote update && git merge && php maintenance/update.php" process
and after the above succeeded I was nevertheless greeted by:

Fatal error: Class 'Cdb\Reader' not found  

exception coming out of includes/cache/LocalisationCache.php on line 1263

It seems that I just forgot to update the "vendor" directory
(I am somehow reluctant to run composer due to allow_url_fopen=1)
requirement

Would that be reasonable to add some basic external libraries
checks to update.php to remind users to update those core
components prior to accessing the wiki?

Btw. I think UPGRADE doc does not (yet) mention the new process.

//Marcin


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Bryan Davis]

On Tue, Jan 13, 2015 at 7:40 AM, Tyler Romeo  wrote:
> I know we just added some new maintenance scripts for checking things with 
> composer. I’m sure it wouldn’t be that bad having update.php check first and 
> tell the user to run “composer install” before doing update.php.


Kunal made the new "checkComposerLockUpToDate.php" maintenance script
to validate $IP/vendor against the $IP/composer.json file. An end user
could either add this to their typical workflow before running
update.php or we could try to find a reasonable way to integrate the
check it performs into the update script. Checking for external
dependencies isn't the same thing at all as updating a database schema
so I'd lean towards suggesting that the new script be used separately.


> On January 13, 2015 at 08:07:34, Marcin Cieslak (sa...@saper.info) wrote:
>
> I am kind of late to the party but I have upgraded one of
> my throaway development wikis with the usual
> "git remote update && git merge && php maintenance/update.php" process
> and after the above succeeded I was nevertheless greeted by:
>
> Fatal error: Class 'Cdb\Reader' not found
>
> exception coming out of includes/cache/LocalisationCache.php on line 1263
>
> It seems that I just forgot to update the "vendor" directory
> (I am somehow reluctant to run composer due to allow_url_fopen=1)
> requirement
>
> Would that be reasonable to add some basic external libraries
> checks to update.php to remind users to update those core
> components prior to accessing the wiki?
>
> Btw. I think UPGRADE doc does not (yet) mention the new process.

I think that Kunal's thinking on this (Composer and UPGRADE) was that
when the 1.25 tarballs are released they will likely bundle the
required libraries directly and thus use of Composer will not be
needed by the end user. There is a sentence in the Git subsection of
 mentioning the
external library dependency:
> If you are upgrading to MediaWiki 1.25 or later, you will also need to 
> install some external libraries. See the documentation on that for more 
> details.

Maybe that needs a bit more emphasis on the wiki page?

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Ryan Kaldari]

This may be a dumb question, but has anyone worked on creating a web
interface for running update and maintenance scripts (and viewing
associated logs)? That would probably make the whole process less painful
and confusing for 3rd party users, especially if the interface offered some
guidance on what each script did and when it was last run.

Kaldari

On Tue, Jan 13, 2015 at 9:08 AM, Bryan Davis  wrote:

> On Tue, Jan 13, 2015 at 7:40 AM, Tyler Romeo  wrote:
> > I know we just added some new maintenance scripts for checking things
> with composer. I’m sure it wouldn’t be that bad having update.php check
> first and tell the user to run “composer install” before doing update.php.
>
>
> Kunal made the new "checkComposerLockUpToDate.php" maintenance script
> to validate $IP/vendor against the $IP/composer.json file. An end user
> could either add this to their typical workflow before running
> update.php or we could try to find a reasonable way to integrate the
> check it performs into the update script. Checking for external
> dependencies isn't the same thing at all as updating a database schema
> so I'd lean towards suggesting that the new script be used separately.
>
>
> > On January 13, 2015 at 08:07:34, Marcin Cieslak (sa...@saper.info)
> wrote:
> >
> > I am kind of late to the party but I have upgraded one of
> > my throaway development wikis with the usual
> > "git remote update && git merge && php maintenance/update.php" process
> > and after the above succeeded I was nevertheless greeted by:
> >
> > Fatal error: Class 'Cdb\Reader' not found
> >
> > exception coming out of includes/cache/LocalisationCache.php on line 1263
> >
> > It seems that I just forgot to update the "vendor" directory
> > (I am somehow reluctant to run composer due to allow_url_fopen=1)
> > requirement
> >
> > Would that be reasonable to add some basic external libraries
> > checks to update.php to remind users to update those core
> > components prior to accessing the wiki?
> >
> > Btw. I think UPGRADE doc does not (yet) mention the new process.
>
> I think that Kunal's thinking on this (Composer and UPGRADE) was that
> when the 1.25 tarballs are released they will likely bundle the
> required libraries directly and thus use of Composer will not be
> needed by the end user. There is a sentence in the Git subsection of
>  mentioning the
> external library dependency:
> > If you are upgrading to MediaWiki 1.25 or later, you will also need to
> install some external libraries. See the documentation on that for more
> details.
>
> Maybe that needs a bit more emphasis on the wiki page?
>
> Bryan
> --
> Bryan Davis  Wikimedia Foundation
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808v:415.839.6885 x6855
>
> ___
> 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] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Dmitriy Sintsov]

Isn't web interface for maintenance imposes security risk? Also web scripts
usually are time-limited while shell scripts are not. To update text status
of web scripts one has to run batches via json, which is cumbersome.
Laravel artisan (shell script) runs composer itself, why
maintenance/update.php cannot? I work with Laravel after years of previous
working with MediaWiki.
Dmitriy


On Tue, Jan 13, 2015 at 9:29 PM, Ryan Kaldari 
wrote:

> This may be a dumb question, but has anyone worked on creating a web
> interface for running update and maintenance scripts (and viewing
> associated logs)? That would probably make the whole process less painful
> and confusing for 3rd party users, especially if the interface offered some
> guidance on what each script did and when it was last run.
>
> Kaldari
>
> On Tue, Jan 13, 2015 at 9:08 AM, Bryan Davis  wrote:
>
> > On Tue, Jan 13, 2015 at 7:40 AM, Tyler Romeo 
> wrote:
> > > I know we just added some new maintenance scripts for checking things
> > with composer. I’m sure it wouldn’t be that bad having update.php check
> > first and tell the user to run “composer install” before doing
> update.php.
> >
> >
> > Kunal made the new "checkComposerLockUpToDate.php" maintenance script
> > to validate $IP/vendor against the $IP/composer.json file. An end user
> > could either add this to their typical workflow before running
> > update.php or we could try to find a reasonable way to integrate the
> > check it performs into the update script. Checking for external
> > dependencies isn't the same thing at all as updating a database schema
> > so I'd lean towards suggesting that the new script be used separately.
> >
> >
> > > On January 13, 2015 at 08:07:34, Marcin Cieslak (sa...@saper.info)
> > wrote:
> > >
> > > I am kind of late to the party but I have upgraded one of
> > > my throaway development wikis with the usual
> > > "git remote update && git merge && php maintenance/update.php" process
> > > and after the above succeeded I was nevertheless greeted by:
> > >
> > > Fatal error: Class 'Cdb\Reader' not found
> > >
> > > exception coming out of includes/cache/LocalisationCache.php on line
> 1263
> > >
> > > It seems that I just forgot to update the "vendor" directory
> > > (I am somehow reluctant to run composer due to allow_url_fopen=1)
> > > requirement
> > >
> > > Would that be reasonable to add some basic external libraries
> > > checks to update.php to remind users to update those core
> > > components prior to accessing the wiki?
> > >
> > > Btw. I think UPGRADE doc does not (yet) mention the new process.
> >
> > I think that Kunal's thinking on this (Composer and UPGRADE) was that
> > when the 1.25 tarballs are released they will likely bundle the
> > required libraries directly and thus use of Composer will not be
> > needed by the end user. There is a sentence in the Git subsection of
> >  mentioning the
> > external library dependency:
> > > If you are upgrading to MediaWiki 1.25 or later, you will also need to
> > install some external libraries. See the documentation on that for more
> > details.
> >
> > Maybe that needs a bit more emphasis on the wiki page?
> >
> > Bryan
> > --
> > Bryan Davis  Wikimedia Foundation
> > [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> > irc: bd808v:415.839.6885 x6855
> >
> > ___
> > 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Chad]

The installer can be run on an existing install and
updates will be run.

-Chad

On Tue Jan 13 2015 at 10:30:00 AM Ryan Kaldari 
wrote:

> This may be a dumb question, but has anyone worked on creating a web
> interface for running update and maintenance scripts (and viewing
> associated logs)? That would probably make the whole process less painful
> and confusing for 3rd party users, especially if the interface offered some
> guidance on what each script did and when it was last run.
>
> Kaldari
>
> On Tue, Jan 13, 2015 at 9:08 AM, Bryan Davis  wrote:
>
> > On Tue, Jan 13, 2015 at 7:40 AM, Tyler Romeo 
> wrote:
> > > I know we just added some new maintenance scripts for checking things
> > with composer. I’m sure it wouldn’t be that bad having update.php check
> > first and tell the user to run “composer install” before doing
> update.php.
> >
> >
> > Kunal made the new "checkComposerLockUpToDate.php" maintenance script
> > to validate $IP/vendor against the $IP/composer.json file. An end user
> > could either add this to their typical workflow before running
> > update.php or we could try to find a reasonable way to integrate the
> > check it performs into the update script. Checking for external
> > dependencies isn't the same thing at all as updating a database schema
> > so I'd lean towards suggesting that the new script be used separately.
> >
> >
> > > On January 13, 2015 at 08:07:34, Marcin Cieslak (sa...@saper.info)
> > wrote:
> > >
> > > I am kind of late to the party but I have upgraded one of
> > > my throaway development wikis with the usual
> > > "git remote update && git merge && php maintenance/update.php" process
> > > and after the above succeeded I was nevertheless greeted by:
> > >
> > > Fatal error: Class 'Cdb\Reader' not found
> > >
> > > exception coming out of includes/cache/LocalisationCache.php on line
> 1263
> > >
> > > It seems that I just forgot to update the "vendor" directory
> > > (I am somehow reluctant to run composer due to allow_url_fopen=1)
> > > requirement
> > >
> > > Would that be reasonable to add some basic external libraries
> > > checks to update.php to remind users to update those core
> > > components prior to accessing the wiki?
> > >
> > > Btw. I think UPGRADE doc does not (yet) mention the new process.
> >
> > I think that Kunal's thinking on this (Composer and UPGRADE) was that
> > when the 1.25 tarballs are released they will likely bundle the
> > required libraries directly and thus use of Composer will not be
> > needed by the end user. There is a sentence in the Git subsection of
> >  mentioning the
> > external library dependency:
> > > If you are upgrading to MediaWiki 1.25 or later, you will also need to
> > install some external libraries. See the documentation on that for more
> > details.
> >
> > Maybe that needs a bit more emphasis on the wiki page?
> >
> > Bryan
> > --
> > Bryan Davis  Wikimedia Foundation
> > [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> > irc: bd808v:415.839.6885 x6855
> >
> > ___
> > 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Tyler Romeo]

The relevant link: https://www.mediawiki.org/wiki/Manual:$wgUpgradeKey
-- 
Tyler Romeo
0x405D34A7C86B42DF

On January 13, 2015 at 13:36:10, Chad (innocentkil...@gmail.com) wrote:

The installer can be run on an existing install and
updates will be run.

-Chad

On Tue Jan 13 2015 at 10:30:00 AM Ryan Kaldari 
wrote:

> This may be a dumb question, but has anyone worked on creating a web
> interface for running update and maintenance scripts (and viewing
> associated logs)? That would probably make the whole process less painful
> and confusing for 3rd party users, especially if the interface offered some
> guidance on what each script did and when it was last run.
>
> Kaldari
>
> On Tue, Jan 13, 2015 at 9:08 AM, Bryan Davis  wrote:
>
> > On Tue, Jan 13, 2015 at 7:40 AM, Tyler Romeo 
> wrote:
> > > I know we just added some new maintenance scripts for checking things
> > with composer. I’m sure it wouldn’t be that bad having update.php check
> > first and tell the user to run “composer install” before doing
> update.php.
> >
> >
> > Kunal made the new "checkComposerLockUpToDate.php" maintenance script
> > to validate $IP/vendor against the $IP/composer.json file. An end user
> > could either add this to their typical workflow before running
> > update.php or we could try to find a reasonable way to integrate the
> > check it performs into the update script. Checking for external
> > dependencies isn't the same thing at all as updating a database schema
> > so I'd lean towards suggesting that the new script be used separately.
> >
> >
> > > On January 13, 2015 at 08:07:34, Marcin Cieslak (sa...@saper.info)
> > wrote:
> > >
> > > I am kind of late to the party but I have upgraded one of
> > > my throaway development wikis with the usual
> > > "git remote update && git merge && php maintenance/update.php" process
> > > and after the above succeeded I was nevertheless greeted by:
> > >
> > > Fatal error: Class 'Cdb\Reader' not found
> > >
> > > exception coming out of includes/cache/LocalisationCache.php on line
> 1263
> > >
> > > It seems that I just forgot to update the "vendor" directory
> > > (I am somehow reluctant to run composer due to allow_url_fopen=1)
> > > requirement
> > >
> > > Would that be reasonable to add some basic external libraries
> > > checks to update.php to remind users to update those core
> > > components prior to accessing the wiki?
> > >
> > > Btw. I think UPGRADE doc does not (yet) mention the new process.
> >
> > I think that Kunal's thinking on this (Composer and UPGRADE) was that
> > when the 1.25 tarballs are released they will likely bundle the
> > required libraries directly and thus use of Composer will not be
> > needed by the end user. There is a sentence in the Git subsection of
> >  mentioning the
> > external library dependency:
> > > If you are upgrading to MediaWiki 1.25 or later, you will also need to
> > install some external libraries. See the documentation on that for more
> > details.
> >
> > Maybe that needs a bit more emphasis on the wiki page?
> >
> > Bryan
> > --
> > Bryan Davis Wikimedia Foundation 
> > [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
> > irc: bd808 v:415.839.6885 x6855
> >
> > ___
> > 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

signature.asc
Description: Message signed with OpenPGP using AMPGpg
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Legoktm]

On 01/13/2015 09:08 AM, Bryan Davis wrote:
> On Tue, Jan 13, 2015 at 7:40 AM, Tyler Romeo  wrote:
>> I know we just added some new maintenance scripts for checking things with 
>> composer. I’m sure it wouldn’t be that bad having update.php check first and 
>> tell the user to run “composer install” before doing update.php.
> 
> 
> Kunal made the new "checkComposerLockUpToDate.php" maintenance script
> to validate $IP/vendor against the $IP/composer.json file. An end user
> could either add this to their typical workflow before running
> update.php or we could try to find a reasonable way to integrate the
> check it performs into the update script. Checking for external
> dependencies isn't the same thing at all as updating a database schema
> so I'd lean towards suggesting that the new script be used separately.

I tried getting update.php to run checkComposerLockUpToDate.php but it
was messy and didn't really work well, so I uploaded a patch[1] that
adjusts the intro text to recommend that you run
checkComposerLockUpToDate.php before running update.php.

[1] https://gerrit.wikimedia.org/r/#/c/185592/

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Working around composer? (Fatal error: Class 'Cdb\Reader' not found)

[Legoktm]

On 01/16/2015 05:52 PM, Legoktm wrote:
> I tried getting update.php to run checkComposerLockUpToDate.php but it
> was messy and didn't really work well, so I uploaded a patch[1] that
> adjusts the intro text to recommend that you run
> checkComposerLockUpToDate.php before running update.php.
> 
> [1] https://gerrit.wikimedia.org/r/#/c/185592/

Turns out that running maintenance scripts inside each other is actually
pretty simple (Maintenance::runChild()) so I changed my patch to have
update.php run checkComposerLockUpToDate.php before starting the upgrade
process, and it has been merged.

-- Legoktm

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l