When the module is installed during a configuration import, the content snapshot is not generated. This causes the export command to report there is no content to export when running the drush command.

How to reproduce:
1. Create a Drupal instance using Drush site:install ( for example ).
2. Use the Drush command to import a configuration which enables the module.
3. Execute "drush content-sync:export", it reports no entities to export.

Expected result:
The module should report for export, the default content generated in the default Drupal install ( admin user, shortcuts, etc ).

Actual result:
The module reports no content to be exported.

Workaround:
A workaround for this problem, involves uninstalling manually the module with "drush pmu content_sync", and to enable the module again. ( drush pme ). Then, the drush export command reports the correct content to export.

CommentFileSizeAuthor
#7 moved_snapshot_to_settings_form.patch11.71 KBedmund.dunn

Issue fork content_sync-3134102

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

guiu.rocafort.ferrer created an issue. See original summary.

Blanca.Esqueda’s picture

Blanca.Esqueda CreditAttribution: Blanca.Esqueda as a volunteer and commented

@guiu.rocafort.ferrer thanks for the info.

Interestingly... this was working in the past, so probably it is related to the latest updates on dev or to the core changes done since it was working.

In any case, I had in mind to change the snapshot generation on install for different reasons. The main ones: time-consuming or timeouts for large sites, and not everyone wants/needs a snapshot of the entire site but only certain entities and dependencies.

My idea is to remove the snapshot generation on install and add a configuration screen for the snapshot creation with some criteria options.
It would be an extra step, but it will give more flexibility.

I have some work in progress that kind of related to the future snapshot configuration screen:
* Partial imports with dependencies using checks for the insert of data on the snapshot only if needed.
* Filters/Pagination for the sync screen.
* Drush command snapshot validation.

Maybe the fastest solution is just to add the snapshot configuration page without criteria options and remove the snapshot creation on install.

As extra info, instead of snapshot creation what I want to implement on install is to look for default content to import but this is another task.

guiu.rocafort.ferrer’s picture

guiu.rocafort.ferrer
Primary language Spanish
Location Barcelona
CreditAttribution: guiu.rocafort.ferrer at Indra Sistemas, S.A. commented

Hi @blanca,

I agree that generating the snapshot on install is probably not a good idea, and I believe that a administration page and/or a drush command might be better suited for the issue.

I also think that, before executing a drush export / import command, it is necessary to check if the snapshot have been created or not. In case it hasn't, a snapshot must be created before executing the command.

As a summary, I propose a series of tasks to develop:

  1. Don't generate the content snapshot on module install.
  2. Create a Drush command to generate the snapshot. This could be partial or total.
  3. Create an admin page to generate the snapshot.
  4. Before import / export commands, check if there is an active snapshot, and if not, generate it before executing the operation. If the command only involves a certain type of entity, this could be partial, as the drush command.

May I ask what have you already done, and how could we organize to reach this goals ?

Blanca.Esqueda’s picture

Blanca.Esqueda CreditAttribution: Blanca.Esqueda as a volunteer and commented

Hi @guiu.rocafort.ferrer

I have some work in progress that kind of related to the future snapshot configuration screen:
* Partial imports with dependencies using checks for the insert of data on the snapshot only if needed.
* Filters/Pagination for the sync screen.
* Drush command snapshot validation.

Unfortunately, the above changes are part of the work I'm doing to replace all the configuration classes that content sync uses and have their own classes, and to use a table instead of arrays for queues. I'm going to try to extract the parts that are needed for this ticket, but not sure if it would be a clean patch as that was work in progress and I need to revisit it.

If you already are working on this task, feel free to submit a patch and then I'll review it and commit it.
And later on, when I have a chance I'll integrate my work.

Thanks,
Blanca

guiu.rocafort.ferrer’s picture

guiu.rocafort.ferrer
Primary language Spanish
Location Barcelona
CreditAttribution: guiu.rocafort.ferrer as a volunteer and at Indra Sistemas, S.A. commented

Hi @blancaesquerda

I've been working in the dependency loop issue and now i'm planning to address this topic in hopefully 2-3 weeks. I wanted to know how is your work on the issues you mention before. Do you think these changes would be ready enough for merge anytime in the next month ?.

Also, if you send me a patch, i can apply it to my local environment and work from that.

Blanca.Esqueda’s picture

Blanca.Esqueda CreditAttribution: Blanca.Esqueda as a volunteer and commented

Hi @guiu.rocafort.ferrer
I haven't had the chance to go back to it, and I don't have a working patch.
There is another dev ( @edmund.dunn ) that offered help to work on the snapshot related issues, so probably he will be posting some patches in the following days/weeks too.

But it is ok because that's the beauty of open-source, later on we can combine solutions to have a better result.

Thank you!

edmund.dunn’s picture

edmund.dunn CreditAttribution: edmund.dunn at Aten Design Group commented
FileSize
moved_snapshot_to_settings_form.patch11.71 KB

I added a config form in a tab labeled "Snapshot" that will run the snapshot on the selected entity types and bundles. It generated the snapshot successfully. I was then able to export using drush.

yfma’s picture

yfma CreditAttribution: yfma commented

Confirmed above path #7 worked , it generated the snapshot for entity types and bundles.

Blanca.Esqueda’s picture

Blanca.Esqueda CreditAttribution: Blanca.Esqueda as a volunteer and commented
Version: 8.x-2.x-dev » 3.0.x-dev
Status: Active » Needs review
lquessenberry’s picture

lquessenberry CreditAttribution: lquessenberry as a volunteer commented

Patch #7 fails on 3.0.x-dev for me. Thanks.

Blanca.Esqueda’s picture

Blanca.Esqueda CreditAttribution: Blanca.Esqueda as a volunteer and commented

Added a patch to have the --force argument for the Drush export command:
https://www.drupal.org/project/content_sync/issues/3205955#comment-14235381

If the snapshot is not generated can not be used for diff/sync, but the --force will allow exporting even when the snapshot is not populated.

Dimiter made their first commit to this issue’s fork.

Dimiter opened merge request !4

Dimiter’s picture

Dimiter CreditAttribution: Dimiter at iO commented

I have created https://git.drupalcode.org/project/content_sync/-/merge_requests/4 , which just applies #7 on the current 3.0.x-dev branch. If you need a patch-file, you can use https://git.drupalcode.org/project/content_sync/-/merge_requests/4.patch

Dimiter’s picture

Dimiter CreditAttribution: Dimiter at iO commented

I did notice something being off in #14 though. The patch creates a new SnapshotSettings config, and it looks like it should split off the Adminsettings from the Snapshot settings, but right now when running config-split:export, all the settings are still written to (and read from) content_sync.settings.yml .

geoffreyr made their first commit to this issue’s fork.

geoffreyr’s picture

geoffreyr CreditAttribution: geoffreyr as a volunteer commented

I've made a few changes to the Merge Request as follows:

  1. The form save operation didn't vary the bundle key while performing the EntityQuery, ensuring that entity types that didn't use bundle key type would throw an exception. This has been changed to use the bundle key provided by the entity.
  2. Checks to make sure entities only get added to the snapshot queue once.
  3. EntityQuery uses accessCheck, ensuring compatibility with Drupal 10.
  4. Ensures that entity update/delete hooks take the new config into account, thereby skipping entities that aren't set to be included in snapshots.