PHP 7.2

Has anyone managed to get Fuel running on PHP 7.2? Mcrypt has been deprecated, and it looks in the codeigniter code that it should use OpenSSL when Mcrypt isn't available but I'm finding it to throw errors about the missing module. Not sure if it's currently unsupported?



  • It's currently not supported yet (am accepting pull requests though to help with that :)...

  • Ok cool. Thanks for the clarification :)

  • I just found out that PHP 7.2 is throwing an error with mcrypt. Any idea of when this might be corrected? Rough ETA? :)

  • Where is it throwing the error and is it FUEL specific or CI? The warnings I was seeing were mostly regarding the use of create_function.

  • Hi, new to fuel, but have used ci and ci-bonfire for years.
    Trying to install v1.4.(2) just downloaded.
    Problem is that I am setting up a new server and have just gone through upgrading to php 7.2 and all ci up to 3.1.8 and bonfire 0.8.3 and all is working well.
    My existing ci-bonfire sites are working now, but I am looking for a new CMS for basic web site - having used cms made simple for years for a particular site, but it is time to move on.
    As your code is based upon ci I thought, here is something I can use.

    Your install gives error:
    Message: count(): Parameter must be an array or an object that implements Countable

    Filename: libraries/Menu.php

    Line Number: 676
    which is no doubt due to 7,2 strict checking of parameters and your code not adhering to this. I did an initial check and the parameter is an array, however on the first pass through you return with no value .... as I have no experience with your code base I hesitate to try debug just to try the clean install.
    So question is - when will you have an updated download that is 7.2 friendly and maybe with ci 3.1.8 rather than the current 3.1.3?

  • The develop branch is currently using 3.1.7 (and will update to 3.1.8 when we can). Regarding 7.2 fixes, we've started on some but have a ways to go and at this point can give a firm date.

  • I have edited some of the fuel code to get to the point of being able to enter the cms.
    I note extensive(!) use of create_function() - this is a huge attack vector as it uses the eval() function with all the attendant risks. Seems like poor coding practice.
    I started replacing them (did two to enable loading of cms part), but the amount of work for someone that doesn't understand what is trying to be achieved and the nuances that are invisible to a new player, plus the poor maintainability of inline code makes it very time consuming, thus I have given up.
    Fuel looked really interesting and would probably meet my needs, but with no ETA I guess I will keep looking.

  • FYI there is a php 7.2 compatibility fix branch on the repo now which also includes CI 3.1.8:

  • Hi! :)

    This is great, but I've noticed a "Notice" error you might want to be aware of:

    A PHP Error was encountered<br /> Severity: Notice<br /> Message: Undefined variable: l_delim<br /> Filename: parser/Fuel_dwoo_parser.php<br /> Line Number: 117

    If this is due to my code missing something, please, let me know :)

  • edited April 2018

    This is also very weird. It seems that everything within my header view between <script> tags is looking like this:
    <script s r c = " / ass e ts / js / j q u e r y . i m a g e M as k . js ? c = " t y p e = " t e x t / j a v as c r i p t " c h a rs e t = " u t f - 8 " ></script><br /> <script >f u n c t i o n m as k I t ( $ e l e m e n t ) {

    Nothing else looks like this on the page, just the code between the <script> tags.

    Any idea what might cause this? It only started with the 7.2 compatibility fix branch.

    FYI, I did require updating to the latest branch as the host is needing to update to PHP 7.2.


  • edited April 2018

    Interesting, it's not doing it to all the pages, only the front page. Any clue what could be causing it?

    I put a <?php die(); ?> at the bottom of my footer block view file and it fixed this issue but created new issues with various tags, obviously.

  • I've fixed the $l_delim error in that branch. Regarding the spacing, what is the real HTML for that suppose to be?

  • Hi, thanks for that fix!

    Here is what the same code should look like:
    <script src="/assets/js/jquery.imageMask.js?c=" type="text/javascript" charset="utf-8"></script><script>function maskIt($element) {

  • edited April 2018

    The $l_delim warnings have been taken care of, however, this popped up next:
    A PHP Error was encountered<br /> Severity: 8192<br /> Message: The each() function is deprecated. This message will be suppressed on further calls<br /> Filename: Dwoo/Compiler.php<br /> Line Number: 3044

  • Is there an ending script tag? For the Dwoo/Compiler.php error, I'll need to probably look into updating that codebase... ugh!

  • Yes, that's just the beginning of the code. The spacing in the script ends at the </script>

  • It's fun when they decide to deprecate useful features eh? :)

  • It looks like the spacing thing happens when an error shows up. If there are no PHP errors, the script tags are shown correctly. I just need to make sure I go to the website and acknowledge the each() deprecated error once per page when I update to PHP to 7.2.

  • I'm having a tough time replicating that issue. If you change that line in the error in the Dwoo/Compiler 3044 to the following does it work:

    foreach ($map as $k => $v) {
  • Do you know how I can re-enable the suppressed deprecated errors? I couldn't find a way. I'd be happy to help if I can make them show up again.

  • Try looking at the main index.php file around line 142 where you should see the following:

    ini_set('display_errors', 1);
  • Yes, those are set. As you saw in the error message I posted earlier:

    Message: The each() function is deprecated. This message will be suppressed on further calls

    So, it doesn't look like it'll show the error to me again. I need a way to un-suppress the errors :)

  • I found that the Fuel cache was causing it so I wouldn't see the errors. I've cleared the cache and the errors re-appear. I'm going to implement your fix and make sure the errors are gone now.

  • edited April 2018

    It seems I'm still getting the same error message with the latest updates.

    Here is the code that is showing the error:
    </p> <div class="content-panel"> <div class="container fade"> <div class="row"> <?php $bottom = get_bottom_info(); ?> <div class="col-sm-12 v-center copy-section"> <?=fuel_edit($bottom['id'],'Edit this content','home')?><?=parse_template_syntax($bottom['text'])?> </div> </div> </div> </div> <p>
    Specifically the parse_template_syntax() function from the looks of it. After I eliminated all other variables.

  • Is the error message the same you listed above at the same line number (regarding each() function)?

  • Yes, that is correct, the exact same error message.

  • It's not at the same line number though since it was replaced with a foreach correct?

  • I updated the files that had been most recently modified which include:

    • /fuel/modules/fuel/libraries/parser/Fuel_dwoo_parser.php
    • /fuel/modules/fuel/libraries/Fuel_custom_fields.php

    I noticed you updated the following within the last couple days, I have not updated these yet:

    • /fuel/modules/fule/controllers/Module.php

    The error message is exactly the same from the Dwoo/Compiler.php file which hasn't been updated yet.

  • The change I recommended hasn't been pushed to the branch yet and was something I thought you could test out locally since I'm not able to replicate just yet. The code change was specified here to the Dwoo/Compiler.php file:

  • edited May 2018

    My apologies, I was expecting something different so I didn't fully read your comment. I applied that fix and with no other adjustments that error is gone.
    Thank you :)

Sign In or Register to comment.