[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.
[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.
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).
@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.
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.
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
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.
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 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).
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()
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.
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.
