export to SQL format not available for tables

[thelounge-zz]

4.8.4: database can be exported as sql, for tables it defaults to "CodeGen"

yes, maybe it's because of my rpmbuild deletes a large part of folders and files because in the past few years phpMyAdmin became a horrible bloat, but there is no rational reason differ in that part
phpMyAdmin: 4.8.4

[ibennetch]

I confirmed this with 4.8.4, but not with the current master.

SQL isn't even available as a table-level export option, but works as expected for database- and system-level exports.

[ibennetch]

Git bisect tells me that c1cdaac is the first bad commit, @MauricioFauth could you take a look?

[lotharsm]

I can confirm this for 4.8.4, haven't tried the current master since the installation in question is running in a production environment.

[ibennetch]

If we can fix this in the next few days, I'd be interested in releasing 4.8.4.1 along with #14782.

[bs-thomas]

Wow, what an issue... Looking forward for the fix soon! Thank you so much guys!

[williamdes]

git bisect found that c1cdaac is the first bad commit.

[thelounge-zz]

can someone please fix that tragedy because it's simply impossible in that overengineered codebase to even guess where the values for the select are coming from and when you are at it stop leaking phyiscal temp-dir as full-qualified path in the import screen and make all that "hey place files on the server and select them in phpmyadmin" stuff OPTIN for the sake of security

[idonda]

@thelounge-zz can you temporarily downgrade to 4.8.3?

[williamdes]

@thelounge-zz I am fixing this issue in minutes ;)

[thelounge-zz]

how can 9511484 which just copies a GET value to a GLOBALS (shrug) fix the content of a select-field?

[williamdes]

@thelounge-zz You can confirm that 9511484 fixes the issue ?

[thelounge-zz]

[root@srv-rhsoft:/downloads]$ cat Export.php > /usr/share/phpMyAdmin/libraries/classes/Display/Export.php

indeed - it's displayed again and even working - i honestly don't want to understand the codebase behind which seems to work out of a miracle

[idonda]

@williamdes it does fix the problem for me.

[wzltr0n]

Good news... if I select the db, then checkbox the table(s), exporting under "with selected" I get the SQL option :)

I can also export the full database. Glad there are workarounds for this otherwise debilitating issue.

[pxao02]

Any clue when version 4.8.4.1 gets released? I can't use the master branch on production servers, and more and more clients are noticing the missing export. I could point them to the workaround for a while but it's getting a bit tiresome now :)

[thelounge-zz]

@pxao02 while i also don't get why there is no bugfix release you can simply replace that one single file and are done for now, and yes i normally build phpMyAdmin rpm packages but that don't mean you can't overwrite a single file in the meantime

#14775 (comment)

[pxao02]

Good point @thelounge-zz I might consider doing this if it doesn't get released any soon.

[ibennetch]

@pxao02 and @thelounge-zz My plan was to release 4.8.4.1 as a quick fix for the several regressions caused with 4.8.4 (which were all related to a security change we made), but it seemed like #14800 was also related and I was holding the release for a fix for that issue.

Meanwhile, the continued development cycle meant that 4.8.5 continued to get regular bugfixes and we're coming up on the time I intended to release that next version, which I tentatively planned for a release early next week. Releasing that and the concern over not having #14800 fixed yet kind of created conflicting goals now, where I have to balance releasing a fix for the export issue that contains a known issue with the process list, or if I wait for 4.8.5, or do I hold 4.8.4.1 until the process list issue is fixed. Honestly, I expected a quick fix for the process list issue just like the sql export issue was quickly fixed, and that hasn't happened...perhaps I decided wrongly to wait on the release and now I think I should have released 4.8.4.1 sooner, but it wasn't until a few days ago that the whole big picture view of the timeline became clear.

So I may be able to release 4.8.5 a bit earlier than planned, in order to get this and a few other fixes out.

All that to say basically that I was waiting for a fix that hasn't happened, I think that was a mistake, but now we'll probably soon see a release of version 4.8.5 instead of 4.8.4.1.

Of course, we regret the inconveniences this has caused and are grateful for your patience and understanding.

[idonda]

@ibennetch thank you. Interesting to know what is going on behind the scenes. keep up the good work

[thelounge-zz]

don't get me wrong but "where I have to balance releasing a fix for the export issue that contains a known issue with the process list" is pure nonsense! currenmtly you only have a old insecure or a new version available with obviously more than one issue

so how could it be more bad fix the low haning fruits and make a point release still containing the other bugs than only have a completly buggy version available?

[pxao02]

Thank you @ibennetch !
For me personally it will not make a difference whether you release 4.8.4.1 or 4.8.5. What matters most is that either one of them will be released soon enough to fix the SQL export, which is causing us the most trouble with our clients :)

[ibennetch]

@thelounge-zz I'm sorry you feel that way, but when the security flaw was fixed, a side effect was that a few places where requests were being passed between code blocks got missed and there were several similar bugs as a result of that fix. Would you have preferred for me to release 4.8.4.1 for the Text_Plain_Sql error, then three days later release 4.8.4.2 for the two-factor QR code, and two days after that release 4.8.4.3 for this SQL export issue? Some people do prefer a rapid release cycle, but most of the feedback we've gotten indicates that people would prefer we group fixes like these to make one release. Since several of the regressions were directly related to the one code change, it seemed to make sense to hold off on a release until all of the related problems were fixed at once.

Unfortunately, it turns out that the one that seemed related (and may still be) took longer to diagnose than expected. There's a skill to balancing "I need a few days to figure this out and fix it" against realizing "This is going to take longer than I expected," and I messed up.

I think your point about fixing the low hanging fruits is the exact detail that caused 4.8.4.1 to slip by a week or two here; I thought the final issue was a low hanging fruit that was closely related, so I was chasing that to include as part of the release.

[thelounge-zz]

the answer to "Would you have preferred for me to release 4.8.4.1 for the Text_Plain_Sql error, then three days later release 4.8.4.2 for the two-factor QR code, and two days after that release 4.8.4.3 for this SQL export issue" is CLEARLY YES

in doubt i prefer every two days throw a tarball into /rpmbuild/SOURCES/ and fire up rpmbuild because it's cheaper than a single phone call why some crap don't work now and how to solve it for the user

"but most of the feedback we've gotten indicates that people would prefer we group fixes like these to make one release" - these people are morons! nobody is forcing them to deploy 4.8.4.1, 4.8.4.2, 4.8.4.3 on the day they are released, the can just ignore them if they think all is running fine enough

[ibennetch]

I want you to know that we take your feedback seriously and consider these things when evaluating our long-term plans. Thanks for sharing your views on this.

[thelounge-zz]

and small point releases have the advantage in case they contain a regression by themself that it beomces qucikly clear from where they are coming besides when 4.8.4.1, 4.8.4.2, 4.8.4.3 all have several bugs you can chose which of them affect you most

as example i could not care less about "process list issue" because i owuldn't miss the whole feature at all like for a lot of stuff phpMyAdmin was bloated with over the years and features like "chose a file from the server for import" leaking a phyiscal path to the user are making me terrible angry to begin with

honestly i want my old phpMyAdmin where you had a frameset and no ajax at all back with just security fixes instead have "rm -rf" and a patched css full of "display:none" the biggest part of my rpmbuild specfile