Migrate backdrop & Drupal 7 references and Drupal 7 entityreference fields to reference.#25
Migrate backdrop & Drupal 7 references and Drupal 7 entityreference fields to reference.#25moonray wants to merge 6 commits intobackdrop-contrib:masterfrom
Conversation
…ckdrop reference fields.
…with taxonomy_term_reference fields.
|
Hey @moonray, thanks for working on this! I'm away at sxsw, but will try to check it over soon. @jenlampton What do you think about this being the primary upgrade path? I think it makes sense to be upgrading from d7 entity reference by default, and then moving cross-upgrades from the other reference modules to a helper module. |
|
Actually, this cross-upgrades from the backdrop references module, as well as from entityreference AND d7 references module. |
|
Is this a mandatory upgrade or optional? I'm hoping for an optional upgrade since there are reasons why people would want to use the others. |
When reference goes into core, we'll need to get everyone from everything else they may be using now onto reference. However, while reference is still in contrib, it may be acceptable to provide a helper module to allow people to opt-in to using a reference field only for specific cases. To me, that just seems like extra work, and since our progress has been slow-going to date, we should be focusing on making this module core-ready, rather than planning on it being in contrib indefinitely. Keep in mind that the "helper module" approach is what happened in D6 -> D7 with cck moving to fields in core. We can look back at that as an example of "what not to do to our users" and use this upgrade as an example of how Backdrop can do better!
If reference module goes into core, this upgrade will be mandatory and all other modules will be marked as "merged into core" and become unsupported - just like token, pathauto, entity_view_mode, and every other module that's been replaced by a core feature.
@herbdool can you list any of the reasons people might want to use the others? There shouldn't be any - but if there are, we will need to address all of them before this module goes into core :) |
|
There are a number of things the other modules can do that this one cannot (so far). In the issues you'll see a list of quite a few. Here's just a sample: views relationship, using a view to filter content to be referenced, reference prepopulate, more widgets, access control, hooks, ... I don't expect all of this to built into this module, at least not right way. But without everything the other modules can already do we shouldn't force people to use this module of the others have more functionality. IMHO |
We'll get the 80% use-case of those covered for core. The rest of those features will become contrib modules that extend the core reference module. Those likely won't all be ready at the time reference moves into core, but we'll have to make a decision as to whether we think its worse for some theoretical people to loose some features, or create a less ideal situation for everyone by having an icky upgrade path, or continue on with our module-selection-confusion. Let's start by seeing how close we can get with the feature list :) |
|
I don't know what you mean by "lose some features" but I think we need to avoid having a core upgrade that would remove (contrib) features on an existing site. If so people would either need to avoid the core upgrade or remove the reference module from core and then upgrade. |
Agreed! Here's a plan: Let's
|
|
we need to avoid having a core upgrade that would remove (contrib) features on an existing site
No existing site is going to lose featues if things from entityreference don't make it into core. No existing site has any of those features, as entityreference doesn't exist for backdrop! :)
Getting 100% feature parody is both unrealistic, (and completely unnecessary) as the number of people who are using most of those edge-case features now is exactly 0.
References is pretty simple, and there's nothing in there we can't steal for reference.
Agreed! Here's a plan...
I agree we should make a list (why I asked above) as I think this is a lot of worry about nothing. Anyone want to take a stab at one?
|
I guess, it's more about the Backdrop References contrib module. It's quite popular. |
|
I'm going to add a comment here #16 since this is a pull request and should focus it on the code. |
|
I think the conclusion from this discussion is that while reference is in contrib, and can be used alongside other reference-field-providing modules, we can't make the migration from those other fields mandatory. For now, we should stick to doing an automatic upgrade from entityreference and figure out other ways to help people convert those other fields (I'm leaning towards a reference_migrate submodule that will let people choose what fields they want to convert). @moonray, can you please submit another pull request with just the entityreference upgrade path, and reference issue #28 which I created for just this functionality? Thanks a bunch for your work! |
|
@mikemccaffrey IMHO that's going to be a lot of wasted effort. Considering how long it took us to get any kind of upgrade path at all, it may not be worth rejecting what we have in favor of something that's going to get thrown out in the end. |
|
@jenlampton What is getting thrown out in the end? I'm not sure what you are advocating against. I do know that we can't commit the code as is, because we don't want people who install this module to have a bunch of fields supplied by other modules irrevocably altered without some additional steps added to confirm that this is what they would like to happen. |
You had mentioned...
That will be thrown out when reference goes into core, when we'll put back what we have right now instead. |
That is a discussion for another day and another issue queue. Right now, I'm focusing on getting a contrib release out so we can get people using and testing the module. |
That could happen without any upgrade paths at all. Baby steps? |
|
I think this should remain open until there's another upgrade path provided. I still use this on all my Drupal to backdrop upgrades. It's even harder for people to find a closed PR than a module with no release. If i struggle to find it, and I use it all the time, I can't imagine what it's like for others. |
Well, it's too late for my perfect-world scenario because we now have an entity reference module for backdrop, as well as nodereference, as well as reference. So far, we've made the "multiple reference module" problem worse, and not better. We now have several upgrade path issues where we can work on each update independently:
|
5 participants
No description provided.