You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This could be a PM in Drupal slack but I think that the discussion will benefit everyone. I personally haven't really understood who is going to benefit from the effort of developing this module - though I don't take your effort on it lightly at all. I can think of some benefits but nothing like "Simple D7 to D10 transition" as it's advertised in most articles.
A Drupal website depends on at least the following:
Structure
Code
Database
Content
Theme
For a transition from D7 to D10 we need the following:
Install a new Drupal instance (using a newer PHP version etc) to obtain the new database structure
Migrate the structure of the website (so that new field tables of Content Types get created)
Migrate the content of the website (usually requires the Migrate module)
Change the code of the website (change modules used, upgrade code to newest hooks/events/yml etc.)
Change the old theme to the newest version (PhpTemplate -> Twig, drupal_add_css() and drupal_add_js() to libraries.yml etc).
For any one of the above to work, the implementer (developer or other) still has to know which is the correct way of addressing each problem:
Static or dynamic SQL queries in custom modules or themes will have to change since the fields' tables have changed
Inline JS code will have to be properly modified with drupalSettings or other mechanisms
Themes of the D7 epoch don't have a stable D10 version anymore (eg. Zen, Omega5)
Tricks where field_attach_update('node', $node) along with entity_get_controller('node')->resetCache(array($node->nid)) was used.
Other things like loading blocks, menus, views in templates etc.
So, to sum up... For most of the scenarios above, the implementer should know which is the correct way. In order to know it, the implementer should also know how to achieve it - how to develop it on his/her own. So, what is the thinking behind developing this module - apart your research and study I mean? Could you provide us a few Use Cases & Examples where or to whom this module would be helpful and at what level a full solution is expected? This is something I would greatly appreciate in a README.md file - even as a simple mention to this issue.
The text was updated successfully, but these errors were encountered:
I'll work on more concrete answers, but I wanted to at least answer in some way right now:
For any one of the above to work, the implementer (developer or other) still has to know which is the correct way of addressing each problem:
The idea is to take this from 100% to 60% or even 50%. That way organizations can upgrade to Drupal 10 faster without being hit by the EOL during development. Once running on D10 post-data migration, they can refactor legacy code off of the Retrofit for Drupal provided compatibility layers.
"PhpTemplate -> Twig" This is already supported, themes are not quite there yet
"Themes of the D7 epoch don't have a stable D10 version anymore" This is true, nothing can be perfect
"Other things like loading blocks, menus, views in templates etc." These will be added
I am working on documentation to explain covered APIs. But right now existing hook_menu will translate to the new routing + menu APIs. hook_block_* turns into new block plugins. Even forms work. You may need to refactor some of the code.
But the idea is to allow precise refactoring, not a wholesale rewrite.
This could be a PM in Drupal slack but I think that the discussion will benefit everyone. I personally haven't really understood who is going to benefit from the effort of developing this module - though I don't take your effort on it lightly at all. I can think of some benefits but nothing like "Simple D7 to D10 transition" as it's advertised in most articles.
A Drupal website depends on at least the following:
For a transition from D7 to D10 we need the following:
For any one of the above to work, the implementer (developer or other) still has to know which is the correct way of addressing each problem:
field_attach_update('node', $node)
along withentity_get_controller('node')->resetCache(array($node->nid))
was used.So, to sum up... For most of the scenarios above, the implementer should know which is the correct way. In order to know it, the implementer should also know how to achieve it - how to develop it on his/her own. So, what is the thinking behind developing this module - apart your research and study I mean? Could you provide us a few Use Cases & Examples where or to whom this module would be helpful and at what level a full solution is expected? This is something I would greatly appreciate in a README.md file - even as a simple mention to this issue.
The text was updated successfully, but these errors were encountered: