Hi,
On the Themes web page, we say:
> Support for themes
>
> Themes are provided by third parties and the phpMyAdmin team does
> not provide any support for them, please contact original authors
> for improvements or security fixes."
But since we now host the theme repository with a related issue tracker
and ability to receive pull requests, we may want to revisit the
phrasing of this.
I'm not sure if we should continue to refer users to the original
author, or if we should encourage authors to monitor the issue tracker
on Github. Part of the problem here is that, if a theme author has their
own repository, it makes it more difficult to submit pull requests
against our repository; if a user wishes to make a change to a theme, do
they suggest it to the original author (who may be unreachable or not
interested) or directly to our themes repository.
I propose that themes should remain unsupported by the official team and
that the themes repository should be the official place to submit pull
requests or issues. If a theme author has provided their email address,
users can also contact them directly, but by maintaining our repository
as the official source, users can easily submit improvements without
having to track down the original author. Besides, we seem to do some
work updating themes anyway; it's better to do it in one place.
Therefore, the language of the themes page can be changed to:
> Support for themes
>
> Themes are provided by third parties and the phpMyAdmin team does not
> officially provide support for them. However, to maintain a
> consistent experience, bugs or suggestions can be made at the [issue
> tracker] and theme authors are encouraged to subscribe to
> notifications from this repository. [Pull requests] are also
> welcome.
Any opinions about this?
Hi,
I'm working on updating some of the themes for 4.7, but have encountered a
difficulty.
I'm looking at the mhn theme, on the Table Structure tab, at the icons
representing a primary key. This seems to me to be a style applied by the
class ic_b_primary. That class is defined in mhn.icons.css.php. I actually
want to take the grey/inactive icon from the "Action" area and use it again
as b_key.png, the indicator.
The problem for me is that ic_b_primary isn't a .png in the img directory,
so I can't just copy the file, and I'm not having any luck moving b_key in
to mhn.icons.css.php.
Anyone have a tip for me?
Thanks,
Isaac
We got this email report from a user about trouble with phpMyAdmin
4.2.12, which is the old version packaged with Debian Stable. I suppose
we should inform him that the version is no longer supported by us. Any
other thoughts about this report?
-------- Forwarded Message --------
Subject: Re: Js/AJAX Fatal Error on Linux x86_64
Date: Sat, 11 Feb 2017 21:10:13 +0100
From: Alessandro Majorino
To: Isaac Bennetch <bennetch(a)gmail.com>
I selected two table rows and clicked on edit. Then the editing page was
displayed correctly but with a warning <div> included at the bottom.
Again
Alessandro
Il 11 feb 2017 9:03 PM, "Isaac Bennetch" <bennetch(a)gmail.com
<mailto:bennetch@gmail.com>> ha scritto:
Hi Alessandro,
Could you tell us a bit about what you did before the error occurred?
What steps can I use to reproduce this?
Best wishes,
Isaac
> Hello,
> I just encountered a "JS fatal error" using phpmyadmin. Here it is
the log:
>
> {
> "exception": {
> "mode": "onerror",
> "message": "TypeError: AJAX.source is null",
> "stack": [
> {
> "line": 319,
> "func": "?",
> "context": [
> " AJAX.cache.add(",
> " data._selflink,",
> " data._scripts,",
> " data._menuHash,",
> " data._params,",
> " AJAX.source.attr('rel')",
> " );",
> " }",
> " if (data._params) {",
> "
PMA_commonParams.setAll(data._params);",
> " }"
> ],
> "filename": "ajax.js"
> }
> ],
> "useragent": "Mozilla/5.0 (X11; Linux x86_64; rv:45.0)
Gecko/20100101 Firefox/45.0",
> "name": "TypeError",
> "uri": "sql.php?target="
> },
> "script_name": "sql.php",
> "pma_version": "4.2.12deb2+deb8u2",
> "browser_name": "FIREFOX",
> "browser_version": "45.0",
> "user_os": "Linux",
> "server_software": "Apache/2.4.10 (Debian)",
> "user_agent_string": "Mozilla/5.0 (X11; Linux x86_64; rv:45.0)
Gecko/20100101 Firefox/45.0",
> "locale": "en",
> "configuration_storage": "enabled",
> "php_version": "5.6.30-0+deb8u1",
>
> current index = 1;
>
>
>
> Cheers,
>
> Alessandro
When a user does not define `$cfg['Servers'][$i]['host']` but does set
`$cfg['Servers'][$i]['connect_type'] = 'tcp';`, the default host of
'localhost' is used, forcing the connection over socket because of how
MySQL interprets the host.
Would it be helpful to detect when the user specifies 'tcp' and use a
default host of '127.0.0.1' instead of 'localhost', or is that getting to
be too much guessing about what the user wants?
