Le jeu. 27 août 2015 à 07:10, Michal Čihař <michal@cihar.com> a écrit :
Dne Wed, 26 Aug 2015 20:05:58 +0000
Hugues Peccatte <hugues.peccatte@gmail.com> napsal(a):

> Le mer. 26 août 2015 à 14:10, Marc Delisle <marc@infomarc.info> a écrit :
>
> > Le 2015-08-26 05:34, Hugues Peccatte a écrit :
> > > Le mar. 25 août 2015 à 15:40, Hugues Peccatte <hugues.peccatte@gmail.com
> > > <mailto:hugues.peccatte@gmail.com>> a écrit :
> > >
> > >     Le mar. 25 août 2015 à 12:06, Atul Pratap Singh
> > >     <atulpratapsingh05@gmail.com <mailto:atulpratapsingh05@gmail.com>> a
> > >     écrit :
> > >
> > >         On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte
> > >         <hugues.peccatte@gmail.com <mailto:hugues.peccatte@gmail.com>>
> > >         wrote:
> > >
> > >             Hi,
> > >
> > >             phpMyAdmin's ruleset is based on PEAR standards. One of this
> > >             standard
> > >             (PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to
> > >             name class' attributes / methods with a leading underscore
> > >             when the element is protected / private.
> > >             This rule is quite useful because it helps to see very
> > >             quickly if an element is public or not.
> > >             But http://www.php-fig.org/psr/psr-2/#4-2-properties asks
> > >             not to use this leading underscore.
> > >             For attributes, I'm not sure this is a big deal because
> > >             almost all the attributes shouldn't be visible and
> > >             accessible only by getters / setters. But for methods, there
> > >             is nothing to know the visibility of a method. However
> > >             actual IDE help to see this.
> > >
> > >             Do you think that we should follow PSR2? Only for attributes
> > >             maybe?
> > >             Should we consider to base our ruleset on another standard
> > >             closest to PSR rules?
> > >
> > >         Hi,
> > >
> > >         I agree to follow PSR-2 no underscore recommendation for
> > >         attributes and going forward we may lean more towards PSR,
> > >         specifically about achieving codebase wide autoloading of
> > >         classes(PSR-4).
> > >
> > >         Also, I
> > >         think https://github.com/phpmyadmin/phpmyadmin/pull/11365 needs
> > >         to be rebased.
> > >
> > >
> > >         --
> > >         Regards
> > >
> > >         Atul Pratap Singh
> > >
> > >
> > >     Hi,
> > >
> > >     I won't rebase the branch but remove it.
> > >     I'll see the modifications I can do to stick to PSR 0 to 2 rules.
> > >
> > >     H.
> > >
> > >
> > > Hi,
> > >
> > > Some days ago, we spoke about this code in all files:
> > > if (! defined('PHPMYADMIN')) {
> > >     exit;
> > > }
> > >
> > > In PSR, one of the rules is the "side effects" [0]. This rule says not
> > > to have class/functions/etc declaration and execution in the same file.
> > > And the code above is considered as execution. So here I don't want to
> > > restart the discussion, but we may have to change this if we really want
> > > to stick (not sure about this english word…) to PSR rules.
> > >
> > > H.
> > >
> > > [0] http://www.php-fig.org/psr/psr-1/#2-3-side-effects
> >
> > This constant verification can safely be removed if there is no other
> > "execution" code in the file.
> >
> >
> > --
> > Marc Delisle | phpMyAdmin
> >
>
> Hi,
>
> Has anyone an idea about the origin of this error please?
> https://travis-ci.org/phpmyadmin/phpmyadmin/jobs/77383289
> I don't see anything special in my modifications that can lead to this
> error…

Looks like problem with compiling runkit extension... I've changed the
code to stick with particular runkit revision which compiles fine.

--
        Michal Čihař | http://cihar.com | http://phpmyadmin.net

Thanks a not Michal, It seems to work now!

H.