Hello all, it’s time for the weekly migration initiative meeting. The meeting will take place in slack in various threads
| mikelutz |
Validation during migration entity saves |
| mikelutz |
Validation is part of the entity forms, not the entity api itself, so it’s not triggered by default. There is an issue open to allow validation as an opt-in, but making it opt-out is a tricky bc break that would probably have to wait until D10 |
| phenaproxima (he/him) |
“Validation is part of the entity forms, not the entity api itself, so it’s not triggered by default.” <-- I don’t think that’s true, validation is part of the entity API. At least for content entities. |
| wimleers (he/him) |
That is indeed absolutely not true. |
| wimleers (he/him) |
It used to be true in Drupal 7. |
| wimleers (he/him) |
It’s not true in Drupal 8. |
| wimleers (he/him) |
If it were true in Drupal 8, rest.module and jsonapi.module would be hopelessly insecure |
| mikelutz |
Well, am I thinking of the field level validation then? Or just specifically that ->validate is not included in ->save(), which is what I meant. |
| phenaproxima (he/him) |
@mikelutz Right. $entity->validate() and $entity->save() are two different operations, the latter does not invoke the former |
| heddn |
https://www.drupal.org/node/3073707 I was thinking of here (edited) |
| mikelutz |
So I perhaps I wasn’t clear, I didn’t mean the the validation wasn’t included in the api itself, just that it wasn’t forced by the entity api. it’s forced by the forms (and jsonAPI) |
| wimleers (he/him) |
well yeah it’s not “forced” |
| wimleers (he/him) |
but that’s only for BC reasons |
| wimleers (he/him) |
What is the reason for Migrate to not validate entities? |
| wimleers (he/him) |
If my migration appears successful, I also expect to be able to edit entities on my destination site. Right now, it’s possible that they render fine, but as soon as I go to their edit form and then hit Save without changing anything, that will result in a validation error.That’s why I think migrate should run $entity->validate() prior to $entity->save() to ensure all migrated data complies with the destination’s validation logic, i.e. with the destination data model. |
| phenaproxima (he/him) |
I agree with Wim. |
| mikelutz |
Stubs can sometimes cause problems, though that could be handled. There are historical reasons, but of course that’s no reason not to change. We deal with a lot of bad data during upgrade migrations, and sometimes you just want to get as much in as possible. I’d like to see us get to a position where we can do the validation, as long as it doesn’t make D6 and 7 upgrades more difficult, especially right now. |
| heddn |
@wimleers (he/him) @phenaproxima (he/him) we have validation built into entity api and for content entities it is an optional feature we can turn on. |
| heddn |
for BC reasons, we didn't turn it on for all migrations |
| heddn |
reason being, links. |
| phenaproxima (he/him) |
That makes sense to me. |
| heddn |
links in d6/d7 are notoriously all over the place. |
| phenaproxima (he/him) |
@heddn Can you elaborate on that a bit? |
| heddn |
and if we get the data into D8... then its easy to fix them up |
| heddn |
but for a lot of legacy sites (thinking d6) fixing up all that data in d6 before migration is really, really hard. much better to import the data, then fix it over time |
| phenaproxima (he/him) |
@heddn I don’t know if I agree with that. The reason being that users don’t care about what their data looks like, they care that the site works. |
| heddn |
plus, these links are on really old pages. blog posts that were written 5+ years ago. SEO value of fixing those links is very low |
| heddn |
all over the place = validation in D6 for links was almost non existent. d7 let you do some very odd things. D8, now link is in core, has some pretty standard validation. |
| heddn |
pulling that data into d8, exposing the data in a view, then fixing it in the new system, or fixing it via process plugins. but to discover the bad links, it is really hard in D6. much easier in d8 (edited) |
| heddn |
plus BC for migrations that have been running for quite some time. |
| heddn |
you can always turn on validation. but many smaller sites don't care that much and would rather not pay for the time needed to fix the data. as long as "most" of it works. |
| heddn |
but... the framework does exist for those sites that do care. they can turn on validation at their desire. so this is really a philosophical discussion |
| wimleers (he/him) |
https://www.drupal.org/node/3073707 is GREAAAAAATTTTTTTTT!!!!!!!!! |
| wimleers (he/him) |
reason being, links. |
| wimleers (he/him) |
This I do not understand. |
| wimleers (he/him) |
Even after the explanation above. |
| wimleers (he/him) |
I can’t imagine all that being about @FieldType=link? |
| heddn |
That's the most obvious and frequent example. We added the feature. If we could, we'd turn it on by default. Maybe it should be in D9 |
| heddn |
But for BC, we can't turn it on always in 8.x |
| wimleers (he/him) |
Is there a reason why the migration system does not have a --dry-run flag? If rollbacks truly rolled back everything (including on disk and ID-autoincrement), then that’d be the answer. But it doesn’t, so this need still exists. |
| phenaproxima (he/him) |
I think part of the reason this is an issue is because the D8 migration system was a quick-port from D7 and did not account, over time, for changes in D8's overall architecture |
| wimleers (he/him) |
But that doesn’t go into the architectural rationale. Furthermore, if rollbacks are imperfect/incomplete in D8, then that would’ve been the case in D7 too. |
| phenaproxima (he/him) |
It is quite possible that was the case in D7, but I’m not sure. I imagine it might have had fewer overall “effects” in D7, since that was much more geared towards migrating entities, as opposed to the D8 migration system, which wants to be able to migrate anything |
| heddn |
what is the point of dry run? |
| phenaproxima (he/him) |
To find errors! |
| heddn |
import, then rollback. |
| heddn |
or start from a fresh install again |
| heddn |
or rollback, but if you have any sizeable amount of data, expect it will take a really, really, really long time |
| phenaproxima (he/him) |
Except rollback doesn’t really do it. |
| phenaproxima (he/him) |
It can delete content entities |
| phenaproxima (he/him) |
But config changes? Nope. |
| phenaproxima (he/him) |
And I don’t think we can really expect users to do the import, fix the thousands of errors, then do it again. Giving them info beforehand is a much friendlier option. |
| heddn |
@phenaproxima (he/him) most of those errors don't surface until you actually save. |
| heddn |
That all said, we did recently added --continue-on-failure to migrate tools: #3092369: Add continue-on-failure option |
| heddn |
This would perhaps help in this space |
| phenaproxima (he/him) |
“most of those errors don’t surface until you actually save.” <-- then Drupal core has a validation problem. |
| phenaproxima (he/him) |
If we cannot detect egregious errors until runtime, we need to fix that. |
| heddn |
|
| heddn |
we could add it. yes. but there's a lot of entity reference required fields. I feel like a dry-run option would get caught by that most of the time. unless we had the option to ignore errors on certain fields. but then why not just --proceed-on-error --limit=20 and see what happens. then rollback. |
| mikelutz |
So, two big problems with Dry-Run. The biggest is that migrations depend on each other, but each instance of executable runs one migration and runs it by itself. There’s no direct api to run a group of migrations in core. Trying to do a dry-run of single migrations is meaninless because their dependent migrations won’t have ran. |
| mikelutz |
The second is more manageable, and that’s just defining what a dry run means, and how useful it is. Is it just a NULL destination, and you are dry-running the source and process plugins? fine. Do we need to add something for destinations to manage what a dry run means to them? Probably. It probably means validate for entities at least (but we don’t validate now, so until we do that consistently, I’m not sure that’s helpful. |
| mikelutz |
The third (I thought of a third) is evil contrib process plugins like entity_generate. process plugins should not affect the destination, but unfortunately some do, so they will break dry-runs. |
| heddn |
migrate_generate-- |
| heddn |
until its useful, then migrate_generate++ |
| heddn |
|
| mikelutz |
it’s a handy custom shortcut that is okay if you know what you are doing, execpt it just isn’t, and if you know what you are doing you can do it in a better way, lol. |
| heddn |
@mikelutz the use cases I find most interesting for its use are a slow feed, i.e. JSON, CSV with taxonomy terms (think tagging). No need to process the slow feed 2, 3, 4+ times to insert all that extra data. Where that extra data is just a Name value in a taxonomy_term entity. |
| mikelutz |
Yeah, especially if you aren’t rolling back, and have good error handling. It’s just sooooo not ETL. |
| wimleers (he/him) |
MigrateProcessPlugin plugins don’t seem to have any validation logic built in for their options. Consequently, the only way to know whether a configured process plugin is a valid configuration is to … run it, and observe whether it fails. Is this correct? Am I missing something? |
| phenaproxima (he/him) |
I believe you grok it in fullness. But I’m not sure plugins have any sort of API to validate their options, outside of a form context. |
| phenaproxima (he/him) |
In general, I’m very +1 for plugin constructors validating their incoming configuration with asserts and such. |
| wimleers (he/him) |
But that still implies runtime validation. I think it’d be very valuable to be able to validate migration definitions before running them.In other words: the ability to audit migration definitions.cfr. https://drupal.slack.com/archives/C226VLXBP/p1573740855247800 |
| heddn |
@wimleers (he/him) all process plugins I've worked on almost always have config validation w/ InvalidArgumentExceptions added to their constructor |
| wimleers (he/him) |
But that’s still runtime validation. |
| phenaproxima (he/him) |
I think I’m on the same page as Wim here. Where a big, sensitive migration is concerned, AOT validation generally beats runtime validation. |
| wimleers (he/him) |
Also, the very first process plugin in core is \Drupal\migrate\Plugin\migrate\process\ArrayBuild, and that does validation not in the constructor, but in the ::transform() method |
| heddn |
are we suggesting validation during plugin discovery? |
| heddn |
much of the validation can't be done until runtime |
| phenaproxima (he/him) |
@heddn I think it’s more like validation during $plugin->setConfiguration() |
| heddn |
but adding things to plugin discovery is possible |
| heddn |
setConfiguration is run during construction, no? isn't that splitting it pretty fine? (edited) |
| wimleers (he/him) |
More like a static function validateConfiguration() that can be invoked for a given plugin without instantiating. But you say that much validation can’t be done until runtime, so that won’t work presumably? |
| wimleers (he/him) |
Since https://www.drupal.org/node/2876085, we have AuditorInterface. The only implementation is IdAuditor. I could not find any discussion about other potential high-value auditors that would help prevent many migration caveats/PEBKACs. (http://grep.xnddx.ru/search?text=auditorinterface&filename= yields zero results.) Suggestions? Thoughts? |
| heddn |
The reason no one has written it yet is because it hasn't been high enough perceived value. there's an issue in migrate_tools or is it migrate_upgrade to build out more auditing in contrib. its just never been acted upon. |
| wimleers (he/him) |
I’m very interested to act on it |
| wimleers (he/him) |
Can you link to the relevant issues? |
| wimleers (he/him) |
I’m new to Migrate, so it’s hard for me to already see what the potential gains are, i.e. what things are that could be audited |
| mikelutz |
There’s another issue in core to convert the system into a more in-depth audit and decision collecting system, where we can detect problems and ask the user a question, and use the answer later to steer the migrations. |
| wimleers (he/him) |
A concern is that it seems there’s no code that calls all auditors; there’s only an interface, and the call to IdAuditor appears to be hardcoded. I fiercely hope I’m just misreading the code! |
| mikelutz |
No, the system was never fully flushed out. All it can currently do is scan and report, but it can’t change anything so it’s of limited usefulness. |
| heddn |
at the time the audit was created, it was added to unblock the last critical blocker for stability. we knowingly cut corners. |
| heddn |
this was back in New Orleans timeframe |
| heddn |
#2840154: Implement migrate-key-audit command for D8 |
| wimleers (he/him) |
Thanks for that link, @heddn! Responded: #2840154: Implement migrate-key-audit command for D8#comment-13353405 |
| mikelutz |
I’m very much opposed to flushing out the current auditing system. It needs to be rebuilt. The one audit that exists is losing usefulness with the latest multilingual migrations that are going to basically REQUIRE all content be purged to work anyway. |
| mikelutz |
@wimleers (he/him) #3061676: Create an audit plugin class/manager for migrations |
| wimleers (he/him) |
@mikelutz can you express that opposition in #2840154: Implement migrate-key-audit command for D8#comment-13353405 please? |
| wimleers (he/him) |
You both responded, thanks both! |
| wimleers (he/him) |
Is work happening to consolidate some of overwhelming number of modules in the Migrate ecosystem? As somebody who’s new to it, it’s really really overwhelming. Having to choose migrate_run vs migrate_tools is pretty much one of the first things you have to decide. And much more follows after. |
| wimleers (he/him) |
And: how can I help? |
| phenaproxima (he/him) |
+100000000000000 |
| mikelutz |
migrate tools migrate plus and migrate upgrade are the big three, maintained by @heddn |
| mikelutz |
There are tons of smaller contributed modules of varying maintenance status and usefulness, but we do try to consolidate the generally useful plugins and functionality that doesn’t belong in core into those three. |
| heddn |
exactly. I don't follow migrate_run that much. But I believe it was a fork of migration tools several years ago. I would hazard a guess it isn't as frequently maintained as tools. But then I'm also biased as I spend a lot of my contrib time on tools. |
| heddn |
run vs tools has a philosophy difference. around migrations stored as config entities vs migrations as only yaml based plugin instances. |
| heddn |
There are 2 camps in the world of migrate. Those that side on migrations as yaml plugins use run. Those that use config entities use tools. And if you want a web UI to do anything, you use tools and config entities. |
| phenaproxima (he/him) |
I have long believed we need to go away from this “two ways” model |
| heddn |
except you aren't going to take my config entities away from me so then we stop there and have hugs all around |
| wimleers (he/him) |
have long believed we need to go away from this “two ways” model+1 — to somebody who “just” needs to do a migration and isn’t nor wants to become an expert in this, this oh but you just choose, except they need subtle and non-subtle differences that you’ll need to figure out situation is way too costly and risky. |
| wimleers (he/him) |
Any reason we can’t standardize on config entities? |
| phenaproxima (he/him) |
We previously did, before D8.1 |
| phenaproxima (he/him) |
It was unwieldy (edited) |
| phenaproxima (he/him) |
And we couldn’t do “deriver”-type stuff, which was crucial. |
| phenaproxima (he/him) |
We switched to plugins for a reason |
| phenaproxima (he/him) |
We should remain standardized on those. If we need to use config entities for persistence/UIs, hide the shit out of them (edited) |
| wimleers (he/him) |
@phenaproxima (he/him) So we should use YAML plugins only, and not config entities is what you’re saying? |
| phenaproxima (he/him) |
Not exactly. I’m saying we should use the most appropriate tools for given needs, and make sure the boundaries are extremely clear and well documented. |
| phenaproxima (he/him) |
Clearly, config entities bring some benefits that plugins don’t. But by the same token, plugins bring benefits that config entities don’t, which we know from experience. |
| phenaproxima (he/him) |
So we have ended up with what looks, essentially, like “two ways of doing it”. That’s confusing. |
| heddn |
it would be nice to make it clearer/cleaner. |
| quietone |
The documentation, https://www.drupal.org/docs/8/upgrade, does not discuss migrate_run at all. (I though I had added it in a few places). I agree that the two methods need to be explained so people can make an informed choice. |
| wimleers (he/him) |
Based on https://understanddrupal.com/articles/how-debug-drupal-migrations-part-1, the only way to debug migrations without using xdebug is to insert the log or debug process plugins into your process chain. Does a better way exist? |
| mikelutz |
I think xdebug IS the better way. The migration system notoriously absorbs exceptions and logs very little. It’s something I’ve tried to work on, but have struggled with actually getting traction on. If you look at the migration_lookup process plugin, for example. I’ve recently rewritten it to use a new migration lookup service. The new service throws appropiate exceptions, but the plugin has to absorb and ignore all of them for BC reasons. My goal is to eventually deprecate that plugin and replace it with one that passes the exceptions, and fix the core migrations to use it, and use it properly. |
| mikelutz |
There’s tricky issue there though too. The main reason we absorb exceptions in the plugins is because the executable is doing things with data, and we really don’t want to throw an exception that the executable can’t catch and then perform a graceful shutdown from. Which means we probably need more Exception types in the migration system, and a logger in the executable. |
| phenaproxima (he/him) |
We 100% need to overhaul error handling in the system. xdebug is NOT appropriate for users. |
| alison |
I find xdebug difficult to use (prob bc I don't use it almost ever), and I think building and migrations is a way more common task that eeeeeeverybody needs to be able to do, so debugging should be more within-reach than xdebug is. (edited) |
| phenaproxima (he/him) |
Absolutely 10000% agree with @alison. We need to give proper error reporting that gives users clear, actionable information. |
| alison |
Considering that there's so much debugging value to using xdebug...... Is it possible to use xdebug "behind the scenes" to help users debug migrations? (No I don't know what that means.) (edited) |
| phenaproxima (he/him) |
@alison I wouldn’t think so. My reasoning is that xdebug is a tool. It gives information, but it doesn’t give a course of action. |
| phenaproxima (he/him) |
What users need, when migrating, is “hey, something is wrong here, what can I do about it?” |
| phenaproxima (he/him) |
IMHO. |
| alison |
Ahhh ok. I see what you're saying. I wasn't thinking of that, I was thinking of the information providing part. |
| phenaproxima (he/him) |
It can definitely provide information, but the information it provides is like “the variables looked like this at one point”, which won’t mean much to users. |
| alison |
Like, it would be cool to be able to get as much info if you debug from your drush commands as you would get if you were using xdebug. |
| alison |
Gotcha. |
| phenaproxima (he/him) |
I think what we should aim for is something like: “I couldn’t migrate the article ‘Foobar’ because an error occurred: ‘The text format is not valid.’ This probably means that one of the fields in the node is using a text format that doesn’t exist. The available text formats are: blorf, wambooli, pastafazoul.” (edited) |
| phenaproxima (he/him) |
The kind of compiler errors we all wish existed =P |
| alison |
Ohhhh ok. |
| phenaproxima (he/him) |
That’s what I would like to see, personally. Not sure how realistic or useful such a thing would be to other people =P |
| alison |
Hmmm... Providing actionable info sounds awesome, and also a pie-in-the-sky dream I wouldn't have thought of -- my "pie-in-the-sky" analysis isn't based on Facts, tho, I would've just assumed it was Too Hard to build that kind of system, given all the (seemingly?) unpredictable stuff going on in different ppl's migrations.I think I see super informative debug msgs like what I'm imagining ppl get from xdebug as being indirectly actionable, when combined with documentation........... To be fair, this conversation is the first time I've given it any thought. |
| phenaproxima (he/him) |
I mean, you’re right that there’s a point beyond which it’s too hard. But right now, it’s at the other extreme — we swallow errors entirely, don’t log anything, and shit is just broken on the other side. |
| phenaproxima (he/him) |
Even a hint is better than nothing. |
| mikelutz |
I am very +1 for improving logging. What I want to make sure isn’t happening is process plugins throwing invalid argument exceptions that kill the process because the executable can’t catch and handle them. We need to seriously look at the way we handle exceptions in general. We intentionally use them as signals all the time which is disgusting. The intentional signals should be converted to a better api, and the actual errors and exceptions need to be organized, handled at the executable level with appropriate logging and decision making about when to skip and continue and when to bail and shutdown, and what to log and where. |
| phenaproxima (he/him) |
@mikelutz Agreed. Exceptions are bad for signaling. What we should do is create a new class of error — user-facing, loggable errors. |
| phenaproxima (he/him) |
MigrationException, which contains good, useful information about what went wrong, where, why, and how it might be fixed. |
| mr.baileys |
Besides xdebug, there also is https://www.drupal.org/project/migrate_devel which can be handy to see what’s happening in the process pipeline. Or var_dump() :) |
| chriscalip |
How about using REPL eg. drush php instantiate/retrieve-service-containers the migrate objects to check/execute .. just like in everything else in software development land |
| wimleers (he/him) |
@mr.baileys Yep, I’ve seen that too! That module’s --migrate-debug-pre is the closest I’ve seen yet to a “dry run” mode |
| heddn |
Do we need to stage a sprint or a hangouts call (with a scribe) to plan out some better architectures for migrate? We had a small BOF at Midcamp earlier this year. Would doing something like that help out? |
| mikelutz |
I’m getting the distinct impression that a spiky haired Belgian threw some Acquia OCTO talent this way. I’m happy to do some sort of onboarding zoom if that is the case, @wimleers (he/him) |
| heddn |
ergo my question. I'm not opposed. Actually, getting over my natural and initial reaction of, "we've never done it that way before..." |
| alison |
O rly?? That's pretty cool. |
| heddn |
I think some of these ideas are really great. At least they could use some discussion and surface the gems that deserve the most attention. (edited) |
| mikelutz |
I think these are all issues that have been on our minds for a while, just haven’t been able to get the attention they deserved. |
| alison |
Isn't that always the way |
| wimleers (he/him) |
Yes, we all wished for 48-hour days |
| wimleers (he/him) |
And yes, @gabesullice and I will be looking into Migration-related problems for some time to come |
| wimleers (he/him) |
To be clear: it’s SUPER impressive what the Migrate system can do! |
| wimleers (he/him) |
But some things look rather odd to somebody who’s looking at this with A) fresh eyes, B) eyes that have been trained in minimizing PEBKAC risk |
| mikelutz |
@wimleers (he/him) I’ve long wished I could work on it full time. I’m only sponsored a few hours a week, plus whatever I can justify as part of my billable work (which is migrations for the forseeable future, so that helps) |
| wimleers (he/him) |
So I’m asking a lot of questions to understand why some architectural decisions were made. I suspect many times the answer is going to be “Because that’s how the D7 module did it” or “Because of time constraints”. |
| wimleers (he/him) |
Which is true for any software project. And it’s true of Quick Edit, Entity API, Field API, REST module, and I can keep going |
| mikelutz |
We aren’t as bad as views….. |
| mikelutz |
I pmed you my email, @wimleers (he/him) in case you ever want to set up a zoom to go over things. |
| heddn |
@wimleers (he/him) @mikelutz @phenaproxima (he/him) we should schedule a call then sometime to brain dump and do some backlog grooming. |
| wimleers (he/him) |
It’s not a matter of badness. It’s a matter of choosing to work on what has the biggest impact for the people working on it. And so far it’s been super highly skilled developers using Migrate. In order to get more people to migrate from 7 to 8, I believe we need to make it feasible for less technical people to also successfully migrate. All my questions relate to that |
| phenaproxima (he/him) |
Absolutely, 100% agreed. |
| mikelutz |
@wimleers (he/him) I assume you’ve seen #3061689: Improve the usability/developer experience of the Migrate system by addressing common problems , but if not, then that is the place to start on what you are talking about. |
| heddn |
if possible, a time when @quietone can join |
| webchick |
Would you folks like me to take on setting up a Doodle? |
| webchick |
quietone + wimleers in the same call will probably be nigh impossible, but let’s give it a shot. |
| quietone |
Sure, let's try |
| wimleers (he/him) |
@mikelutz I had not yet seen #3061689: Improve the usability/developer experience of the Migrate system by addressing common problems, thanks for that! |
| LOBsTerr |
I'm sorry, if my question is out of the scope of this meeting, but it is really hard to find information. Why do we have two ways to expose migrations 1) Using "migrations" folder and 2) is as a config entity (install folder), which is the the history behind ? What is the best practice here ? |
| heddn |
It is a bit dated, here's some rational: https://mtech-llc.com/blog/lucas-hedding/config-management-migrations |
| alison |
(For next time -- mtg topics go in thread !) |
| mikelutz |
As far as Drupal core is concerned, migrations are plugins that go in the /migrations folder. Migrate Plus (contrib module) creates a way to work with them as config entities for convenience, but they are converted back to plugins for core to run. |
| LOBsTerr |
@alison ok, I will. Thanks |
| LOBsTerr |
Thanks for answers! |
| phenaproxima (he/him) |
I am against the fact that there are two ways, personally, but @heddn insists on it. :) |
| mikelutz |
^^ same. |
| alison |
I found it super confusing (what's what?!) and then annoying (extra config that doesn't do anything and keeps showing as overridden??) and then I stopped caring (bc "other stuff") and then I seriously forgot all about it (legit didn't know what you were talking about at first).The four stages of ____ (working on an end to that sentence). (edited) |
| mikelutz |
My frustration with the system as a maintainer is just trying to get people to fully understand the difference. @LOBsTerr thankfully recognized that one is a config entity and one isn’t. because they look the same, many people feel like it’s just two different folders you can put a migration, and can’t understand why one requires a cache clear and the other requires a module reinstall. |
| phenaproxima (he/him) |
Exactly. Because two parallel systems is not good |
| phenaproxima (he/him) |
Honestly, one mitigation would be to mark the config entity type as internal (edited) |
| mikelutz |
Core uses plugins, which are defined as yml configuration files applied to a base plugin class. They can also have derivers, which will generate multiple plugins from one definition. Migrate plus uses one empty plugin definition and a deriver to generate plugins for each of the config entities it manages. When you understand that process, you can start to see the differences in handling, and why certain caches need to be cleared and when. |
| mikelutz |
Internal to migrate plus? |
| phenaproxima (he/him) |
Yeah, internal to whatever module provides them. I think entity types can be explicitly marked as internal. |
| wimleers (he/him) |
Yeah, internal to whatever module provides them. I think entity types can be explicitly marked as internal.That internal flag just means that it won’t be exposed via REST/JSON:API.\Drupal\content_moderation\Entity\ContentModerationState is an example of that.But I don’t think that’s the meaning of “internal” that you’re looking for, @phenaproxima (he/him). What you’re saying sounds more like @internal as it relates to code. |
| phenaproxima (he/him) |
@wimleers (he/him) True. I don’t think I read the documentation for EntityTypeInterface::isInternal(). |
| phenaproxima (he/him) |
Which, checking now, absolutely makes that distinction |
| Joshua Turton (srjosh) |
All that being said… migrate plus offers us the ability to use migration groups, which is critical and therefore it is (IM-not-so-humbleO) best practice to use MP’s process across the board. |
| phenaproxima (he/him) |
I don’t think migration groups are at odds with plugins. |
| phenaproxima (he/him) |
At least, not as I understand migration groups, which might be flawed. |
| Joshua Turton (srjosh) |
no, but… you have to put the YML files for groups in the config directory. If you follow that process for groups, but then put the migration files somewhere else, that’s… bad. |
| phenaproxima (he/him) |
If we switched away from plugins, not only would that be full of painful BC implications/breaks, but we would lose critical functionality |
| Joshua Turton (srjosh) |
Oh, I understand. What I’d rather see is a plugin-based functionality for migration groups. Until that day, I’m going to continue to recommend that people follow the migrate plus paradigm and keep all the YML in one place. |
Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Comments
Comment #2
mikelutzComment #3
mikelutzComment #5
mikelutzComment #7
mikelutzComment #9
mikelutzComment #11
mikelutzComment #13
mikelutzComment #15
mikelutzComment #16
mikelutzComment #18
mikelutz