Here's a list of notes I took in the Prague presentation prep we did on Friday with Alex and Jess. These are not necessarily things we should do, but things we could discuss as they are all things that stood out to me.

TODO: Get rid of getFormID(): #2089593: Have FormBase auto-generate form IDs, so you don't need to implement getFormID() on all forms
TODO: Move SystemConfigFormBase to Form namespace: #2089627: Move \Drupal\system\SystemConfigFormBase to \Drupal\Core\Form\ConfigFormBase
TODO: Change pattern => path #2051097: Change "pattern" to "path" in *.routing.yml files
TODO: Add a config() method to SystemConfigFormbase so you don't have to see horrible awful HORRIBLE stuff like $this->configFactory #2087279: Add a config() method to FormBase
TODO: How do translate field settings (e.g. "On" and "Off") in CMI files
TODO: Options field allowed_values should be type: text not type: string
TODO: Drop IdentifiableInterface :P just put id() in EntityInterface
TODO: Fix docs in api.php to typehint properly (e.g. UserInterface)
TODO: \Drupal:: everywhere #2053489: Standardize on \Drupal throughout core
TODO: Find DIC tetst issue from alexpott?

CommentFileSizeAuthor
#9 installererror.png101.81 KBCyclodex

Comments

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Issue tags: +DX (Developer Experience)

.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Issue summary: View changes

Updated issue summary.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

As an update, we nailed the following easy things tonight:

#2089627: Move \Drupal\system\SystemConfigFormBase to \Drupal\Core\Form\ConfigFormBase
#2087279: Add a config() method to FormBase
#2051097: Change "pattern" to "path" in *.routing.yml files
#2053489: Standardize on \Drupal throughout core
#1614186: Coding standards for using "native" PHP classes like stdClass in namespaced code

Still in the process of writing up some of the issues, but got a tentative +1 for IdentiyInterface from fubhy in IRC, so that's a start! :)

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Title: [Meta] Clean up DX issues found in porting Pants from D7 to D8 » [Meta] Clean up DX issues found in porting modules from D7 to D8

Re-purposing this issue for our DrupalCon Lab.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented

Coming from #1969572: Make Uuid a service, a few more things stood out over there:

       \Drupal::service('event_dispatcher'),
       \Drupal::service('config.factory'),
       \Drupal::entityManager(),
      \Drupal::lock()
      \Drupal::service('uuid')

a) We really, really need to make some firm guidelines on when to use Drupal->service('uuid') and when to do Drupal->uuid(). Something simple like "If it's used from more than two places" or whatever would work for me. I know there's another issue to discuss this, I'll try and find it and cross-link it in the summary.

b) Why sometimes event "underscore" dispatcher and sometimes config "dot" factory? We should standardize on service names like we do on router names. There's also a separate issue for that.

     $this->storageComparer = $storage_comparer;
     $this->eventDispatcher = $event_dispatcher;
     $this->configFactory = $config_factory;
     $this->entityManager = $entity_manager;
     $this->lock = $lock;
    $this->uuidService = $uuid_service;

A few things here:

c) "configFactory" seems like leaky abstraction to me. Why do I care if you implemented config as a Factory pattern or a Singleton pattern? I care about needing config in my class.

d) Similarly, I'd make uuidService just "uuid."

e) Less sure about "entityManager" but seems like it might be the same thing?

Eronarn’s picture

Eronarn commented

Worst DX issue I ran into thus far: form array keys with periods getting eaten and not showing up in $form_state['values'], so instead having to assign period-containing config entries based on the not-period-containing array keys. (And because you don't get nested keys from $form_state['values'], you can't do something like concatenating ['values']['foo']['bar'] into 'foo.bar' in a loop.) This is error-prone, particularly if anyone needs to change that form later, and the DX for making a mistake sucks (you pull out a null value and set that, or you pull out the right value but set it in the wrong key). Some kind of helper or other magic would really help speed up construction of the most common kinds of forms.

Also, if I want to define an admin config form properly, I need to touch foo.routing.yml, foo_menu, foo_admin_path, and then still define the form ID in the form class. Yikes!

lorique’s picture

lorique commented

I ran into an interesting problem

I was trying to clear my config cache, because a config file wasn't showing up. So in order to force it, i deleted my files/config-xxxwhatever folder and i got a fatal error saying something to the effect of "cant find directory"

Fatal error: Call to a member function getDirectoryPath() on a non-object in /var/www/drupal/drupal8/core/modules/image/lib/Drupal/image/PathProcessor/PathProcessorImageStyles.php on line 34

I was unable to trigger a rebuild on these settings, and we should probably find a way to do this. If the settings files are just cache, we should be able to regenerate these files, if not i say we should have the settings in a cache somewhere in the DB as well. This could, potentially, also help during development because you would be able to bypass the cache.. like the d7 rebuild theme on page load thing.

aspilicious’s picture

aspilicious commented

The config direcotry is NOT a cache... It contains all the config and a cache clear uses THIS directory to FILL the cache :).
So yeah you should never delete those files, ever...

Eronarn’s picture

Eronarn commented

I managed to do something similar by using the GUI configuration sync tool when I had only one module's configuration file in the staging directory, not realizing that a missing file indicates 'delete'.

Cyclodex’s picture

Cyclodex commented
StatusFileSize
new installererror.png101.81 KB

Here the D8 installation issue I ran into - discussed quickly with webchick:

Starting issue:
My MAMP was not up2date and so I got the message, that my PHP Version is not Supported - so I downloaded the latest and installed it. Fine!

Installing D8
Without changing anything I downloaded D8 and wanted to install it... Everything fine until the modules are enabled/installed, there I got the following message, which hopefully should lead me to the error message or hint what was going wrong, but no success... (just Internal Server Error)
There is also a link "Please continue to the error page" - which was just a blank page then...
install error

I had to check my error log, which told me about the memory issue!

[25-Sep-2013 17:37:10 Europe/Berlin] PHP Fatal error:  Call to a member function get() on a non-object in /Users/gander/Sites/d8/drupal/core/lib/Drupal.php on line 241
[25-Sep-2013 17:37:40 Europe/Berlin] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 262144 bytes) in /Users/gander/Sites/d8/drupal/core/vendor/doctrine/annotations/lib/Doctrine/Common/Annotations/TokenParser.php on line 53

Sure the standard memory configured was way to low for Drupal8, but could we not provide the information, or even pre-check if enough memory limit is avilable.

More advanced:
Perhaps warn depending on the profile you install ? - because the minimal profile worked fine!

At least we should try to help better with the message, don't you think?

Eronarn’s picture

Eronarn commented

@Cyclodex Fortuitous - I forgot that I had something similar occur several times, except in my case it was due to a 30 second PHP execution limit. Also, in my case hitting 'continue to the error page' just brought me to the next installation step with no indication of whether any configuration had actually failed to complete.

mmilano’s picture

mmilano commented

Here's a DX issue based on a recent challenge of figuring out the proper way to add a non-base field to a module that provides a custom entity.

#2107645: Adding non-base fields to entities

blackra’s picture

blackra commented

I promised webchick that I would give some feedback from the BADCamp 2013 Drupal 8 module session on 26th October.

  1. Disabling modules is broken. I spent a while trying to work out how the [broken] module I had just installed had broken it, not realising that it was a known issue. It didn't occur to me to look in the uninstall tab because the Drupal 7 behaviour only allows uninstalling disabled modules.
  2. I spent a lot of time trying to debug a problem with a unit test. It turns out that the problem was that D8 core requires a lot more memory than D7. Again, this is not immediately obvious. I experienced a WSOD opening Administration->Configuration->Development->Testing running with a 128M limit and Drupal 8 core and 1 extra module. I am not sure how developers can be informed of the extra resource requirements of D8.

    I did look to see whether I could find it in any of the documentation I "should have read". Unless it is on display in a locked filing cabinet in a disused lavatory...

  3. The module system does a lot of failing silently if you get something wrong. This always used to be a problem in D7 (coming from a non-Drupal software background this is one of my least favourite Drupalisms) but D8 has even more files "loaded by magic" for people to get wrong. Experienced D8 developers seem either to have checklists to deal with this, or to cut and paste "magic incantations" from other modules until something works.
  4. I do have some positive comments. For a non-Drupal developer, D8 is clearly much better engineered and more pleasant to work with than D7. The use of abstraction layers means I don't have to fry my brain again trying to learn everything at once. Yay!
  5. The installation process for D8 feels much more friendly than for D7 (and views and chaos tools and all the rest of the things you need to remember...)
blackra’s picture

blackra commented
Issue summary: View changes

added FormBase::config()

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
commented
Issue summary: View changes

Change record entity_get_info() deprecated. Use \Drupal::entityManager()->getDefinitions() it is not possible to get to the data-set a ConfigEntityType has.

Thus added child page #2304863: EntityType should support toArray()

As this meta issue is referred from https://www.drupal.org/community-initiatives/drupal-core/d8dx as the place to be I wonder why we have way more open DX issues in the queue.

Is this issue still actively monitored? How can I help?

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented
Status: Active » Closed (outdated)

Feel free to re-open, but there hasn't been any comments here since 2013 and many things from the issue summary have been addressed and others are likely not possible due to BC. Just create new issues if you want to improve something.