Composer Updating Auto loader

juggernautsei · August 15, 2018, 7:41pm

I am trying to figure out what to do about adding a new location to the psr-4 in composer.

    "psr-4" : {
        "OpenEMR\\Common\\" : "common",
        "OpenEMR\\Entities\\" : "entities",
        "OpenEMR\\Services\\" : "services",
        "OpenEMR\\Repositories\\" : "repositories",
        "OpenEMR\\Encounter\\Services\\" : "interface/patient_file/encounter/Services",
        "OpenEMR\\Admin\\" : "library/admin/src",
        "OpenEMR\\Core\\" : "library/core/src",
        "OpenEMR\\Menu\\" : "library/menu/src",
        "OpenEMR\\Calendar\\" : "library/calendar/src",
        "OpenEMR\\Sample\\" : "library/sample/src",
        "OpenEMR\\Reminder\\" : "library/reminder/src",
        "OpenEMR\\Billing\\" : "library/billing/src",
        "OpenEMR\\Pdf\\" : "library/pdf/src",
        "OpenEMR\\Tabs\\" : "library/tabs/src",
        "OpenEMR\\Rx\\Weno\\" : "library/weno/src",
        "OpenEMR\\Staff\\" : "library/staff/src"
    }

The staff folder is what I am adding. My question is do I need to run the composer update for this to be added to the autoloader?

juggernautsei · August 15, 2018, 8:20pm

I ran the sudo composer update and the namespace is not working on
ubuntu 16
PHP 7

juggernautsei · August 16, 2018, 12:23pm

I was told in another forum to run composer dump-autoload. I will have to rebuild and try again since I broke my Ubuntu install yesterday.

juggernautsei · August 16, 2018, 8:45pm

Again today every time I run the composer command, it breaks my installation.

I can copy over all my files and everything is fine until I run composer dump-autoload or it really goes south if I run composer update.

Any suggestions?

Log File:

  [Thu Aug 16 20:46:15.536502 2018] [:error] [pid 10974] [client 72.214.51.117:57926] PHP Fatal error:  Uncaught Error: Class 'OpenEMR\\Common\\Logging\\Logger' not found in /var/www/html/s/services/VersionService.php:47\nStack trace:\n#0 /var/www/html/s/interface/globals.php(522): OpenEMR\\Services\\VersionService->__construct()\n#1 /var/www/html/s/interface/login/login.php(33): require_once('/var/www/html/s...')\n#2 {main}\n  thrown in /var/www/html/s/services/VersionService.php on line 47

I have installed this 5 different times and each time I get the same results so I will ask a new question.

@stephenwaite @sjpadgett @robert.down
How do I get namespace to work without wiping out the installation?

Error log without running composer

     [Thu Aug 16 22:14:46.907060 2018] [:error] [pid 12112] [client 72.214.51.117:65484] PHP Fatal error:  Uncaught Error: Class 'OpenEMR\\Staff\\StaffService' not found in /var/www/html/t/interface/reports/payroll.php:19\nStack trace:\n#0 {main}\n  thrown in /var/www/html/t/interface/reports/payroll.php on line 19, referer: https:///t/interface/main/tabs/main.php

What I have learned is no matter which command I run. It wipes out the autoload_classmap.php and the autoload_static.php and not telling what else.

Now I have tried both commands

composer update
&
composer install

And they both whack the installation.

Side note is that this has given me more Linux how tos to live with.

stephenwaite · August 17, 2018, 2:19am

hi @juggernautsei, did you use the -o option?

https://www.open-emr.org/wiki/index.php/Composer#Update_Autoloader

brady.miller · August 17, 2018, 4:49am

Hi @juggernautsei ,

Composer does 2 separate things (at least this is how I think about it):

Third party package management (which is where composer update/install comes in)
Class autoloader (which is where composer dump-autoload comes in)

In your case, you should stay away from item 1 and focus on just item 2. If you add the OpenEMR\\Stafff\\ like you did to the composer.json and run composer dump-autoload, then OpenEMR will autoload any PSR4 compliant classes from the library/staff/src directory. If you run composer dump-autoload -o, then you are just optimizing it to make it faster (so then the autoloader uses a preloaded list of classes rather then needing to search for them in the PSR4 class directories).

hope this helps,
-brady

juggernautsei · August 17, 2018, 1:00pm

@stephenwaite No, did not use the -o option. I could not find that in the documentation. I will try that. It just interesting how it behaves so different on Linux than Windows.

