Migrating code from Windows to Linux (Ubuntu)

question

(Jerry P) #21

try composer update first


(Brady Miller) #22

hi @juggernautsei ,

If your new classes are following PSR4 guidelines, then the classes at library/staff/src will be brought in by the autoloader automatically. Now, you can “speed” things up by doing the following command:

composer dump-autoload -o

(this adds your classes to the composer files to make the lookup faster)

You definitely do not want to run ‘composer update’ since this will update all the composer packages and dependencies (and you could potentially bring in new versions of stuff that may not work :slight_smile: ). Unless you actually add another package separately, but then you would just update that specific package.

-brady


(Brady Miller) #23

Actually,

To get your new classes to work, you do need to do the following:

composer dump-autoload -o

-brady


(Jerry P) #24

composer dump-autoload -o sometimes will not update classes correctly especially when moving code around. Plus, the whole purpose of composer is to bring in dependencies that are required to run app and therefore should not bring in unwanted artifacts, if so, the composer.json needs to be looked at. true?


(Brady Miller) #25

Hi @sjpadgett ,

Composer does 2 things (at least in my simpleton brain).

  1. Package management - This is what composer update acts upon.
  2. Autoloader - This is what composer dump-autoload -o acts upon.

So, if just adding or reorganizing classed, then the dump-autoload is all that is needed.

And if wish to update the packages/dependencies to most recent versions (as allowed by composer.json), then this is what composer update does.

See here for details and goals on this:
https://www.open-emr.org/wiki/index.php/Composer#Introduction

As discussed in the wiki page, the end goal is to have an empty vendor dir that is built during builds and/or by developers, but we are a ways from that (we do the build and maintain it in the codebase; for example, I just recently updated the smarty and phpadodb versions via composer for PHP7.2 compliance).

hopefully this makes sense(I haven’t had enough coffee today, so it’s quite possible I am making no sense :slight_smile: ),
-brady


(Jerry P) #26

No sir, Makes sense and I get it but, if composer.json is setup only to load to versions of dependencies required we should never have issue. Oh, wiki! whats that? :slight_smile: No matter, update has gotten me out of fixes like this one…thanks


(Brady Miller) #27

lol,

My guess is a composer update should not ever cause problems, but you could end up using versions of packages that are not in the OpenEMR official codebase. For example, at:


(the * at the end means it will update those versions if they exist)

Again, though, we only have several versions set like that in composer.json, so the chance of composer update causing problems is very, very, very low(ie. keep doing what you are doing :slight_smile: ).

-brady


(Jerry P) #28

Yep, probably one of us ought to go ahead and fix them to a version.


(Sherwin Gaddis) #29

I am trying to find the magic of automatically autoload. Here are the steps I took to skip down the path to autoloading without running the composer dump-autoload -o.

I created a folder in the library folder. I followed the path of the one (Billing). I named it staff/src. As in the billing folder. I created a file there and named it StaffService.php.

In the StaffService.php file I added

  namespace OpenEMR\Staff;

 class StaffService
 {
     /* Do lots of stuff here and it works on windows server after running the composer dump-autoload -o */
 }

I was sure hoping that the billing was PRS-4 compliant. I followed all the steps I could find and they coincided with a tutorial that I found also.

Alas, when I ran my code the namespace was not found because the code would freeze (stop running) until I ran the composer function to update the autoloader.

I appreciate the foregoing conversation.

As a side note, I have gotten really good at reloading the code onto the Linux box and can get back to a working spot in a couple of minutes now instead of the hour it took the first couple of times.

So, if someone could point me to where the magic happens without running the composer command please share with me.

 [Sun Mar 18 11:20:48.930083 2018] [:error] [pid 12882] [client 70.169.20.249:53352] PHP Fatal error:  Uncaught Error: Class 'OpenEMR\\Staff\\StaffService' not found in /var/www/html/mindfulemr3/interface/staff/page.php:17\nStack trace:\n#0 {main}\n  thrown in /var/www/html/mindfulemr3/interface/staff/page.php on line 17, referer: http://70.16.20.24/mindfulemr3/interface/main/tabs/main.php

The above is the error that I am getting now. In line 17 of the page.php file I have

 use OpenEMR\Staff\StaffService;

I almost feel like I need to post a repo but I don’t want to expose all this code.
To my understanding, the use command tells the system which namespace to look and find. Following the convention of the billing. The name should look in the library/staff/src folder and load the class therein.

How do I make this happen?


(Jerry P) #30

Once you run update to ensure all dependencies are in, now is a good time to use composer dump-autoload -o. If your’'re using phpstorm the IDE should let you know if the path can be found in your use statement.


(Jerry P) #31

Forgot this: Once composer is setup there really is no reason it can’t be move without running any composer commands, just as we do with OpenEMR. I think something happened in this case with the upload.


(Sherwin Gaddis) #32

Well, guys, this has been a nice exercise in learning about what composer can and cannot do and will and will not do. I have decided for the sake of time to revert back to include statements to get my production code working. Maybe in the future, I can get the composer to work like it is supposed to work but for now, I will have to abandon the composer and namespace setup to get back on schedule.


(Brady Miller) #33

Hi @juggernautsei ,
I’d be glad to take a look at this code to see why your composer is not picking up the classes.
-brady


(Sherwin Gaddis) #34

Thanks, @brady.miller. I will send you the link offline.


(Dmitri) #35

Hello,
I just have spent a weekend to try the OEMR get working on my Ubuntu 18.04.1 LTS.
You wrote:

PHP Fatal error:  Uncaught Error: Class 'OpenEMR\\Common\\Logging\\Logger'

I’ve got this error too. when I examined /services/VersionService.php,
I found there two wrong uses:

use OpenEMR\Common\Database\Connector;
use OpenEMR\Common\Logging\Logger;

though if we follows psr-4 namespace mapping and the real directory names,
we would be using

OpenEMR\Common\database\Connector
OpenEMR\Common\logging\Logger

This is reason OEMR 5.0.1 doesnot work under Ubuntu.
How to fix that? An idea is to rename directories
common/database to common/Database etc. , restart, and see logs,
though it would be nice to clean code according to log information.

Dmitri


#36

Hello
Download the Mint/Ubuntu/Debian package.

https://www.open-emr.org/wiki/index.php/OpenEMR_Downloads
I only install on Ubuntu.
Good luck


(Sherwin Gaddis) #37

I thought that I updated this thread. But I see I did not. The solution or difference that I experience between the Windows and Linux Ubuntu box was the way they each handle composer.

On my second go round with moving from Windows to Linux. I found that running composer -o as suggested by @stephenwaite in this thread Composer Updating Auto loader

This is what got the Windows copy to run on the linux box once I ran composer with the -o option.


(Dmitri) #38

Hi APerez,

Thank you for replay. the .deb package is nice. What the OEMR is going on under Ubuntu?

I’ve downloaded openemr-5.0.1.tar.gz to install in my user space, not root, in order to use IDE, etc. for troubleshooting and possible development.

Dmitri