openemr
openemr copied to clipboard
openemr
WordPress Patient Portals are really really broken
Describe the bug
All WordPress up-for-grabs demos, including 5.0.2, are broken. A 500 error occurs when trying to login to the admin area.
tbh WordPress has been broken for awhile and we need to address it now. I just tried installing the WordPress patient portal and it's not at all updated.
@sunsetsystems seems to have done some work on this -- any help is appreciated
@bradymiller This is a sad state of affairs -- this hasn't been updated since 2014 ;-;
@sunsetsystems https://community.open-emr.org/t/wordpress-as-portal-patient/12992
Also linking this to current convo that I just saw: https://community.open-emr.org/t/how-to-connect-wordpress-with-openemr/8937/30
Some of the Ninja forms are pretty broken. There is no Cartpauj PM (1.0.11 or greater) plugin anymore.
Since the onsite portal is so nice now, would it make sense to consider:
- removing wordpress portal
- removing offsite portal (@arnabnaha , are you still using this portal?)
(since neither of these have been maintained for several years)
I actually been meaning to emulate some features from WP portal that are missing from onsite.
Hi Brady,
I am only using the onsite portal. Not the wordpress or offsite...can easily remove it after jerry introduces some of the wp pprtal features to onsite.
On Sun, 31 May 2020, 14:00 Brady Miller, [email protected] wrote:
Since the onsite portal is so nice now, would it make sense to consider:
- removing wordpress portal
- removing offsite portal (@arnabnaha https://github.com/arnabnaha , are you still using this portal?) (since neither of these have been maintained for several years)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openemr/openemr/issues/3571#issuecomment-636439817, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIGOBBACNPJH6BLRWK5RFDRUIIRLANCNFSM4NNRSU2A .
It's been 5 years since I last looked at the WP Portal. Could anyone that has some experience with Onsite and WP give me some idea what features would need to be replaced in Onsite?
After having a lot of experience with WordPress, when you create a plugin, you still have to maintain that plugin as methods can break when versions of WordPress change. Since no one has really tried to keep these plugins functional over the years, I see the best way forward in this is to drop WP portal support and off-site portal support and instead create API functions that will allow clinics to create their own if they would like to.
The main thing that is maintained right now is the patient portal -- and this should be the main function that we focus on.
I am sorry, I am late to this thread. I would like to volunteer to revive the WP portal and maintain it with help from, perhaps @CraigT543 Here are some of my reasons:
- Having options is a good idea, people/companies may provide their providers/doctors several options depending on their needs, or on how much they can spend.
- I would like to have subscribers who are not necessarily my patients, who may eventually become my patients, hence I would like to continue to have that connectivity. Mainly, because I would like to educate my subscribers and if they decide to eventually request an appointment with me, they may. I am starting a practice and it will be a long time before I am able to accept insurance assignments. (the state is behind due to the pandemic) Some patients are waiting on me to take insurance as they cannot afford to pay themselves.
- I would like to offer educational newsletters and maybe videos (most likely not) on healthcare issues. These will be available to my subscribers and patients. I would the ability to have my WP site to be integrated with openemr. I could maintain them for now.
If I don't do a good job, then you can delete it. Just send me the article and video tutorials such that I can figure this stuff out!
Thanks
@bradymiller Might wanna create a news post on this on the community page since this will effect a lot of people
I was under impression that this was non-functional and not updated. I can definitely add the wordpress portal back if it is actually functional and used. Or if somebody wishes to resuscitate it, can make a branch that has wordpress code in it on most recent codebase that devs can work on.
check out this thread. I think removing it will affect at least one person.
https://community.open-emr.org/t/how-to-connect-wordpress-with-openemr/8937/20
doh, sounds like I should add it back then. I'll make a PR to add it back and then see if that user is using it that way (will be a good way to see what changes that user may of made to get things to keep working).
Hi there, I would like to help to rebuild a link between OEMR and WP. May I help at least for test ? I know both solutions (as user and admin).
I have been using it for years. I was a little late updating to 5.0.2. I did that this week and now the WordPress portal does not work. I get these errors:
2020-06-08T21:38:03-07:00 xxx [Mon Jun 08 21:38:03.496236 2020] [proxy_fcgi:error] [pid 21513:tid 140206211790592] [client xxx.xxx.xxx.x:xxx] AH01071: Got error 'PHP message: OpenEMR Error : Decryption failed authentication.', referer: https://xxx.xxx.xxx.x:xxx/openemr/interface/main/tabs/main.php?token_main=SKXnjgk40KbqabRYiRVFMB2HA5xs3bvaPHl3wvEL 2020-06-08T21:38:03-07:00 xxx [Mon Jun 08 21:38:03.496485 2020] [proxy_fcgi:error] [pid 21513:tid 140206211790592] [client xxx.xxx.xxx.x:xxxx] AH01071: Got error 'PHP message: PHP Warning: Variable passed to each() is not an array or object in /path to/openemr/interface/cmsportal/list_requests.php on line 266PHP message: PHP Warning: Variable passed to each() is not an array or object in /path to/openemr/interface/cmsportal/list_requests.php on line 267', referer: https://xxx.xxx.xxx.x:xxxx/openemr/interface/main/tabs/main.php?token_main=SKXnjgk40KbqabRYiRVFMB2HA5xs3bvaPHl3wvEL
In 5.0.1 I had similar problems and to work around I just used the older files from 5.0.0. But it looks like in 5.0.2 those old files just will not work. It looks like the issue is the authentication routine. Something is definitely not working there. I am not sure how to trace it down. Very frustrating for me because now I have to enter patient information by hand again.
I had made several modifications to the sunset patient portal in word press due to problems with Ninja. My work around was to use Michael Simpson's CFDB (https://cfdbplugin.com/). So I rewrote my webserve to use Michael Simpson's interface which works with Ninja, CF7, and my favorite, Gravity Forms. All worked well until this week. So if someone can help me with the authentication issue I will freely share what I have working.
WordPress has a very nice API now and I think it would be wise to work with the API rather than using the Sunset Portal Method. It works for now but I would not be surprised if it stops working in future iterations of WordPress.
It sounds like there may be encryption now in openemr, and that is why you may be getting the first error. The other issue may be a PHP version issue. That is when I get those errors.
I definitely am interested in helping with the WP portal option. Mostly because I have experience with the portal from my previous job, I will learn the onsite portal, and then we can compare with the WP portal. We can bring all the nice features to both the onsite portal and the WP portal (yes, I agree with the API, but I would agree with us maintaining it for ease of download and install) such that users have options.
Ok. The encryption is not an issue. The problem was that after I did the upgrade to 5.0.2 I needed to re-enter my credentials for the portal. So now the authentication error is gone. Understandable. I should have thought to look at that before.
But I still am getting this:
2020-06-09T22:41:21-07:00 xxx [Tue Jun 09 22:41:21.656654 2020] [proxy_fcgi:error] [pid 21513:tid 140206036440832] [client xxx.xxx.xxx.x:xxxx] AH01071: Got error 'PHP message: PHP Warning: Variable passed to each() is not an array or object in /my path to/openemr/interface/cmsportal/list_requests.php on line 266PHP message: PHP Warning: Variable passed to each() is not an array or object in /my path to/openemr/interface/cmsportal/list_requests.php on line 267', referer: https://xxx.xxx.xxx.x:xxxx/openemr/interface/main/tabs/main.php?token_main=OxveEgIDZesA14Hsa9Fe1LCyjZoxfPOo6pcEBJoc
This was not a problem before with same code in 5.0.1 But now in 5.0.2 it is not recognizing the information received as an array. I am looking at the Sunset Portal code and I see arrays are built in foreach loops. Looks like an arrray is being built. And it worked in 5.0.1 so I am very confused at this response.
What PHP version are you using @CraigT543 ? It's unclear if that warning should stop script cold. Something else may be going on here.
@CraigT543 @bradymiller You know, I love "beyond compare" from https://www.scootersoftware.com/ it is free to use for I think 60 days or so. You can compare your openemr bakup with your new directory and see which were the changes made. Maybe by looking at the code it will come to you what it is that needs to be fixed. I am interested in getting involved, and maintaining the WP portal with you and @Bouguy (above)
Having options is a good idea.
I would agree 100% and more. There seems to be lot of interest here.
Maybe with @Bouguy and @CraigT543's help suggest starting from scratch on WP side and use EMR as a black box with only REST interface. Also like the Mobile interface, it could be a separate and completely optional project.
@bradymiller @mdsupport @sjpadgett I was thinking (since most users probably won't use a WordPress-based portal and use the regular one instead), why don't we create this as a laminas drop-in module instead? Since we want to make things more modular I think that would be a step in the right direction. Also using REST API would help future-proof its usage.
@tywrenn Since the original WP portal was contributed, the architecture of this project has evolved significantly. The environment in which the product operates has changed even more and will continue to do so. Addition of more presentation related components to the standard project makes it costlier to implement component version updates. When you and @sjpadgett went through BS4 upgrades, both of you ended up treating each piece of code equally just because it is in the standard code base. I think core project should have more efforts directed towards medical functionality and making life of clinical users as easy as possible. MU3 has been waiting patiently for quite a while. At the same time there is big need for each specialty to have a tailored outward looking presence that can be implemented by different skill sets. Since these should be loosely linked with core product I do not see much benefit by making it a "module".
When we moved to 5.0.1 the portal failed for me. I could see that encryption was changing. But, I was able to just move over my old files using the older encryption system with crypto.php and it worked again. I think /library/crypto.php was still running in 5.0.1 so I could just replace the new cmsportal files with the old ones from 5.0.0 and it continued to work. Again in 5.0.2 the new cmsportal files did not sync with sunsetportal just like with 5.0.1. So, I used the exact same files that were working for me from 5.0.0. But because crypto.php was taken out for 5.0.2 and now cmsportal is a complete fail with the new encryption.
I have been putting back some of the pieces of the old encryption system and little by little I am getting rid of errors related to credentials and file sync. Now I have new errors indicating that I do not have all the configuration pieces in. For example the old decryption routine that was in c_document.class.php is now missing and I can add that. We will see. Could it be that the new encryption routine was not fully implemented in CMS portal for 5.0.1 or 5.0.2? I can see that efforts were made to transition it in to the new system but was it tested? It never worked for me and it is not working for me now. Because when I use the new system for some reason I get the "Variable passed to each() is not an array or object" on lines 266 and 267 of list_requests.php. That did not happen in 5.0.1 if I used my files from 5.0.0 and the only change between the two is removal of the routine for crypto.php. It seems that the new encryption method was never fully worked out for the cmsportal because it was assumed to be dead (understandable). But not dead to me.
Yes, I agree, It would be good if it remains included. My server is currently down. As soon as I fix it this weekend, I could help some.
I was not successful in getting crypto.php to function with 5.0.2. So, the handshake is not taking place between the list_requests.php in openemr and webserve.php in the sunset portal. The error log tells me I have a probable configuration error. I am likely missing some dependency for crypto.php to work. And I am also certain that the webserve application for the sunset portal is not set up to receive the csrf_token_form in the new method. So the alternate option is to rewrite the webserve to accept the csrf token in the new routine. I am not sure where to start there yet.
hi @CraigT543 , Just submitted a PR with all the wordpress portal code in it on OpenEMR's most recent development codebase: https://github.com/openemr/openemr/pull/3639
Are your encryption/decryption issues in the interface/cmsportal/upload_form.php script?
No the file that initiates the connection in OpenEMR is portal.inc.php with webserve.php in Wordpress. As far as I can tell, portal.inc.php does a little cURL handshake with webserve.php and list_request.php grabs an array from webserve.php of all forms and messages that are on the wordpress site. I am pretty sure it all is initiated with portal.inc.php.
hi @CraigT543, Are you seeing errors in the handshake? https://github.com/openemr/openemr/blob/daf9411666edafdfe3f3486c8fb3278dc9fd78f7/interface/cmsportal/portal.inc.php#L40 or https://github.com/openemr/openemr/blob/daf9411666edafdfe3f3486c8fb3278dc9fd78f7/interface/cmsportal/portal.inc.php#L47
Note that the crypto call in that function is just decrypting the password that is stored in globals. So, the way to fix this would be to resave your wordpress password in globals, which will then get encrypted in database (and then correctly decrypted when collected from database).