Migrate content #5
Labels
No labels
A11y
Automated Testing
Contributable
Contributed
Decision
Design
Development
Drutopia
IndieWeb
Infrastructure
Launch Critical
Marketing
Needs documentation
Post-Launch
status
Abandoned
status
Blocked
status
Deploy
status
Doing
status
Done
status
Duplicate
status
In Review
status
Needs Clarification
status
Test
status
To Do
type
Bug
type
Task
type
User Story
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: geo/geo-coop#5
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Work Required
marked the checklist item Finalize migration plan - https://ethercalc.org/geo-migration-plan-13sdfsdfq34 as completed
marked the checklist item Map fields - https://ethercalc.org/geo-field-mapping-123sdfs4 as completed
marked the checklist item Write migration scripts as completed
assigned to @gnuget and unassigned @cedewey
web/modules/custom/geo_upgrade/migrations/upgrade_d7_file.yml:12: source_base_path: '/var/www/html/d7/'
That's not going to work except on local, right? Can't it be defined relative to the web root?
Moreover... can the old files just be moved to
web/sites/default/files
? I expect there'll be a lot of "unmanaged" files that are in there that we'll still want.And fascinatingly:
and it bails on the migration, but re-running the migration group picks up and continues fine.
@gnuget There are many aliases, but they are all the ones created on the new site.
There are no redirects: https://geo.ddev.site/admin/config/search/redirect
We definitely need the 4,853 old path aliases —
/about
,/story/charter-social-solidarity-economy
,/content/brewery-co-op-brings-everyone-table-loomio
to name a few representative ones — to be brought over to the new site as redirects.Or maybe because you made the node IDs the same we can export the aliases from the old site and create a big .htaccess-style redirect of them all to their associated node/ids, and then the new site can take it from there?
If doing old paths as redirects in a migration is difficult, let us know and we (@wolcen) can pursue other approaches.
Overall the migration looks great!!
marked this issue as related to #9
marked this issue as related to #10
marked this issue as related to #8
marked this issue as related to #15
marked this issue as related to #16
@gnuget I ran into some things on the actual run of the migration on the server instance.
First, I was unable to find the source files. This turned out just to be the hardcoded path in the config.yml for the migration. See this line in upgrade_d7_file.yml.
Once this was adjusted, the file section ran, but stopped afterwards:
Despite the above complaints, and stopping after this, files were being populated into the files folder, and we now have >3k in there.
I simply reran the import:
So - after this, it appears there is some content!
It'd be great to see this project use a containerized deploy, eh? (where this type of setting is pulled into a known file system layout).
marked this issue as related to #20
OK, the aliases are being handed in, and we can deal with them afterward. Closing this issue as we have enough related ones following up on the weird parts of the migration (and David's doing and did tons of work we never even wrote down first, also).
closed
marked the checklist item Run migration as completed