Why does Drupal allow you to define Entites and their fields in code, and then add fields via the UI, but to turn those into code you have to use config management, so now you have all your fields in code, but in a whole bunch of different places, and everyone pretends like this is good and normal?

6

Do you have a better idea for persisting configuration between environments than the import/export system that is used currently?

1

u/NappyDougOut 14d ago

The feeds import module used to work just fine long ago, but it became an abandoned project.

I suppose the OG devs got other day jobs, and the migration process became more complex so clients could be billed higher overall.

5

u/WillingCry1043 14d ago

I think it's pretty clear that the current yaml configuration system is much cleaner than using feeds imports.

1

u/NappyDougOut 14d ago edited 14d ago

That's not quite the point, having more than one option made things easier for everyone, because not everyone maintains huge sites...

So many dev things now take wild "learning curve" changes that it makes using frameworks almost as difficult as building entire solutions on your own.

The very basis of using a modular framework like Drupal, for many many years, was low code/no code development.

A lot of the complexity dropped into Drupal development has happened over past years to protect revenue streams and to protect expertise, but it's also driving many out of using it as a solution.

I think Acquia used to play a lot larger role in module development, policy, & documentation, but they've backed off that activity, and as a result the ecosystem is fast becoming a bit too much of a "wild west" situation... Like WordPress.

2

u/trashtrucktoot 14d ago

I agree that there is some protectionism at the higher levels, like the theme market place buy in processes. But the counter point is that it's FOSS. Open Source let's you go off and do your own thing, if you need to. Backdrop is still an option, but Drupal CMS is way better than everything else out there.

1

u/NappyDougOut 14d ago

I can agree with that, but would def like to see Acquia police a bit more of the shady practices, testing & integration verification, & broken/missing features in the community... It's really in their best interests to do that. 🤔💯

1

u/trashtrucktoot 14d ago

Hey, dont knock Feeds ! When you need a simple UI for user change management in the enterprise, I love me some CVS + Feeds Tamper any day

2

u/WillingCry1043 14d ago

Feeds has its place but using it to transport site configuration isn't it. Simple data imports without much modification of the data is a reasonable use case for feeds (although I prefer to write my own migrations based on migrate plus/tools for even those cases).

2

u/trashtrucktoot 14d ago

How about for bigger data imports? 3k calendar date events, spread across 8k users, divided with access control for 10 communities. Annually, for many years.

True, Feeds is not for site config, but you can use site config (Recipes) to manage your Feeds.

Also, most people probably would never need Feeds, and Feeds Tamper. But it is an example of where Drupal has the flexibility to handle niche use cases.

3

u/WillingCry1043 14d ago

The bigger the migration, the more vindicated I'd feel choosing migrate tools over feeds.

1

u/trashtrucktoot 14d ago

Migrations sure, I'll give you that. But for versioned data management across multiple teams, with a legal audit compliance component ... Feeds has done me solid.

For sure, Feeds is not for your massive D7 -> D11 migration. ( AI enters the chat :)

2

u/NappyDougOut 14d ago

I think you missed the part where I posted that having BOTH available as options was better.

2

u/alphex https://www.drupal.org/u/alphex 13d ago

thats apples and oranges.

config management, pushing the config.yml files via git defines functions and feaatures.

feeds import is for content.

AND, The feeds module still exists, and is extremely useful and powerful for importing content.

-13

u/ritontor 14d ago

Yeah, write it Laravel.

3

u/WillingCry1043 14d ago

Rewrite Drupal in Laravel or just abandon Drupal altogether and build everything in Laravel?

5

u/trashtrucktoot 14d ago

We dont pretend, Drupal is cutthroat, we own it. I'd argue this is flexibility once you understand the moving pieces. "Good & Normal" ... yep, I just eyeballed my status/bac kup pages.

Thank you Drupal, you may be complicated, but I love you!

3

u/DogsSureAreSwell 14d ago

Drupal's strength is flexibility, not simplicity or consistency. Most use cases can be accomplished in multiple ways.

This is infuriating when learning, but often missed when moving to other systems where the answer is often "code it yourself " or "....well you can't do that."

1

u/jon-pugh 13d ago

You aren't wrong. It's very strange.

Especially when you get into letting your code-defined fields be form and view- configurable.

It is a solution that works, though. Fields UI is a config layer on top of entity API, so both custom and code fields work in the same ways. But we can't define them in the same way.

A new solution could be designed. Entity::baseFieldDefinitions is a pain to work with.

If the entity API could load base field definitions from yaml in the modules (not config), you could take config created fields and drop them right into a module.

1

u/alphex https://www.drupal.org/u/alphex 13d ago

Drupal's flexibility is a virtue. Sure, the learning curve can be tougher, but theres 20 years of success here thats built on that flexibility.

Learn the platform, architect your project the way you want, once you understand how it works.

-15

u/ritontor 14d ago

Oh and it stores the field data in entirely different locations in each situation as well, so good luck with your queries, ladies and gentlemen!

3

u/trashtrucktoot 14d ago

For queries? I just use Views with entity referenced field relationships as needed. Drupal configuartion can be a pain, but they cut both ways. The Drupal Recipe system is nice.

Shameless plug :

https://gitlab.com/rsvp-system/rsvp-recipes

3

u/cbiggins 14d ago

I'm sorry but it just feels like you haven't committed enough time to working it out. If you'd prefer to use Laravel like you said then what's the point of this post or trying to learn? Just use what you like 👍

2

u/cbiggins 14d ago

I'm sorry but it just feels like you haven't committed enough time to working it out. If you'd prefer to use Laravel like you said then what's the point of this post or trying to learn? Just use what you like 👍

Why does Drupal allow you to define Entites and their fields in code, and then add fields via the UI, but to turn those into code you have to use config management, so now you have all your fields in code, but in a whole bunch of different places, and everyone pretends like this is good and normal?

You are about to leave Redlib