hi @juggernautsei, did you use the -o option?
https://www.open-emr.org/wiki/index.php/Composer#Update_Autoloader
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/installcomes in) - Class autoloader (which is where
composer dump-autoloadcomes 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
@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.
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
1 Like
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.
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/",
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
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?
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.
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
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()
Has anyone taken responsibility to bring smarty up to date?
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
btw, here is the Issue:
(the dev just started looking into this about a week ago)
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.
I like the consolidation. If it works like it looks it will make future coding efforts a lot better. It looks like what @mdsupport was referring. So, now we will be able to drop new classes in the namespace without having to manipulate the composer. Is that the goal?
@juggernautsei Yes. You won’t have to change the composer. Just drop the classes in as long as you follow PSR-4 naming conventions.
When you use -o to dump autoload, composer will build a list of classes and functions. If you make changes to class, it would be good to re-dump autoload. We had proposed a UI for that purpose if you want to avoid going to shell.
Very nice tool you guys created. I’ll have to use this.