Remove PHPMyAdmin as a default service, replace with recipe

[rfay]

There are people that love PhpMyAdmin, but I don't think it needs to be provided by default any more (if it ever needed to be).

Remove it, replace it with a ddev get drud/phpmyadmin

• [ ] omit_containers[dba] goes away from global and project
• [ ] ddev launch -p changes probably. Or maybe it can just see if there's a possibility
• [ ] Many places reference "dba"

[rpkoller]

i agree with removing PHPMyAdmin as the default db admin interface since DDEV isn't exclusive on mysql/mariadb anymore. but it would be a reasonable step to provide more than one solution via ddev get (not just PHPMyAdmin). You've named TablePlus as an option on Discord. But for Postgres there is also an equivalent to PHPMyAdmin pgAdmin (https://www.pgadmin.org) and the most flexible solution support wise (if you deliver it with extension for all the different db systems) might be Adminer http://adminer.org . it is a single file solution. quite capable but i dislike the ui unfortunately :/ (revisited yesterday night) that is the only downside about it.

[heddn]

https://www.phpmyadmin.net/files/5.1.3/ => a new version (with security fixes) just got launched.

[rfay]

DDEV already uses the latest phpmyadmin:5 image, so people should get this just fine. But of course, please use new issues for new problems, thanks.

[bserem]

An adminer recipe is ready (https://github.com/bserem/ddev-adminer).

ps: @rpkoller it is quite easy to change the UI colors in this one, by changing a variable in the YML file, so you might find something to your liking. I do want to add the theme switcher plugin, but I need to spend more time with adminer configuration to get that right.

[rfay]

Yay, congratulations! Let me know when you want to get it promoted. I'll try it out shortly!

[bserem]

Give it a go and we can decide later.

It would be great to get it to auto-login to the database before we promote, or maybe promotion will gather more minds and we get to improve faster.

[rfay]

https://github.com/bserem/ddev-adminer/issues/1

[rfay]

I wonder what to do with this. Should we just let people use adminer if they want to? Should we just completely remove phpmyadmin and make it an addon? Do people generally need or use a web-based database browser?

[fe-hicking]

I'm +1 on removing PMA as default. I'd argue in ddev dev context you usually use CLI or Heidisql/sequelace. Shaving off a few bytes of images would be appreciated, especially if its easy to add-on.

[peterkraume]

I'd vote to remove PMA.

[heddn]

I use a tool like this a lot during development of migrations from d7 sites into drupal 9. Being able to visually display all the tables, explore the schemas is pretty useful. But it doesn't have to be a default service either.

[shochdoerfer]

+1 for removing PMA, I'd rather use the database tool integration of my PhpStorm IDE.

[mikehayesuk]

I'd be happy for it to be removed personally.

I don't see any reason for PMA to be favoured over other options. By that I mean:

• If we want to use TablePlus, we install that app and use the ddev command to launch.
• If we want to use Sequel Ace, we install that app and use the ddev command to launch.
• If we want to use PMA, we run the relevant installation / add-on command and then use the ddev command to launch.

etc.

There's no particular need for PMA to come "pre-installed" in my opinion.

[graham73may]

Me and my whole team use DDEVs PHPMyAdmin a lot. It’s just extremely helpful to have it there and ready if you just need to do something quickly. (The favourite use case is a fuzzy search across all tables at once).

It’s also helpful for the front end only developers who just prefer a nice simple interface to setup their local development site.

If it is going to be removed could there be a global config option to add it to every project by default?

I’ll be honest, I’ve not jumped in to add-ons yet (haven’t had a need so far). Im currently looking up if they are effectively just a few lines in the config.yaml.

Edit: having read this page: https://ddev.readthedocs.io/en/latest/users/extend/additional-services/

I’m not 100% on what would happen if I install an add-on, commit the ddev config. If another dev comes along and pulls, ddev starts. Do they also get the add on and everything ready to use?

Edit 2: As long as I can commit a ddev project with all its gets for the next dev ready to use then I’m sold 🙂. +1 from me!

[rfay]

@graham73may

ddev get drud/ddev-adminer (or future ddev-phpmyadmin)

Check in your .ddev directory.

You have it.

[kaystrobach]

Go for it. Maybe add a question during the first dtart wether the service should be added or not.

[bserem]

IMHO the current add-ons system is very easy to use and extend/modify. It makes sense to use it for anything outside "ddev core". I can understand that people may haven't used it yet, but it is literally one command like ddev get drud/whatever and you are good to go.

PMA is often super handy, mainly for fuzzy search like already mentioned, but it is also a beast in terms of size. People that work with the DB a lot would probably already use something else (phpstorm, dbeaver, all the other ones mentioned that I didn't know about). People who use it sparingly will be good with the addon, I guess.

Maybe a verbose message after ddev config or when running ddev describe saying "you can get a db manager with ddev get" would be handy for those who will be affected by the switch.

+1 from me to remove it

[juergen-venne]

Please remove PHPMyAdmin.

I globally disabled it a long time ago. I favour SequelPro/SequelAce. But we (still) have members in our teams who use it. The Problem I see if it becomes a ddev addon is: Dev A activates PHPMyAdmin and commits that to the project. Dev B pulls the projects and pollutes his/her local machine with PHPMyAdmin.

So I think we need a solution every Developer is able to globally activate/disable it.

[macmladen]

Maybe a verbose message after ddev config or when running ddev describe saying "you can get a db manager with ddev get" would be handy for those who will be affected by the switch.

I agree, ddev should be as light as reasonably possible and include whatever is needed by making a conscious choice.

There are many ways and many tools as we've seen here so having a choice not to have a default and an option to include what works the best for one's own stack is the way to go.

[cngJo]

The Problem I see if it becomes a ddev addon is: Dev A activates PHPMyAdmin and commits that to the project. Dev B pulls the projects and pollutes his/her local machine with PHPMyAdmin.

Would it maybe be an option to "install" PhpMyAdmin globally beside the proxy, so each developer can decide whether to use it or not? Not sure if it's possible, because you'd need to have access to multiple projects from the same PhpMyAdmin instance.

It could then be installed with a global configuration, a bit like the current option to use the traefik instead of the nginx proxy. Also, everyone could decide to use PhpMyAdmin or possible alternatives in the future like Adminer.

Not sure if that's possible / wanted, just had the idea and wanted to throw it in here ;)

[bserem]

@juergen-venne Pollutes is a strong word here. Worst case it is another docker image that gets loaded for that project, only if people commit it. Huge improvement from the current state where we always have PMA.

On top of that, Devs/Teams should be concise in their decision, we can't actually think of everything before hand, can we? If a team decides they need PMA so be it. If they decide they want to remove it down the road they can. Or maybe they can git ignore PMA docker files so it is not committed to the project. So many options here.

[jcnventura]

I too agree that this should be removed. However, this also something that should not happen without jumping to a new major version, as people should clearly be aware that things got removed from DDEV, thus breaking some sort of backwards-compatibility.

[tyler36]

For those that use PhpMyAdmin, what are the benefits over ddev get drud/ddev-adminer? Habit? Built-in?

I think we need PhpMyAdmin as an addon before removing it.

[chrisfromredfin]

Same. I'm totally in favor of removing it... once it's an add-on. For me, just familiarity. Starting to try adminer, but I usually just use SequelAce.

On Tue, Jan 10, 2023 at 7:10 PM tyler36 @.***> wrote:

For those that use PhpMyAdmin, what are the benefits over ddev get drud/ddev-adminer? Habit? Built-in?

I think we need PhpMyAdmin as an addon before removing it.

— Reply to this email directly, view it on GitHub https://github.com/drud/ddev/issues/3534#issuecomment-1378061268, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACD7KXDV44TM6VZCQWFHOTWRX26HANCNFSM5MKVFLEA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[rfay]

@jcnventura - absolutely to be done on major version @tyler36 new add-on absolutely has to be ready in advance.

Thanks!

[da-anda]

I'm also in favor of getting rid of it by default. I very much prefer dbeaver during development and would like to get rid of the PMA bulk.

[alesrebec]

I'm also surprised this is still in. On a clean install of a Drupal 9 site with Postgres db (without phpmyadmin uncommented in config.yaml) the phpmyadmin service is still running.

Definitely it shouldn't come enabled by default in ddev, but could stay easy to set up.

[rfay]

I've created github.com/ddev/ddev-phpmyadmin (tests not yet complete). Next step is to remove direct support from ddev.

[pasqual-artif]

This is the first result google finds, if you search for the warning in ddev. Please edit your command above from drup/phpmyadmin to ddev/ddev-phpmyadmin thx

[rfay]

I edited the OP, thanks, please see if that's what you were after.