Add more environment variables about docker-adminer HOT 22 OPEN

@TimWolla I understand that this discussion went into the direction on plugin configuration although the original question is very broad.

I'd like to pick on the original broader question. Let me know if you rather like to discuss that in a separate issue.

With ADMINER_DEFAULT_SERVER, this repo already supports an environment variable that allows to default the server on the login interface. As this is already in place, I don't see any reason not to support configuration of default values for other parameters on the login interface via environment variables.

I already have it working locally and can provide a PR. We could then continue the discussion there.

What do you think?

from docker-adminer.

It does seem odd that you can change the default host via an environment variable, but cannot set the connection type the same way. (At the very least! The username and password would also be super convenient to set defaults for, specifically for development with docker-compose setups.)

from docker-adminer.

Solution provided here wasn't working for some reason so I used other hook to prefill login form. Otherwise the process is the same as kindly explained by the maintainer of this repository.

Dockerfile with build stages to prevent this plugin from ever making it's way to production.

ARG ADMINER

FROM adminer:${ADMINER} AS base

WORKDIR /var/www/html


FROM base AS home

COPY ./services/adminer/enabled-home/* plugins-enabled/


FROM base AS server

COPY ./services/adminer/enabled-server/* plugins-enabled/

Form prefill plugin from /enabled-home/ folder *** edit: Updated with suggested fixes *** edited again ** to fix own stupid brainfart

<?php

class LoginPrefill
{
  /** Get login form field
  * @param string
  * @param string HTML
  * @param string HTML
  * @return string
  */
  function loginFormField($name, $heading, $value) {
    $warning = '<span style="color:red; font-size: 2.2em; margin: 0 3px">*</span>';

    switch ($name) {
      case 'username':
        return $heading.$warning.$this->_fill($value, 'ADMINER_USER');
        break;

      case 'password':
        return $heading.$warning.$this->_fill($value, 'ADMINER_PASSWORD');
        break;

      case 'db':
        return $heading.$warning.$this->_fill($value, 'ADMINER_DB');
        break;
      
      default:
        return $heading . $value;
        break;
    }
  }
  

  /** Name in title and navigation
  * @return string HTML code
  */
  function name() {
    $warning = '<span style="color:red; font-size: 0.6em; margin: 0 3px">* Home env.</span>';

    return '<a href="https://www.'.$_ENV['DOMAIN'].'"'.target_blank().' id="h1">' .
      $_ENV['APP_NAME'].'</a>'.$warning;
  }


  /**
   * Fill value from environment.
   */
  private function _fill($value, $key) {
    if (strpos($value, 'value=') === false) {
      $tail = strpos($value, '>');
     $prefilled = substr_replace($value, ' value="'.htmlspecialchars($_ENV[$key]).'"', $tail, 0);
      
      // Password might hold quotes or other symbols that break formatting.
      return $prefilled;
    }

    return str_replace('value=""', 'value="'.$_ENV[$key].'"', $value);
  }
}

return new LoginPrefill();

from docker-adminer.

This is very basic functionality,

@khromov I disagree. See also this issue for a related discussion: #52 (comment) (especially the last comment).

The phpMyAdmin Docker image solves this very elegantly using env vars, why can't Adminer do the same?

One reason is that phpMyAdmin natively supports a configuration file to configure the login. Adminer does not without using plugins. Different software, different features, different use cases. Adminer aims to be simple and lightweight. phpMyAdmin is more comfortable and full-featured.

from docker-adminer.

Any chance this could be merged / released?
For dev environments with frequent restarts it is really cumbersome (and a PITA) to re-type all the stuff over and over again.

from docker-adminer.

@mlenkeit I believe your request is a duplicate of #13. I suggest to comment there if the solution I gave in there is insufficient.

from docker-adminer.

@realies What is the difference between some kind of environment variable you would need to configure manually and a file that you would need to configure manually? The Docker image even gives you a template to fill out.

Other than that I'm not even sure how a good interface using environment variables would look. Hardcoding everything for the official plugins is a non-starter for consistency reasons. Also in most cases you would need to provide arrays which are painful to provide, as you would need to encode the array structure within a flat environment variable.
Thus I conclude that adding a custom file to initialize plugins provides the best user experience. And for 99% of the plugins the default initialization using ADMINER_PLUGINS works just fine.

from docker-adminer.

@walkafwalka See #49 + linked issues.

from docker-adminer.

Though, it does feel like a tease to see that five configurations have their defaults modified. I think the same reason you chose to change these defaults align with the same reasons that these configurations should be configurable by the user via an environment variable.

My answer here would be identical to this one here, so just linking: #36 (comment)

I am not arguing for the "one more" configuration but instead for allowing the current additional configurations to not be set in stone.

They are not set in stone. There's about a thousand different ways for you to modify them. And if someone brings forward a good argument for further modification of the defaults I'm happy to include it. As an example max_input_vars was not included initially and now is since #41.

from docker-adminer.

Check #39 for a possible solution, please.

from docker-adminer.

@TimWolla, please integrate configuration variables into docker-adminer.

from docker-adminer.

@realies I'm afraid: Your comment is not actionable, as it misses critical information. What kind of configuration variables are you looking for? Why does #39 not fulfill your needs?

from docker-adminer.

Configuration variables that allow for plugin auto-configuration.

from docker-adminer.

@realies You can load your custom plugin configuration using a bind-mounted file to /var/www/html/plugins-enabled/ instead of using ADMINER_PLUGINS. Alternatively use a derived image which statically adds the configuration to the container.

A more detailed explanation is given in the README: https://github.com/docker-library/docs/tree/master/adminer#loading-plugins

from docker-adminer.

Would be nice if the official plugins are supported by the official Docker image in an automated way.

from docker-adminer.

@TimWolla What about environment variables to set upload_max_filesize, post_max_size, etc. I ended up creating my own build based on yours except with modified PHP values.

from docker-adminer.

@TimWolla Fair enough. I agree that users are always going to want one more configuration to configure.

Though, it does feel like a tease to see that five configurations have their defaults modified. I think the same reason you chose to change these defaults align with the same reasons that these configurations should be configurable by the user via an environment variable.

I am not arguing for the "one more" configuration but instead for allowing the current additional configurations to not be set in stone.

from docker-adminer.

👋 I have a similar question to the original poster - we are using Adminer with docker-compose. We have a Postgres database and would like to prefill the database type dropdown as well as username, password and database name. This is very basic functionality, I think referring to custom plugins for it without a code example diminishes the images usability a lot.

The phpMyAdmin Docker image solves this very elegantly using env vars, why can't Adminer do the same?

from docker-adminer.

@pintoflager Thank you for sharing your solution. I appreciate it.

I've reviewed it from a PHP perspective:

• You should use strpos(…) === false instead of !strpos(). The former handles 0 correctly, the latter does not. It probably doesn't matter in your case, but it is good form.
• You might want to consider using htmlspecialchars() in case one of the environment variables (e.g. the password) contains a quote (").

from docker-adminer.

Good catches and valid points. Updated to 42

from docker-adminer.

looking forward to this solution

from docker-adminer.

It does seem odd that you can change the default host via an environment variable, but cannot set the connection type the same way. (At the very least! The username and password would also be super convenient to set defaults for, specifically for development with docker-compose setups.)

Exactly my needs, found an image that helps me with those variables:
https://github.com/wodby/adminer#environment-variables

from docker-adminer.