Phpmyadmin upgrade

bradymiller wrote on Monday, May 11, 2009:

hey,
Would it be worthwhile to upgrade the phpmyadmin version? I’ve been working on UTF-8 changes and this would be helpful. So far the only openemr specific mods I’ve noted are very minor ones in the config.inc.php file. This wouldn’t be hard for me to do; just want to make sure there are no pre-sourceforge openemr mods that make an upgrade not feasible. If I did it, i’d bring it into cvs in such a way to allow easier phpmyadmin upgrades in the future.
-brady

cfapress wrote on Monday, May 11, 2009:

Sounds good to me. The only request I have is that, if possible, move the phpmyAdmin code out into it’s own folder. Currently it’s buried in <oemr>/interface/main/myadmin. Would it be better to come from the root of <emr>? Much like you did with PHPGACL.

Jason

bradymiller wrote on Monday, May 11, 2009:

To further clarify I’d upgrade to the current 2.x branch of phpmyadmin to maintain compatibility with php4.
-brady

bradymiller wrote on Monday, May 11, 2009:

Jason,
Good idea. Would also expose openemr->phpmyadmin unwanted hooks also.
-brady

sunsetsystems wrote on Monday, May 11, 2009:

Yep, upgrading phpmyadmin sounds like a good idea.  But I don’t know how much it was customized for OpenEMR.

Rod
www.sunsetsystems.com

bradymiller wrote on Tuesday, May 12, 2009:

hey,

What is the point of all the PMA_ tables in openemr (from the phpmyadmin linked_tables infrastructure)?

Don’t need them to get phpmyadmin functionality…

Especially wondering why we have the following in our sql dumpfile?
2361 – Dumping data for table `pma_bookmark`
2362 –
2363
(4 inserts here that seem to be specific to a ‘openemr’ database and a ‘openemr’ user)

If the PMA_ tables aren’t needed, should I remove them from database.sql, and turn off this functionality in our new embedded phpmyadmin (or is there a reason to keep this stuff)?

-brady

cfapress wrote on Tuesday, May 12, 2009:

Hi Brady,

Just glancing at the tables myself…

I see that pma_column_info contains the comments associated with various fields in the database. However, I’m not sure why it’s there. Whenever I create a new column in a table I make sure to include a comment but I do that in a SQL file, not in this pma_column_info table.

As for the pma_bookmark, no idea. It looks like something very specific to the phpMyAdmin interface when working with the OpenEMR database.

If you’re able to remove those tables without breaking phpMyAdmin then go for it.

Jason

bradymiller wrote on Tuesday, May 12, 2009:

hey,
They seem useless to me and are phpmyadmin specific; a user who wants these can install them into this or a separate database. I’m gonna remove them along with simplifying the phpmyadmin config file to 8 lines from several hundred. Have it working without gacl controls in openemr/phpmyadmin, but adding gacl controls brings globals.php with it which seems to conflict with the sessions of phpmyadmin. No nothing about sessions, but hopefully figure it out.
-brady

bradymiller wrote on Wednesday, May 13, 2009:

done,

  Put it in openemr/phpmyadmin. Check it out.  It’s much snazzier than our previous version (it will show up in the cvs demo this AM).  I checked it in a way that should allow easy upgrades to future versions (especially when we take the plunge to no longer support php4/mysql4). There were some session issues that arose after checking it in causing me to go through a crash course in sessions.  I’ve applied a quick fix and it is testing well, but plan to continue to revisit this after more extensive testing.

  I didn’t set up any of the pma stuff (phpmyadmin linked_tables infrastructure).  This is really just for developers it seems, can always be set up by them, and I’m guessing developers who use this will already have it set up in a separate database.  So, if nobody’s against it, I’m going to remove these 7 tables (pma_*) from our database.sql file.

  I also plan to remove the old phpmyadmin, and does this mean I can also test a removal of the globals work-around at front of globals.php file since it seems to be for the old phpmyadmin?

  This now checks phpmyadmin off the UTF-8 todo list. All that’s left is postnuke…

-brady

tmccormi wrote on Wednesday, May 13, 2009:

The pma_bookmark is where ad-hoc queries are saved so that they appear in the pull down for clients use in the Reports screen.   I find that feature to be extremely useful, however it is under designed.   I had planned on updating that feature. 

Not sure what removing it will do to the Reports menu.

Tony

bradymiller wrote on Wednesday, May 13, 2009:

hey,
Definitely won’t remove it if it’s getting used.  I won’t touch any of the pma_ tables for now; Probably just set it up in config file then so users can use the linked-tables infrastucture which is what stores information in these php_ tables (same as older phpmyadmin setup). Just realize that phpmyadmin uses the table pma_bookmarks to save queries (why the openemr database/user has been hardcoded into the row of data for each bookmark), so re-structuring or not using table properly will likely cause problems with phpmyadmin.
-brady

tmccormi wrote on Wednesday, May 13, 2009:

There are Database Design tools built into phpMyAdmin that can be used for documentation and information about references and connections between the records and tables.  It will even produce nice docs if you use these features.  We should use them… :slight_smile:

–Tony

bradymiller wrote on Thursday, May 14, 2009:

hey,
  Added the database designer tools support to the config (just as the old phpmyadmin version); note you won’t get full functionality since we don’t have the pma_designer table in there. Also have officially removed the old phpmyadmin from release; new home for phpmyadmin is openemr/phpmyadmin
-brady

bradymiller wrote on Thursday, May 14, 2009:

Also,
Here’s the wiki page with specifics of upgrade:
http://www.oemr.org/modules/wiwimod/index.php?page=PhpMyAdmin
-brady

tmccormi wrote on Friday, May 15, 2009:

Today I get this warning. …

The mbstring PHP extension was not found and you seem to be using a multibyte charset. Without the mbstring extension phpMyAdmin is unable to split strings correctly and it may result in unexpected results.

Log: Fri May 15 15:08:33 PDT 2009: Starting OpenEMR Developer Appliance startup script
Fri May 15 15:08:33 PDT 2009: Will attempt to install OpenEMR CVS version
Logging in to :pserver:anonymous@openemr.cvs.sourceforge.net:2401/cvsroot/openemr

–Tony

bradymiller wrote on Saturday, May 16, 2009:

hey,
  mbstring are php functions to deal with multibyte characters (ie. mbtrim fucntion will remove entire character (regardless of bytes) and not one byte), I’m pretty sure only pertinent to non-english languages (utf-8 encoding of english characters is 1 byte).  We’re in process of migrating to UTF-8 to broaden language support; will definitely need to deal with mbstring stuff at some point.
-brady

tmccormi wrote on Sunday, May 17, 2009:

OK, just making sure. Should be noted in the developer docs as "not a problem’ right now… :slight_smile:
–Tony

bradymiller wrote on Sunday, May 17, 2009:

hey,

this warning brings up a good point and is very related to this issue:
https://sourceforge.net/forum/forum.php?thread_id=3275391&forum_id=202506

To get internationalization in phpmyadmin/openemr, it’s quite possible we may require the mbstring multibyte functionality in php. I’m finding this encoding stuff becomes rather complicated very quickly, and has been pretty much ignored in the past.

-brady

bradymiller wrote on Sunday, May 17, 2009:

I should also add the cvs demo is based on mandriva 2006. Most of the relatively recent releases seem to include mbstring, so shouldn’t be to much of a pain if we go that route for internationalization.
-brady

sunsetsystems wrote on Tuesday, June 23, 2009:

Hey I just did an upgrade of an older CVS version of OpenEMR, and phpmyadmin is not working any more.  I get the Apache error “script ‘/var/www/login_screen.php’ not found or unable to stat”.  It’s as if it doesn’t know about $web_root.

Is there some configuration step I’m missing?

Rod
www.sunsetsystems.com