Thanks @brady. Once I get the server rebuilt, I will try the -o.

juggernautsei · August 22, 2018, 3:21am

Finally got the server rebuilt and adding the -o worked out. It showed me all the dependencies that were missing that I needed to add.

Thanks @brady.miller @stephenwaite

growlingflea · May 2, 2019, 1:59am

I know that this thread has a status of “closed” but there is some missing information that I hope will be useful for others that encountered a very similar situation where the current info isn’t complete for a fix. I am a n00b at Composer so I hope this will prevent some hairpulling.

I was having a similar issue. I was able to run OpenEMR501 using php7.1 but when I was running 7.0 (the version of one of my customers) OpenEMR501 would crash. The error message I was getting was this:

My research concluded that it was because of the ability in 7.1 to use “public” for methods which isn’t allowed in 7.0. I followed the advice of Brady in another thread where in the composer file you want to specify what version of php OpenEMR is being run on. in the other case the thread was concerning php5.6. I changed the composer.json file and added the lines after “preferred-install” that specify the platform.

I went ahead and started running 7.1 from 7.0 and didn’t run into any issues

The clue that I was going to be successful was after I ran “composer update” I saw the following output:

The files that were written for 7.1 optimization were downgraded to previous versions that work on 7.0.

mdsupport · May 19, 2019, 6:32pm

Can someone please explain the reasoning behind decision to force developers to update composer every time a new (group of) class definitions is added to this project? Specifically, what are the disadvantages of not having a single entry in composer.json as

  "psr-4" : {
        "OpenEMR\\" : "library/",

brady.miller · May 20, 2019, 7:11am

Hi @mdsupport ,

No real great reasoning. There were several different developers involved in the beginning stages of the composer work and class organization. We figured since class placement is lightweight would make sense to do a reorg when we have enough classes, which I think we definitely do now. Note this issue that arose, which we would need to avoid on a reorg:
PSR-4 cannot load classes due to folder name casing · Issue #2352 · openemr/openemr · GitHub

Also would suggest definitely combining the PSR4 classes with other code. Maybe using base dir of src. Hopefully some other folks can weigh in on this.

-brady

adunsulag · May 20, 2019, 6:54pm

@mdsupport

It doesn’t make sense to me to have the different PSR-4 places. I was actually going to go ahead and refactor it all when I saw that to a single directory but I wasn’t sure if there was other code in the codebase that relied on the separate directories. I also ran into that issue #2352 about the casing on the files that will have to be addressed. Does anyone else see a reason not to combine these into a single class load?

mdsupport · May 20, 2019, 7:17pm

I would imagine even if something is using directories directly, fix would be trivial upon discovery.

Along same lines, if someone absolutely needs different case(Admin vs admin), they can selectively alias without touching anything else.

brady.miller · May 21, 2019, 8:27am

Hi,

I can’t think of a reason to not combine them all into a single class load. Would be nice to get them all into src directory and keep same namespaces (and proper capitalized directory structure). The only class that is special and is included via require_once is the one that checks for php versions (OpenEMR\Common\Compatibility\Checker class).

-brady

mdsupport · May 22, 2019, 9:55pm

Not sure if it is relevant but Smarty will be ongoing issue until it is brought to current version.

Smarty 3.1.22

Namespace support within templates
==================================
Within templates you can now use namespace specifications on:
 - Constants                like    foo\bar\FOO
 - Class names              like    foo\bar\Baz::FOO, foo\bar\Baz::$foo, foo\bar\Baz::foo()
 - PHP function names       like    foo\bar\baz()

juggernautsei · May 22, 2019, 10:11pm

Has anyone taken responsibility to bring smarty up to date?

brady.miller · May 22, 2019, 10:18pm

hi @mdsupport and @juggernautsei ,

There is a developer (same dev that added the TOTP MFA code to OpenEMR) now looking into updating Smarty2 to Smarty3. When I know more, I’ll provide another update.

-brady

brady.miller · May 22, 2019, 10:20pm

btw, here is the Issue:

(the dev just started looking into this about a week ago)

mdsupport · May 23, 2019, 12:09am

Worst case workaround for gacl would be to run it as a standalone app along lines of phpmyadmin. Calendar, on the other hand is far more crucial. SmartyBC should buy more time there.

brady.miller · May 25, 2019, 9:40am

hi @mdsupport and @adunsulag ,
Took a stab at consolidation of all the classes into 1 place here: