Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I have installed the Adminer Module and the additional files as per instructions.
When using Adminer, I get a generated table of MySQL tables, but:
There appears to be no CSS being applied (everything is poorly laid out)
The field names, such as labels and column headings show only as numbers
Much of the content, such as in links, displays as question marks
I have used Adminer (installed in AMMPS, for example) and everything is fine. Obviously it is an issue with running as a Drupal module.
I have tried using the latest adminer.php (4.2.1) as well as an older one (3.7.1).
Drupal is an up-to-date Drupal 7.
How do I upload a screen dump?
Mark
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | adminer-translations-fix-2452193-4.patch | 1.28 KB | morbiD |
| adminer.png | 87.43 KB | manngo |
Comments
Comment #1
ghidorah CreditAttribution: ghidorah commentedI have somewhat the same problem
Css are fine but all strings appear as numbers.
I guess there are some kind of translation file I need to put somewhere but no instructions are provided.
Comment #2
morbiD CreditAttribution: morbiD commentedYou can work around the strings-as-numbers problem by using one of the language-specific versions (cs, de, en, pl, sk) of adminer from http://sourceforge.net/projects/adminer/files/Adminer/Adminer%204.2.1/
Anyway, I've been investigating with a debugger and the problem with the multi-language version seems to be that it defines a
global $vh;variable then sets$vh = &$_SESSION["translations"];but this assignment by reference does not propagate to$GLOBALS['vh']for some reasonbecause the adminer.php file is included from within another function and doesn't have the correct scope. This means that when thelang()function tries to accessglobal $vh;in order to translate the numbers to localized strings, it is NULL and doesn't contain any translation strings.I'm not really sure what the solution is though.
Comment #3
morbiD CreditAttribution: morbiD commentedOk, this patch seems to be enough to get it working for me.
It simply detects a multi-language adminer file and then sets
$GLOBALS['vh'] = &$_SESSION['translations'];right before the adminer file gets included.One problem I can see with this is the fact that the adminer PHP file gets compiled/minified from various source files which means their compiler could potentially change
$vhto some other variable name in a future version if the source code changes significantly enough.Comment #4
morbiD CreditAttribution: morbiD commentedThe adminer compiler will actually try to preserve the variable names between versions but there's no guarantee so I made an updated patch which reads the adminer PHP code for the correct global variable name to use.
This patch also removes some whitespace that should not have been in the previous one.
Comment #5
morbiD CreditAttribution: morbiD commentedSorry for all the patches but I realised the adminer compiler could potentially include underscores in the variable name so I thought I'd better account for that.
Comment #6
geek-merlinThis patch does exactly what it announces here.
Comment #8
duozerskHey guys,
Thank you for using the module and for the report.
morbiD, thank you a lot for the patch, sorry it had to wait that long - committed.
axel.rutz, thank you for testing the patch.
Thanks
AndyB