Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Fuel 2.0

  • Hi,

    Just out of my curiosity.
    What where the reason why Fuel 2.0 was abandoned ?
    Seemed right the right direction back in the days...

    Traditionally, anything going on about the successor ?
  • Quite simple:

    by 2014 there was only Uru and myself. He moved on to a non-php job, and I suffered from quite serious brain damage, from which I am only very slowly recovering. One of the problems I still have is poor memory, which means I have to code with the manual besides me, as I can't remember syntax very well. And mental activity tires me very quickly, so I can't do much in a day.

    I used the good days, together with the devs in my company, to make sure the code remained maintained, and compatible with current PHP versions, so current dev runs fine on PHP 8.

    As to 2.0:

    At the time there was a strong movement towards isolation and testability. While all very fine, as the work got on, I more and more started to realise that it was slowing becoming a Symfony / Laravel style monster, and that is not why people select Fuel. They select it because it is small, simple and easy to understand. And with the above happening, everything grinded to a halt.

    I am still committed to Fuel (otherwise we wouldn't have maintained it) and Fuel is still the framework of choice of my company, and we have quite a few apps in development and maintenance, one already since 2011. Started on PHP 5.3.3, now runs on PHP 8, no problem.

    When my health improves further, I would like to start working on it again. But more with a practical focus.

    The original 2.0 architecture was basically a completely new design, which would have caused a problem for existing applications and their continuity: how long to maintain two frameworks?

    Instead, I would like to redesign and upgrade Fuel more organically, so only one codebase has to be maintained, and users can upgrade to newer versions without (much) impact to existing applications. Even if they are 10 years old.

    A few things we (as a Fuel dev company) would like to do:
    - replace the autoloader with a PSR4 loader
    - merge modules and packages into PSR4 loadable components
    - replace the underscore by a namespace ( \Controller\Welcome instead of Controller_Welcome)
    - simplify the request/response flow code
    - introduce a root namespace for the app (to not contaminate the namespace root)
    - split result rendering from the controller code (return data only, render based on requirements)
    - OpenAPI support
    - lift the PHP requirement to 7.4 / 8.0 (depending on timing)
    - implement strict / typing
    - better tesability and code coverage for the framework code

  • I used to be very interested in version 2, but gradually I lost this interest for the following reasons:
    Everything I need is done right now (based on my usage and knowledge and comparison with other frameworks, until recently Laravel didn't even have a
    temporal model)
    Better customer support and faster code development
    Stable framework and avoidance of stupid changes and behaviors in other frameworks.
    Easy training of new employees (all use the same framework and version for several years)
    High cost support and development of older versions that we do not have.

    To hire a programmer in other frameworks, the version of the framework must be mentioned !!
    fuelphp is very fast.

    I think small changes are better than changing the whole framework and in version 2 these changes are inevitable and have a lot of time and cost for everyone.
  • I agree with all of that. :-)
  • @HarroVerton, from what I understand there is a version of FuelPHP that works on PHP8? Did you share it somewhere already?
  • We run 1.9/dev internally on PHP8 for all our development projects.

    There is a release update in the planning, but no date yet as there are a few potential ORM issues still to sort out...

  • Thank you for the information. We will review 1.9/dev soon internally as well. I wish you good health.
  • @Harro, we have checked 1.9/dev but it seems migrations do not work properly. We have switched to dev-1.9/develop in composer.json:

    "fuel/core": "dev-1.9/develop",
            "fuel/auth": "dev-1.9/develop",
            "fuel/email": "dev-1.9/develop",
            "fuel/oil": "dev-1.9/develop",
            "fuel/orm": "dev-1.9/develop",
            "fuel/parser": "dev-1.9/develop",

    But php oil r migration:fresh returns an error:
    Uncaught exception Fuel\Core\FuelException: 0 - Migration class "Fuel\Migrations\Currency" must include public methods "up" and "down" in /var/www/platform/fuel/core/classes/migrate.php on line 489

    It seems it is related to PHP8 change:
    The ability to call non-static methods statically has been removed. Thus is_callable() will fail when checking for a non-static method with a classname (must check with an object instance).

    So if I change the code to, for example:
    if ( ! is_callable(array(new $class, 'up')) or ! is_callable(array(new $class, 'down')))

    It works. How did you manage to do migrations on PHP8 without this change on 1.9/develop? Is there something I am missing?
  • A migration has always required to have both and up() and down() method, it is not related to PHP8.

    It is not complaining about is_callable(), it is complaining that you have a migratin without (probably) a down() method.

    We run migrations daily, and I've never seen this error.

    edit: I've checked, the Migrate class doesn't use static calls at all, it uses:

            // run the actual migration
            $class = new $class;
            $result = call_user_func(array($class, $method));

    And the methods in the migration classes themselfs are also not static.

    So double check your "Currency" migration for a missing method.
  • All our migration files have up() and down() methods. Here is how it looks: https://ibb.co/Ptp42GJ

    I am not sure why you do not have this error - maybe you have different CLI PHP version and web PHP version?

    The change I pasted is mentioned here: https://www.php.net/manual/en/migration80.incompatible.php

    The rest of the project seems to be working at first glance. Thank you for your work.
  • Our development webservers run all PHP versions, from 5.6 to 8.0, in parallel, so everything can be tested with multiple versions.

    [root@web1] $ ps -ef | grep master
    root  17977  1  0 Feb10 ?  00:01:27 php-fpm: master process (/etc/opt/remi/php56/php-fpm.conf)
    root  18081  1  0 Feb10 ?  00:01:26 php-fpm: master process (/etc/opt/remi/php70/php-fpm.conf)
    root  18091  1  0 Feb10 ?  00:01:27 php-fpm: master process (/etc/opt/remi/php71/php-fpm.conf)
    root  18101  1  0 Feb10 ?  00:01:27 php-fpm: master process (/etc/opt/remi/php72/php-fpm.conf)
    root  18111  1  0 Feb10 ?  00:01:27 php-fpm: master process (/etc/opt/remi/php73/php-fpm.conf)
    root  18121  1  0 Feb10 ?  00:01:25 php-fpm: master process (/etc/opt/remi/php74/php-fpm.conf)
    root  18131  1  0 Feb10 ?  00:01:30 php-fpm: master process (/etc/opt/remi/php80/php-fpm.conf)

    The current PHP 8.0 version running is:

    [root@web1] $ module load php80
    [root@web1] $ php -v
    PHP 8.0.1 (cli) (built: Jan  5 2021 13:54:54) ( NTS gcc x86_64 )
    Copyright (c) The PHP Group
    Zend Engine v4.0.1, Copyright (c) Zend Technologies
        with Zend OPcache v8.0.1, Copyright (c), by Zend Technologies

  • Sorry, I have to take my words back.

    I've checked our local Fuel masters, and for fuel/core:

    [root@dev] $ git status
    On branch 1.9/develop
    Your branch is up to date with 'origin/1.9/develop'.
     
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git restore <file>..." to discard changes in working directory)
        modified:   classes/finder.php
        modified:   classes/migrate.php
        modified:   classes/package.php


    So we have local fixes that someone made but not committed (which also means they aren't synced with github.

    I'll check them now, push them, and then check who I need to cover in tar and feathers....
  • That's very good news. Looking forward.
  • Update pushed.
  • Thank you, works like a charm. If we find anything else, we will open issues directly on GitHub.
  • Thanks, much appreciated.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion