I've just ported one of my D7 modules, Views Contextual Range Filter, to D8. Phew! That took longer than I'd hoped.
In terms of the effort, I'm not referring to us developers having to convert our .info files to .info.yml files. Or that for configuration variables our trusty mymodule_settings() function now needs to return system_config_form($form, $form_state) and that we have to do the saving of our config variables ourselves in another function, using the new API that came out of the CM initiative.
Those were the obvious and the easy bits.
I'm talking Views.
At the time of writing, nothing in this lovely porting tutorial prepares a developer for what they'll face when they port a D7 module that interacts in a big way with Drupal's biggest module, Views.
Views, blocks and the config stuff have plunged deeper into OO through Symfony.
If you're an ex-Java developer like me, then for Symfony read Spring (dependency injection, annotations etc) and you should be right… after the initial shock ... And after a few days of poking, trying to figure things out and reworking your code.
If you only know enough OO to get by in D7, then brace yourself for a brush-up. Big time. Expect to see more of the :: symbol and of that function return chaining thingy (->) so popular in Ruby. If you don't know what I'm talking about, then you're getting my point exactly.
With CTools gone and Views Symfonised, we're not just talking symbols and name changes here. Most of your D7 Views code will be broken: your handlers, plugins, argument code… pretty much everything… Some D7 hooks are gone. Some View data publicly available in D7 is now protected, so new access functions are required to get to it and manipulate it.
Finding where to start can be a daunting task in itself. Your D7 class views/handler/views_handler_argument_numeric.inc for instance, looks and feels different and lives in core/modules/views/lib/Drupal/views/Plugin/views/argument/Numeric.php. Makes sense? Not to me either. Not at first.
With their Symfonication, the new Views parts have also adopted CamelCase notation rather than lowercase plus underscores. Yep… We now have double coding-standards. What is the Coder module going to recommend, I wonder?
The good news? Revisiting your old code is an opportunity to get it right the second time. And Symfony is cool.
So, coming out at the other end of that tunnel, your code does shine a little brighter. Cleaner. And ready to take on the future.
Rik
Comments
What you linked to as a 'D7
What you linked to as a 'D7 to D8 conversion' tutorial isn't documentation at all. Frankly I'm not interested in some comical non-module walkthrough of developer humor, I want a concrete list of steps and documentation of what you have to do. They wonder why people don't get their modules converted in time for each major version up (remember D7?) this is a big reason why. Even seasoned developers are saying 'wtf am I supposed to do??' because the documentation just isn't there.
I do not want to watch a video.
I do not want to rifle through a bunch of commit history.
I do not want to look at a slideshare from a conference.
All of that is copypasta style - I do not want to learn that way! I want to have a solid grasp on this so I can actually do it proper, understand what the changes are and why they are, and know what to use and when. Look, people even expressed this at the last major release.
http://drupal.org/update/modules/7/8
So it begs the question - if there are no solid docs pages, how are core developers converting modules? Where is this written up? How do I know when I need to include new files, use the 'use' namespaces, need to know when to use Symfony classes etc in code? I have absolutely no clue where to start, and I would totally convert everything TODAY and help with core TODAY but there is no documentation whatsoever!!!
On the whole it's really frustrating because we're asked to upgrade to D8 so launch is smooth with contrib options, but they aren't exactly helping the process either.
Thanks!
Thanks for sharing! I've been putting this off myself...
Drupal "upgrades"
Only in Drupal is it so celebrated to spend hours and hours and hours every "upgrade cycle" (let's call it what it is - "rewrite") only to come out the other side with no increase in functionality (or even particularly, performance). As Drupal gets more bloated, this only gets worse.
Routes
I think you also have to retire hook_menu and create routes :D
Coding standards
I could be mistaken, but I was under the impression that Drupal 7 coding standards are to have functions and variable in lowercase with underscores and use camelcase for object properties and methods to help distinguish between them, so really that at least hasn't changed. I imagine Coder already validates these correctly based on whether it's a function/method etc.
Coding standards