Menu

PHP 7 issues.

Help
2015-12-27
2021-09-06
  • vince-br549

    vince-br549 - 2015-12-27

    Issue 1.
    in the trunk version
    In /modules/research_assistant/ra_functions.php

            function parseMonthsToInt($month)
            {
                    switch($month){
                            case "JAN": return 01;
                            break;
                            case "FEB": return 02;
                            break;
                            case "MAR": return 03;
                            break;
                            case "APR": return 04;
                            break;
                            case "MAY": return 05;
                            break;
                            case "JUN": return 06;
                            break;
                            case "JUL": return 07;
                            break;
                            case "AUG": return 08;
                            break;
                            case "SEP": return 09;
                            break;
                            case "OCT": return 10;
                            break;
                            case "NOV": return 11;
                            break;
                            case "DEC": return 12;
                            break;
                            default: return 00;
                            break;
    
                    }
            }
    

    return 08; generates PHP Parse error:
    the leading zero should be removed from all of these return statements.

    Issue 2.
    PHP Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /var/www/html/gedview/includes/functions/functions_print.php on line 1483,

    I copied the latest functions_print.php
    (
    * @version $Id: functions_print.php 7115 2015-10-31 18:26:28Z sridharb $
    ) svn 7117.
    over on top of my "old" version of gedview.
    Seems to fix it.

    I tried a full replacement / update of gedview and got more errors than I wanted to deal with.

    PHP 7 is touted as being twice as fast as php 5.6 and taking 1/2 the memory.
    May be my imagination, but gedview does seem to be faster.
    My ged view data base has 19K persons, and I"m using postgresql.

     

    Last edit: vince-br549 2015-12-27
    • Lester Caine

      Lester Caine - 2015-12-27

      On 27/12/15 15:37, vince-br549 wrote:

      Issue 1.
      in the trunk version
      In /modules/research_assistant/ra_functions.php

          function parseMonthsToInt($month)
      

      return 08; generates PHP Parse error:
      the leading zero should be removed from all of these return statements.

      I'm not finding the function actually used anywhere, but I suspect it
      needs '' around the numbers so they appear as an element of a string in
      the formatted date. I think RA is actually using one of the other date
      packages to do this now.

      Issue 2.
      PHP Warning: preg_replace(): The /e modifier is no longer supported, use
      preg_replace_callback instead in
      /var/www/html/gedview/includes/functions/functions_print.php on line 1483,

      I copied the latest functions_print.php
      (
      * @version $Id: functions_print.php 7115 2015-10-31 18:26:28Z sridharb $
      )
      over on top of my "old" version of gedview.
      Seems to fix it.
      I thought we had all of the /e and other grep deprecated code updated in
      the current SVN version.

      I tried a full replacement / update of gedview and got more errors than
      I wanted to deal with.
      I'm stuck in the middle at the moment
      My port uses Firebird, and I can't get the 'latest' code to run fully
      until I can complete reworking PDO to handle the SQL differences. My
      ADOdb based version runs fine even on PHP7 so I'm not sure it's worth my
      time ... but I'll through a bit more time at it first.

      PHP 7 is touted as being twice as fast as php 5.6 and taking 1/2 the memory.
      May be my imagination, but gedview does seem to be faster.
      My ged view data base has 19K persons, and I"m using postgresql.

      I'm not seeing a substantial speed increase on applications that are
      using multiple files across multiple directories such as PGV. Only when
      running code is it quicker and it needs the opcache running as well,
      which only works well if you are not looking up lots of dynamic data
      from databases :)

      --
      Lester Caine - G8HFL


      Contact - http://lsces.co.uk/wiki/?page=contact
      L.S.Caine Electronic Services - http://lsces.co.uk
      EnquirySolve - http://enquirysolve.com/
      Model Engineers Digital Workshop - http://medw.co.uk
      Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

       
      • vince-br549

        vince-br549 - 2015-12-27

        re: adding " around the returns, the name of the function is parseMonthsToInt,
        so my understanding is just remove the leading zeros. I don't consider myself a PHP expert by any streatch but....
        return 8;
        returns int value of 8. which was the point of the function.
        where return "08"; returns a string, ahh but then PHP will handle it just fine.

        I enabled opcache, so maybe that explains my perception of speed boost.

        your post mingled with mine, was confused as to which were your comments and which were mine.

        --
        Vince

         
        • Lester Caine

          Lester Caine - 2015-12-27

          On 27/12/15 20:13, vince-br549 wrote:

          your post mingled with mine, was confused as to which were your comments
          and which were mine.

          I forget that SF mangles quoting ... about time there was a real
          standard for messaging and one that does not use html to mess things
          further ...

          You are right about the 'int' ... I've been playing with code that
          unmangles UK and American dates today and some routines complain if the
          month is not supplied as two characters :(

          I'm fighting another problem at the moment as the 'getInstance' is not
          returning a class but just an array of data and I can't see at the
          moment how it ever worked as there is no 'new' call in any of the code
          I'm looking through ...

          --
          Lester Caine - G8HFL


          Contact - http://lsces.co.uk/wiki/?page=contact
          L.S.Caine Electronic Services - http://lsces.co.uk
          EnquirySolve - http://enquirysolve.com/
          Model Engineers Digital Workshop - http://medw.co.uk
          Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

           
          • Lester Caine

            Lester Caine - 2015-12-27

            On 27/12/15 21:20, Lester Caine wrote:

            I'm fighting another problem at the moment as the 'getInstance' is not
            returning a class but just an array of data and I can't see at the
            moment how it ever worked as there is no 'new' call in any of the code
            I'm looking through ...

            Bugger I hate PDO ... it's returning the 'INDI' as 'INDI ' add an extra
            'trim' and everything bust into life!

            --
            Lester Caine - G8HFL


            Contact - http://lsces.co.uk/wiki/?page=contact
            L.S.Caine Electronic Services - http://lsces.co.uk
            EnquirySolve - http://enquirysolve.com/
            Model Engineers Digital Workshop - http://medw.co.uk
            Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

             
  • Gerry Kroll

    Gerry Kroll - 2015-12-27

    The research_assistant module is not actively supported by anyone.

    I agree with Lester: That parseMonthsToInt function isn't used anywhere. It seems to be dead code. My vote is to remove the function or to at least comment it out. However, if it's going to remain, its code should be corrected to make PHP 7 happy. Remove those leading zeros. (My vote here: PHP 7 is dumb. What's wrong with leading zeros?)

    Which is it going to be? Let me know, and I'll update SVN accordingly.

    @vince-br59:
    Don't pick-and-choose what you're going to run under PHP 7. There were other occurrences of the preg_replace function with the /e modifier.

    You need to use the entire SVN package, but remove/delete the modules you're not going to use. My site is quite happy with just the following modules: GEDFact_assistant, JWplayer, lightbox, slideshow.

     

    Last edit: Gerry Kroll 2015-12-28
    • vince-br549

      vince-br549 - 2015-12-27

      my undrstanding is leading zeros means it is an octal value, hence the error
      since there is no such octal value as 08. guessing PHP 7 reads entire file and tried to cache it, thus found the offending 08.

      Being new here, where would you like me to post my php 7 results, if at all :)
      I just added some more to the help forum

       
  • vince-br549

    vince-br549 - 2015-12-27

    OK deleted research assistant code. wasn't in my old version.

     
  • vince-br549

    vince-br549 - 2015-12-27

    getting wordy, i am. was reading a huge book on php. they suggest never ending a php file
    with
    ?>
    to prevent accidentle blank lines from mucking up the works when creating html.
    tnx for listening

     
  • Gerry Kroll

    Gerry Kroll - 2015-12-28

    Yes, that leading zero indicating an octal value makes a lot of sense. That's the case in other programming languages too.

    I'll update SVN to remove the leading zeros and also to comment out that apparently unused function.

     
  • Gerry Kroll

    Gerry Kroll - 2015-12-28

    OK, SVN 7118 contains the corrected use of the leading zero in that research_assistant function. It also comments-out that same function, since it's apparently not used.

     
  • Gerry Kroll

    Gerry Kroll - 2015-12-28

    @vince-br59:
    What alternative does that all-knowing book of yours recommend?

    We already know that blank lines preceding or following PHP code can have undesirable effects, and everybody doing work on PhpGedView (i.e., Lester and me) is careful about that. Don't forget also that Byte Order Marks (BOM), when present in PHP scripts, produce very strange and undesirable results. We're equally careful about this.

     
    • vince-br549

      vince-br549 - 2015-12-28

      The book is:

      Title:
      Modern PHP
      By:
      Josh Lockhart
      Publisher:
      O'Reilly Media
      Formats:

          Print Ebook Safari Books Online
      

      Print:
      February 2015
      Ebook:
      February 2015
      Pages:
      268
      Print ISBN:
      978-1-4919-0501-2
      | ISBN 10:
      1-4919-0501-8

      Chapter 3: Standards PSR-2: Basic Code Style
      on page 41.

      See
      item 2.2 on
      ([http://www.php-fig.org/psr/psr-2/])

      Surprised me, it did.
      I'm in trouble, using tabs.
      I use eclipse for php coding, turns out it has the option to
      use the psr-2 format
      window->preferences->PHP->Formater active profile.

      --
      Vince

       

      Last edit: vince-br549 2015-12-28
  • Gerry Kroll

    Gerry Kroll - 2015-12-28

    PhpGedView scripts use tabs extensively. What do you mean when you say they're causing you trouble? Your editor should be able to treat tabs as if they were a string of blanks. Generally, each tab in PhpGedView code is equivalent to 4 spaces.

    That last URL you posted is just ONE project's opinion. PhpGedView precedes that project by a good many years. Having said that, I do agree that when a project is launched, coding style standards should be the first order of business if the project is to succeed as a collaborative effort.

     
    • vince-br549

      vince-br549 - 2015-12-28

      Sorry, the use of tabs was not causing me trouble in phpgedview. when I said I was in trouble, it was because I was not following any of the PSR standards. My formal education dates to pre 1970. Don't recall ever hearing anything about coding style in class. It did seem to make a lot of sense to eliminate the trailing ?> which is where this discussion began.

      Agreed, codeing style is, at least for me, a personel choice. These book authors, and you folks have much more experience and skill than me, I'm trying to learn and figured I could benefit from these folks, and yours! For me, I need to pick a style, and stick with it. PSR-2 since published, seems a place to land.

      --
      Vince

       
  • Lester Caine

    Lester Caine - 2015-12-28

    I totally agree ... My major objection to PSR in general is that it starts from a base of replacing al tabs with spaces. Something I object to especially since the code base for developing PHP extensions IS still tab based. I'd poste another mone about PSR but it's not appeared here. I'll repost if SF has not let it through later.

    Vince ... I'm Eclipse based and have been for years and I make sure any PSR rules are removed from the mix :)

     
  • Lester Caine

    Lester Caine - 2015-12-28

    Vince ... basically PGV does not follow PSR2 rules, prefering a more tradtional coding style, so you will find things like replacing a single tab with 4 spaces which the PSR2 style corrector in Eclipse will implement and moving the opening brace to the next line down in some coding elements will make comparisons with the PGV code base difficult.
    With regards the closing ?>, I've just checked and I don't think PSR actually demands it! It would be in PSR1 if anywhere but that just documents the dropping of the <? opening short tag, so your book is actually creating rules that do not exist ;)

    For easy working with PGV and some related projects, 'PHP Convention' setting in Eclipse is top of the list for good reason ... Zend is second but shows the much more vertically expanded format that 'modern' styles seem to prefer but is not something I find any reason to change to.

     
  • Gerry Kroll

    Gerry Kroll - 2015-12-28

    I wrote my first program over 50 years ago, and have developed my personal style over those many years. If I'm modifying someone else's code, I try to follow whatever style the original author used.

    Let's not worry about coding styles. Use whatever works for you. It's far more important to produce code that is free of bugs.

     
  • Stefan Lejon

    Stefan Lejon - 2021-09-06

    Which version should be used with php7?

     
  • Gerry Kroll

    Gerry Kroll - 2021-09-06

    You should always use the most recent "SVN" version that you download by clicking the "download snapshot" link on this page:
    https://sourceforge.net/p/phpgedview/svn/HEAD/tree/trunk/phpGedView/

    This version is known to work with all versions of PHP from 5.3 right through to 7.4. I understand that it also works with PHP 8, but I haven't personally tried that.

     

    Last edit: Gerry Kroll 2021-09-06

Log in to post a comment.