Active
Project:
Default Content
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
25 Dec 2015 at 04:09 UTC
Updated:
22 May 2024 at 14:26 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
sam152 commentedComment #3
claudiu.cristeaThis might end in a very complex interface. I would go with only implementing a VBO action. Then site admins can use that action only on entity types where this is needed. Dependencies will be displayed in the subsequent VBO confirmation form.
Comment #4
matslats commentedNot what was suggested but I've now put a tab on each ContentEntity page which leads to a form from which the entity can be exported to screen or to file, with or without relations.
And pushed it...
This enables exporting default content one item at a time, which is ok at least for now.
VBO would be another dependency but would allow many items to be easily selected at once as long as the source site content wasn't overpopulated.
Comment #5
sam152 commentedIs there an issue for these changes? Can you please read and adhere to Best practices for co-maintaining projects.
Comment #6
matslats commentedthanks for pointing that out.
I'm unaccustomed to coding as part of a team
These were changes I had made to defaultcontent module where I was the only maintainer for the last six months.
And because I really need the translation done, I was trying to show willing.
Comment #7
andypostI'd better keep UI module separate, latest commits of UI makes module broken so would be great to prevent this
Overall +1 to VBO action for export and similar CMI form for import
Also UI could be extended to show collisions between exported data and actual entity fields
Comment #8
matslats commentedAndy when you say
> latest commits of UI makes module broken
that sounds like something I should be fixing.
is there an issue for that?
Comment #9
andypostAll 3 issues are quick fixes and rtbc today
See #2684133-3: Wrong arguments declaration in services.yml file
Comment #10
benjy commented+1 for having the UI in a separate module.
Comment #11
andypostFirst of all I suggest to rollback UI it causes a lot if issues and makes module unusable
then roll out next release and polish UI with tests
Comment #12
larowlanOk, let's push it to a feature branch then revert
Comment #13
andypostComment #14
andypostI pushed current 8.x-1.x to 8.x-1.x-ui feature branch
Comment #16
larowlanPushed the revert, thanks @andypost
Comment #17
larowlanComment #18
andypostComment #19
frondeau commentedHello,
Is UI still a topic to involve the default_content module ?
If not, we could close this ticket.
Regards.
Comment #20
andypostone day it will appear, there's no tool to consume info.yml index yet
Comment #21
lazzyvn commentedI did it
for somone who is looking for
https://www.drupal.org/project/default_content/issues/3426940
Comment #22
rodnamoc commentedThis module might work https://www.drupal.org/project/single_content_sync