For security purposes I would expect to see the uploaded db dump deleted from the server after it has been used. I would also expect to see some "uniqueness" in the export file name instead of just joomla_db.zip. Probably including the site name and a time stamp.

Notice: Constant JPATH_ROOT already defined in C:\htdocs\joomla-cms\administrator\components\com_installer\Model\DatabaseModel.php on line 14

Windows cannot open the zip

Looking at the zip file I can see that it fails to open because at the top of the file before the zipped data is the markup for the html of the page

My gut is to close this as it's technically no different to the feature we rejected here #15819 (comment) - Anything you'd like to add that hasn't already been discussed there?

This is a gui for PR #24733. This is just a draft and all comments are welcome.

It works with PostgreSQL, but there are some recent bugs when importing into the MySQL database (regardless of this PR).
I hope to do a new PR soon to solve it:
https://github.com/twister65/database/tree/fix-import

Referring to @wilsonge comment #26248 (comment), I close this.

Note that postgresql is no longer supported by Akeeba Backup.
If someone needs to do a full backup of his site, he can use phppgadmin to dump the database and tar to archive the files.
So practical ! What good is it to be bored.

@twister65 at least thanks to your work, we can use the CLI command for this...
btw i disagree with @wilsonge ..... maybe i'm the other postgresql user other than you ?

Bug fixes for the database importer / exporter are here:
joomla-framework/database#191

Reopened for test purposes only, at my convenience.

Windows cannot open the zip

@brianteeman , could you precise your system informations ?
I tested this without error on Windows 10 and wampserver.

I have tested this item ✅ successfully on 5cb9f08

I have tested this and it works successfully, even the downloaded file is also readable.

I am not shure, that the result is ok

@berndkohlen , please see my previous comment: #26248 (comment)
You also need to apply PR joomla-framework/database#191

I have tested this item ✅ successfully on ea0ba05

I have tested this item ✅ successfully on ea0ba05

I have tested this item ✅ successfully on ea0ba05

I did not fund the location of the button 'information' first and did not check the database button first, when i was importing the database again.

But technically everything was fine.

RTC

tested export on another env got
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted

we can use some concept from here #15819

It exports all tables even ones not with the same table prefix. Is this the desirable behavior?

Clicking the Import button, I was expecting a modal to select a file. I did not even see the import box below the button.

Yes, it exports the entire database. When I have time, I'll improve it:

• Import and export only tables with the prefix used.
• Include the import button in the import box.

Thanks for your relevant review @Quy.

@Quy, I did not find in ToolbarHelper, a modal button to select a file. So I let the import GUI in two steps:

• Select a database zip file to import in the import box.
• Click on the Import button.

An alert message is still present if no file has been selected.

I can't open downloaded zip. Says it's invalid. Changing its extension to tar.gz works though.

I can't open downloaded zip. Says it's invalid. Changing its extension to tar.gz works though.

@SharkyKZ , what is your system information ? Tell me if ZIP module is enabled in phpinfo.

Tell me what this command returns with your damaged zip file:
zip -v --test joomla_db-2019-12-2XTHH-MM-SS.zip

You should have something like this:

@brianteeman and @SharkyKZ , I added the file size in the header and flushed system output buffer to download the zip file. Could you tell me if you have your opening error again?
I think it is expected by some browsers.

@brianteeman and @SharkyKZ , I added the file size in the header and flushed system output buffer to download the zip file. Could you tell me if you have your opening error again?

I can open the downloaded zip now

I would also expect to see some "uniqueness" in the export file name instead of just joomla_db.zip. Probably including the site name and a time stamp.

Definitely for those that manage multiple sites to prefix with the domain name or database prefix.

Here on Macintosh, I can't unzip the downloaded file.
If I try to, I get
multilangsample_DB_2019-12-28T10-50-32.zip.cpgz
from a zip called
multilangsample_DB_2019-12-28T10-50-32.zip

hmm, I did not apply
joomla-framework/database#191
as I don't know how.
This may explain that.

Here on Macintosh, I can't unzip the downloaded file.

Have you tried to export a file with another browser (with Safari or Firefox, and vice versa) ?
Let me know, and I will try to fix it with my boring Apple PowerMac G5.

Also, apply this patch joomla-framework/database#191 in your ROOT/libraries/vendor/joomla/database folder.

@twister65
As i wrote above, can’t apply that patch with eclipse here.
No worry.

@infograf768
I just synchronized joomla-framework/database#191 with the current 2.0-dev branch.
It should be fine now.

You can import a zip file that is not a backup and will get a All tables imported. which is misleading.

You can import a zip file that is not a backup and will get a All tables imported. which is misleading.

I just have the informational message All database table structures are up to date.. It did nothing. An error message is missing.

i'm experiencing the same issue, that has been reported by @Quy previously, beside that, all good, i've successfully imported/exported from/to CLI too

@alikon , there is no (yet) import command (CLI) in zip format.
I will add it in a new PR.

@Quy and @alikon , check out the last commit. The analysis is light but should be sufficient to solve the last issue.
Thanks for your interest.

I have tested this item ? unsuccessfully on bfbf948

@twister65 Still getting message that "All database table structures are up to date." when importing a zip that isnt a backup as well as when you click "import" before selecting a file. The correct errors occur, but still contains the misleading message.

@jwaisner , the informational message "All database table structures are up to date." occurs when the system database view is updated. Regardless of this PR, this indicates that the structure of your database is up to date after examining the SQL update scripts (to update the Joomla! core).

I am working to separate the "Update structure" view and the "Import" view with tabs in order to differentiate each functionality.

Regards (Work in progress),

I have tested this item ✅ successfully on bfbf948

@twister65 I misunderstood the expected result. After retesting the functionality works as per this PR.

@ttplpoojak @SharayuYadav @Neppert

Can one of you please retest this PR after changes were made?

@twister65 please can you solve conflict
thanks

@twister65 thanks
i've just linked this pr to a potential GSOC 2020 student,
so the reason of my request

@alikon , it is updated. I don't understand:

i've just linked this pr to a potential GSOC 2020 student,

The next week-end, I will test your PR #25022 with an export job plugin.
Regards.

with postgresql (pdo) 11.7
installed latest 4.0-dev from github (with no sample data)
applyed the pr
exported
and imported
now check structure complain see screenshot

@alikon, remember joomla-framework/database#191 (comment)

i've thinked that the last composer update #26820 have fixed that
what i'm missing ?

we need to split up what the default value is and what the column properties are.

joomla-framework/database#191 (comment)

The fix has been removed from joomla-framework/database#191
joomla-framework/database@a2fa814

I have tested this item ✅ successfully on bfbf948

Applied patch via patch tester, clicekd the export button, it downloaded the zip file and afterwards I clicekd the import button and selected the downloaded file worked without problems.

I have tested this item ✅ successfully on bfbf948

Tested successfully with MySQL

@twister65 The com_installer.ini was cleaned up in #30162 Can you please fix the conflict?

Hello,
thanks for your contribution.

As stated already, this PR is in my opinion not an improved solution to #15819 which was rejected for valid reasons. It also has the some additional challenges + e.g. missing the "time out protection". So I close this PR.