Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UX] Config import should search recursively for config files to import #661

Open
jenlampton opened this issue Jan 30, 2015 · 7 comments
Open

Comments

@jenlampton
Copy link
Member

To reproduce:

  1. create a full export of your site
  2. un tar/zip the export
  3. edit one file (admin_bar.settings.json) and change one value ("position_fixed": 1,)
  4. tar up your entire config directory again
  5. import the new tar.gz, with changes
  6. notice the (incorrect) warning on the page:
    The uploaded configuration matches the current site configuration exactly. No changes were made.

This may be related to #640

@quicksketch
Copy link
Member

I tried out this exact set of steps but could not reproduce it.

I think what you're running into is actually a problem with re-tarring the files. You probably tarred the entire directory, which results in a tar.gz file that contains a directory in its root. The tar file needs to be the files in the root of the archive, with no directory. So when you uploaded the archive, config module didn't find any config files, rather than finding that they were all identical.

@quicksketch
Copy link
Member

Back when we first added testing for Config, I remember this coming up. I think we should probably adjust this issue to be a feature request for Config module to search within a single nested directory in the archives to help prevent this error.

@jenlampton
Copy link
Member Author

This could be the case, but my process was to un-tar what was exported, look at it, and then create an import that was an exact match to what was exported. I don't think we should expect that people will understand that exports and imports are different things - that's very counter intuitive.

We should either change the import (to optionally include the config directory - I recommend this approach) or change the export (to exclude the directory) so that the two files (the ones with the same name and exact same extension) contain the exact same set of files and directories.

@jenlampton
Copy link
Member Author

Also: #667

@quicksketch
Copy link
Member

This could be the case, but my process was to un-tar what was exported, look at it, and then create an import that was an exact match to what was exported. I don't think we should expect that people will understand that exports and imports are different things - that's very counter intuitive.

Just a note that the imports and exports are identical. Otherwise you wouldn't be able to import the exports. :P It's the process of untarring that creates the directory automatically for you. Then when you re-tar, most users will attempt to tar the directory, rather than trying to tar the things inside of the directory.

But in any case, we agree that the importer should just be a little more robust about finding the files in the archive that is uploaded.

@jenlampton jenlampton changed the title Config imports don't always recognize changes Config imports don't recognize config files inside a config directory Feb 6, 2015
@jenlampton
Copy link
Member Author

I wondered about that. I still think we should allow an optional config directory in the import process (and throw the correct errors). As it is now it's very hard to figure out.

@ghost ghost changed the title Config imports don't recognize config files inside a config directory Config import should search recursively for config files to import Sep 3, 2019
@jenlampton jenlampton changed the title Config import should search recursively for config files to import [UX] Config import should search recursively for config files to import Nov 1, 2019
@stpaultim
Copy link
Member

stpaultim commented Nov 2, 2019

Copying these comments that I originally posted in #3933 (duplicate): - some of this was new to that issue, but has already been stated here.

I would say that the feedback provided by Backdrop is misleading at best, I would describe it as inaccurate.

I spent 30 minutes last night trying to figure out how to get this to work and only figured out the problem, because I was able to ssh into the server and see what was happening in the staging config directory. Otherwise, I might not have figured out the problem.

If you think about it - for someone who does not do this all the time. This is what happens:

You export a config tar.gz file of the entire site config files.
You decompress it. When you decompress it, you get a directory full of json files.
You make a changes or add files to the directory.
You recompress the directory and all the files (the opposite of what you did in step 2.
You import the tar.gz file and get the following feedback: "The uploaded configuration matches the current site configuration exactly. No changes were made."
This makes no sense, since you know that there are in fact changes in the uploaded tar.gz file.

So Backdrop expects that you will exclude the directory when you bundle the files, but there is really know way for the average user (or a user like myself) to know that and the feedback is totally inaccurate and/or misleading.

Best solution would be for Backdrop CMS to recognize that the tar.gz file includes a directory and to resolve that.

Other possible solutions, add help text to: admin/config/development/configuration/full - "Your tar.gz file should not include any directories (link to instructions)."

Or, Backdrop could recognize that the input was unexpected and provide feedback that tells user "The uploaded config files should not include a config directory" OR "Unexpected files/format in tar.gz file."

I created a forum post that describes my use case and how I resolved the problem (work-a-round):
https://forum.backdropcms.org/forum/how-add-bundle-or-group-config-files-site

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants