Migrating code from Windows to Linux (Ubuntu)

OpenEMR Development
#19

Well, thank everyone for their input thus far but this is what I have found out now.

@growlingflea your suggestion is the first thing I do always no exceptions.

The composer is breaking the code.

Let me tell you how I got to that conclusion.
In the clean install that works, I started moving the code changes. One of my code changes was to the composer.json file. There was one line put in that file that is this.

        "OpenEMR\\Staff\\" : "library/staff/src"

Yes, the syntax is correct because it works on the Windows server. I added code and trying to be all studious and use namespace. I know that once lines are added composer. The command “composer update” has to be run to update the dependencies.

Once I run the update, the instance starts doing the

    PHP Fatal error:  Uncaught Error: Class 'OpenEMR\\Common\\Logging\\Logger' not found in /var/www/html/mindfulemr3/services/VersionService.php:47\nStack trace:\n#0 /var/www/html/mindfulemr3/interface/globals.php(517): OpenEMR\\Services\\VersionService->__construct()\n#1 /var/www/html/mindfulemr3/interface/main/tabs/main.php(30): require_once('/var/www/html/m...')\n#2 {main}\n  thrown in /var/www/html/mindfulemr3/services/VersionService.php on line 47, referer: http://52.35.13.101/mindfulemr3/interface/login/login.php?site=default

So I copied all the clean install files back and reset the sqlconf and everything goes back to working.

What is the proper way to update namespace using composer in Linux?

Here is more defined what was added.

    "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\\Rx\\Weno\\" : "library/weno/src",
        "OpenEMR\\Staff\\" : "library/staff/src"
     }
 },

If I don’t run the dependencies update then my code does not find the library file.

#20

I just tried below command composer dump-autoload and the system stops functioning.

#21

try composer update first

#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

#23

Actually,

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

composer dump-autoload -o

-brady

#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?

#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

#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

#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

#28

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

#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?

#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.

#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.

#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.

#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

#34

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

#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

#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.

#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