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

Remove exportSiteStructure export step #3948

Open
thet opened this issue May 6, 2024 · 2 comments
Open

Remove exportSiteStructure export step #3948

thet opened this issue May 6, 2024 · 2 comments
Labels
99 tag: bssp Potential task for the Buschenschanksprint

Comments

@thet
Copy link
Member

thet commented May 6, 2024

BUG/PROBLEM REPORT (OR OTHER COMMON ISSUE)

Often, when I want to do an export of the whole site configuration in http://localhost:8080/Plone/portal_setup/manage_exportSteps simply click the "Export all steps" button:

image

But that one also exports the exportSiteStructure step:

image

For a site with production data, this can easily take a very long time.

Now that we are working on plone.exportimport, this export step will become unnecessary.

I'd recommend to remove the step or move it to a separate section where it isn't included in the site's configuration export.

What I did:

In a site with quite some data:

Along with the site configuration, the whole content structure is also exported and this can take a very long time.

What I expect to happen:

  • I expect only the configuration to be exported, excluding the site content.

What actually happened:

  • Site content also exported.

What version of Plone/ Addons I am using:

Plone 6.0.10 (6020)
CMF 3.3
Zope 5.9
Python 3.11.7 (main, Dec 5 2023, 10:44:07) [GCC 13.2.0]
PIL 9.5.0 (Pillow)
WSGI: On
Server: waitress 3.0.0
@thet thet added the 99 tag: bssp Potential task for the Buschenschanksprint label May 6, 2024
@mauritsvanrees
Copy link
Sponsor Member

You have the same problem in the caching control panel where you can choose to "Take a snapshot of the site prior to importing new setting." I never do that, because I know it would export the content as well, which makes no sense.

I remember that long ago, maybe in Plone 3, I had a problem because some content from Products.Poi could not be exported this way. I ended up making an empty exporter, registered only for issues. Still there, I see.

So yes, I can see that getting rid of this export step could be useful.

Of course, some people will like the export step and use it. And the export step is in Products.CMFCore, and I expect that people will complain if we really remove it there.

Here is the Python code of the export step. But where is it defined in zcml? Ah, that is in Products.CMFPlone. I did not expect that.

So we could remove it if we want to. We could do that in Plone 6.1.

Idea for keeping backwards compatibility:

  • Keep registering the content export step.
  • Let the step point to a new function in Products.CMFPlone.
  • Let this check an environment variable, something like PLEASE_LET_ME_HAVE_MY_CONTENT_EXPORT_STEP. ;-)
  • If this env variable is not set, we do nothing.
  • If the environment variable is set, we print a warning that this will be removed in Plone 7, and then we call the current function from CMFCore.

@davisagli
Copy link
Sponsor Member

davisagli commented May 8, 2024

@mauritsvanrees That sounds kind of complicated, and I really doubt the content GS step is used much. My first inclination is to just remove the ZCML registrations of the content step, and document in the 6.1 upgrade guide how to add them to your own project if you need them.

For Plone 6 and earlier, it might be possible to use z3c.unconfigure in your project to ignore these zcml registrations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
99 tag: bssp Potential task for the Buschenschanksprint
Projects
None yet
Development

No branches or pull requests

3 participants