I recently came across this change record for D8: https://www.drupal.org/node/2952947
What this has done in short is that it has allowed installation profiles to specify install
dependencies in addition to the preexisting dependencies
. D8 uses .yml files, but here's how that could look in .info files:
name = Standard
description = Install with commonly used features pre-configured.
version = BACKDROP_VERSION
backdrop = 1.x
install[] = admin_bar
install[] = ckeditor
install[] = comment
install[] = dblog
install[] = views_ui
install[] = update
dependencies[] = node
dependencies[] = block
dependencies[] = color
dependencies[] = config
dependencies[] = contextual
...
The dependencies
array would be treated as a set of "hard" dependencies, meaning that they cannot be uninstalled, because the profile depends on them. If the profile simply wants to specify a list of modules to install, but upon which it does not actually depend, it can use the install
array.
To maintain backwards compatibility, profiles which only define a dependencies
array, but not an install
array, would have their list of dependencies treated like an install
list. This backwards compatibility layer could be removed in Backdrop 2.0, which should allow enough time for profile authors to separate their install
list from their actual dependencies.
Recent comments
Today there was finally time to delve into this issue. First I downloaded the field_data_taxonomyextra table into a spreadsheet. There is a column called Bundle, which in my case included,...
taxonomyextra table after migration from Drupal 6
Hi Enthusiast - there is work in progress on an improvement to core that I think will help this. https://github.com/backdrop/backdrop-issues/issues/4127 I don't fully understand it...
The problem of caching the pages
As time ran out to discuss this last week, I would like to discuss https://github.com/backdrop/backdrop-issues/issues/6900 (Pre-existing field with reserved entity machine name re-used on entity...
May 22nd Weekly Meetings