To remove dependency to Classy, we need to ensure core theme aren't relying on any markup in Classy. #3096349: Create test for confirming Themes do not depend on Classy templates has added test coverage to ensure that markup isn't being inherited from Classy. Currently, lots of templates have been added as ignored.
Ensure all templates have been removed from the skip lists, and copies of those templates exist in core themes.
According to the documentation of \Drupal\Core\Entity\EntityTypeInterface::getHandlerClass() the method should return NULL if a handler class is not set.
We never test for this outcome.
Add a test case to Drupal\Tests\Core\Entity\EntityTypeTest to ensure that a NULL result is possible.
Both \Drupal\layout_builder\Form\DefaultsEntityForm and \Drupal\layout_builder\Form\OverridesEntityForm provide a base form ID to allow hook_form_BASE_FORM_ID_alter() implementations to target both of them, in addition to their individual form IDs.
However, DefaultsEntityForm uses the wrong method when generating the base form ID.
Given nodes and users, the respective base form IDs should be:
node_layout_builder_form
node_layout_builder_form
user_layout_builder_form
user_layout_builder_form
They actually are:
node_layout_builder_form
entity_view_display_layout_builder_form
user_layout_builder_form
entity_view_display_layout_builder_form
Fix DefaultsEntityForm::getBaseFormId()
Write tests
N/A
N/A
N/A
N/A
When I enable translation for a content type. And then create a node of that type and then when I edit that node, I see the following notice on my site.
Notice: Undefined variable: source_langcode in Drupal\content_translation\ContentTranslationHandler->entityFormAlter() (line 415 of core/modules/content_translation/src/ContentTranslationHandler.php).
Drupal\content_translation\ContentTranslationHandler->entityFormAlter(Array, Object, Object) (Line: 18)
Drupal\node\NodeTranslationHandler->entityFormAlter(Array, Object, Object) (Line: 400)
content_translation_form_alter(Array, Object, 'node_living_unit_edit_form') (Line: 539)
Drupal\Core\Extension\ModuleHandler->alter('form', Array, Object, 'node_living_unit_edit_form') (Line: 836)
Drupal\Core\Form\FormBuilder->prepareForm('node_living_unit_edit_form', Array, Object) (Line: 418)
Drupal\Core\Form\FormBuilder->rebuildForm('node_living_unit_edit_form', Object, Array) (Line: 627)
Drupal\Core\Form\FormBuilder->processForm('node_living_unit_edit_form', Array, Object) (Line: 320)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 91)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 573)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 694)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)I updated the Drupal core using composer from 8.8.0 with the following steps
composer update drupal/core:^8.8.1 --with-dependencies
Migrate the revisions for d7 entity translation to d8. This is moved out of #2746541: Migrate D6 and D7 node revision translations to D8, which is now only about node translation, to reduce complexity.
This issue is intended to be completed after #2746541: Migrate D6 and D7 node revision translations to D8.
Use the node master plugins that are introduced in #2746541: Migrate D6 and D7 node revision translations to D8.
A new test fixture is introduced here so that the table entity_translation_revisions exists. For unknown reasons that table does not get populated when using the current drupal7.php fixture. The new one, drupal7_et.php has a content type using entity translation and one that does not and both have translation revisions.
The patch in #28 is merged with2746541-231.patch from the node translation revision issue so that it is available for testing.
After installing Drupal Core there is a horizontal scrollbar on the Extend page at /admin/modules.
Update the css so the Extend page does not display a horizontal scrollbar.
Update the css so the Extend page does not display a horizontal scrollbar.
None.
None.
The BC layer for revision metadata keys has been a source of dozens of lost hours and frustration for Entity API maintainers...
Follow-up to #3111506: Properly deprecate _access_rest_csrf route requirement
As the requirement were not properly deprecated before 9.0 it was moved to d10 removal
Remove route requirement
Remove test module and test case
wait 10.0.x branch and remove
no
no
no
no
I've tried to install Drupal 7 on 2 separate systems using a PostgreSQL 9.0 database backend, and both times it has failed at the same point.
The error message in the PostgreSQL logs both times is:
ERROR: null value in column "rid" violates not-null constraint
STATEMENT: INSERT INTO role_permission (rid, permission, module)
VALUES (NULL, 'administer blocks', 'block')
I followed the instructions in INSTALL.pgsql.txt, and everything else
installs up to this point.
The actual error message returned on the installation page is:
An AJAX HTTP error occurred.
HTTP Result Code: 200
Debugging information follows.
Path: http://bison:8089/install.php?profile=standard&locale=en&id=1&op=do
StatusText: OK
ResponseText:
Home | Drupal
@import url("http://bison:8089/modules/system/system.theme.css?0");
@import url("http://bison:8089/modules/system/system.messages.css?0");
@import url("http://bison:8089/modules/system/system.menus.css?0");
@import url("http://bison:8089/modules/system/system.base.css?0");
@import url("http://bison:8089/modules/comment/comment.css?0");
@import url("http://bison:8089/modules/field/theme/field.css?0");
@import url("http://bison:8089/modules/node/node.css?0");
@import url("http://bison:8089/modules/search/search.css?0");
@import url("http://bison:8089/modules/user/user.css?0");
@import url("http://bison:8089/modules/system/system.admin.css?0");
@import url("http://bison:8089/modules/system/system.maintenance.css?0");
@import url("http://bison:8089/themes/seven/reset.css?0");
@import url("http://bison:8089/themes/seven/style.css?0");
Home
Installation tasksChoose profile(done)Choose language(done)Verify
requirements(done)Set up database(done)Install
profile(active)Configure siteFinished
SQLSTATE[25P02]: In failed sql transaction: 7 ERROR: current
transaction is aborted, commands ignored until end of transaction
block
Steps to recreate:
Gentoo x64 (2.6.31 kernel)
Apache 2.2.15
PHP 5.2.14
PostgreSQL 9.0.3
1) Run: wget http://ftp.drupal.org/files/projects/drupal-7.0.tar.gz
2) Extract using: tar xvf drupal-7.0.tar.gz
3) Create destination directroy: mkdir /var/www/drupal-7.0
4) Copy files: mv drupal-7.0/* drupal-7.0/.htaccess /var/www/drupal-7.0
3) chgrp -R apache /var/www/drupal-7.0
4) Run: createuser --pwprompt --encrypted --no-createrole --no-createdb drupal
5) Run: createdb --encoding=UTF8 --owner=drupal drupal
6) Run: psql -U postgres -c "CREATE SCHEMA drupal AUTHORIZATION drupal;" drupal
7) Change to drupal dir: cd /var/www/drupal-7.0
8) Change permissions on default sites dir: chmod a+w sites/default
9) Create settings file: cp sites/default/default.settings.php sites/default/settings.php
10) Update settings permissions: chmod a+w sites/default/settings.php
11) Update sites/default/settings.php file as per INSTALL.pgsql.txt with schema name, by adding this line: $db_prefix = 'drupal';
12) Navigate to webpage and follow installation.
13) Error appears as described above.
Screenshots of installation attached.
Installation appears to work fine when using a schema named anything but "drupal", or not using a schema at all.
In #3110296: Remove all @deprecated code from Drupal/Core/Access/ we intended to remove the _access_rest_csrf route requirement in Drupal 9. However, it was deprecated early in the D8 cycle and never had a trigger_error() deprecation notice added to warn developers. We should add this now and decide whether it is safe to remove in Drupal 9 or better to wait until Drupal 10.
The requirement is deprecated in 8.2 #2753681: Move CSRF header token out of REST module so that user module can use it, as well as any contrib module
With CR https://www.drupal.org/node/2772399
Add trigger_error() pointing developers to the change notice.
Patch and test the deprecation.
Decide when to remove this feature.
None
An already deprecated API will log a deprecation error.
None
The jQuery UI Position library is among the components that need to be removed/replaced as part of #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
It was determined in #3074267: Replace jQuery UI position() with PopperJS to use popper.js in place of jQuery UI Position for QuickEdit.
However, several other jQuery UI asset libraries depend on core/jquery.ui.position.
The following jQuery UI asset libraries are not used by core and will be marked deprecated before 8.8 is released.
#3067251: Deprecate unused jQuery UI components in favour of a suite of contrib modules
Once these other jQuery UI asset libraries are replaced (if used by core) and marked deprecated, core/jquery.ui.position should also be marked deprecated.
I'm using the following code in my custom formatter:
$result = '';
foreach ($variables['#items'] as $delta => $item)
{
if ($item['access']) {
$nid = $item['nid'];
$url = url(drupal_get_path_alias('node/' . $nid), array('absolute' => TRUE));
$entity_type = 'node';
$bundle = 'page';
$nids = array($nid);
$field_values = db_select('field_revision_field_optional', 'f')
->fields('f', array('entity_id', 'field_optional_value'))
->condition('entity_type', $entity_type, '=')
->condition('bundle', $bundle, '=')
->condition('entity_id', $nids, 'IN')
->condition('deleted', 0, '=')
->execute()
->fetchAllKeyed();
$text = $field_values[$nid];
$result .= '<a href="' . $url . '">' . $text . '</a>, ';
}
}
return substr($result, 0, -2);
With having devel's logging mysql-queries enabled I get the following error (its number of duplicates depends on number of values printed by formatter):Notice: Undefined index: args в функции DatabaseLog->findCaller() (строка 156 в файле /home/u9501/domains/progprofi.ru/includes/database/log.inc).
I don't know whose problem it is: mine, yours or devel module's?
Followup #2999612: Properly deprecate db_query_range
There's some overlap between how Drupal\Core\Utility\Error is determining the caller, and a similar functionality in Drupal\Core\Database\Log::findCaller.
Remove duplication.
How to properly make replacements in the next line of the code:
core/lib/Drupal/Core/Utility/Error.php:50: $db_functions = ['db_query', 'db_query_range'];
Hello,
Years ago, I had created an issue and worked regularly on a pull request on https://github.com/drupal-composer/drupal-scaffold to be able to scaffold files differently if the --no-dev option is used.
For example, I don't want config files of dev tools to be packaged for production.
So I created this issue: https://github.com/drupal-composer/drupal-scaffold/issues/57
And this pull request: https://github.com/drupal-composer/drupal-scaffold/pull/58
As the structure of the Composer plugin is quite different in Core from what is on https://github.com/drupal-composer/drupal-scaffold, do you think it will be possible to have a such feature in Core?
Thanks for any reply.
If I go to Structure > Menus, edit Main Navigation and add a new link, I get thrown back to Structure > Menus, so then I have to click edit on Main Navigation again, so I can order the item that I just entered. After adding new link, I should be in the specific menu, not in the menus overview.
Currently, the menu titles on Structure > Menus are just text. I suggest linking them to the "edit" action, like it was all the previous Drupal versions. This would be easier than moving the mouse all the way over to the edit menu while checking to make sure it's the right one on the other side of the screen.
I have an ContentEntityType with fields 'remote_id' and 'source'. Both are in the Postgresql database as 'character varying' fields. I execute the following using 'drush php':
$sm = \Drupal::entityTypeManager()->getStorage('product');
$sm->loadByProperties(['remote_id' => '7', 'source' => 'finibar' ]);
I turn on database logging at the Postgresql level and see that the generated
query is
SELECT base_table.id AS id, base_table.id AS base_table_id
FROM
product base_table
INNER JOIN product product ON product.id = base_table.id
WHERE ((LOWER(product.remote_id) IN (LOWER('7')))) AND
((LOWER(product.source) IN (LOWER('7'))))
Note that the value that 'product.source' is tested against is not 'finibar' but is '7'.
loadByProperties does work, if both fields are integers, or one is a string and the
other is an integer. It does not work if both fields are strings.
Contrib/custom database drivers are not in the Drupal\Core\Database namespace, and in this case Log::findCaller will not report the caller correctly, but just the first function/method coming after the first call to the database connection, or worse after a vendor namespaced method if the driver implements methods there.
Incurred into this while experimenting a db driver https://github.com/mondrake/drudbal in conjuction with #2605284: Testing framework does not work with contributed database drivers, and getting failure for the LoggingTest.
See the trace below: in this case the identified 'caller' is always 'query' since it's the first method coming after either not namespaced or not into Drupal\Core\Database namespace.
[0] => Drupal\Core\Database\Log -> findCaller
[1] => Drupal\Core\Database\Log -> log
[2] => Drupal\Core\Database\Statement -> execute
[3] => Doctrine\DBAL\Statement -> execute
[4] => Drupal\Driver\Database\dbal\Connection -> query
[5] => -> db_query
[6] => Drupal\drudbal\Tests\LoggingTest -> testEnableLogging
[7] => Drupal\simpletest\TestBase -> run
[8] => -> _simpletest_batch_operation
[9] => -> _batch_process
[10] => -> _batch_do
[11] => -> _batch_page
[12] => Drupal\system\Controller\BatchController -> batchPage
[13] => -> call_user_func_array
[14] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
[15] => Drupal\Core\Render\Renderer -> executeInRenderContext
[16] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> wrapControllerExecutionInRenderContext
[17] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
[18] => -> call_user_func_array
[19] => Symfony\Component\HttpKernel\HttpKernel -> handleRaw
[20] => Symfony\Component\HttpKernel\HttpKernel -> handle
[21] => Drupal\Core\StackMiddleware\Session -> handle
[22] => Drupal\Core\StackMiddleware\KernelPreHandle -> handle
[23] => Drupal\page_cache\StackMiddleware\PageCache -> pass
[24] => Drupal\page_cache\StackMiddleware\PageCache -> handle
[25] => Drupal\Core\StackMiddleware\ReverseProxyMiddleware -> handle
[26] => Drupal\Core\StackMiddleware\NegotiationMiddleware -> handle
[27] => Stack\StackedHttpKernel -> handle
[28] => Drupal\Core\DrupalKernel -> handle
I think we can safely assume in D8 any logged query will always pass by the Connection object. Get its class name, and drop any stack entry with classes that are not the same as the connection class, drop any entry of the connection class, and then process the remaining stack trace as before.
I think we can safely assume in D8 any logged query will always pass through methods in the namespace of the Connection object.
This will get to:
[0] => -> db_query
[1] => Drupal\drudbal\Tests\LoggingTest -> testEnableLogging
[2] => Drupal\simpletest\TestBase -> run
[3] => -> _simpletest_batch_operation
[4] => -> _batch_process
[5] => -> _batch_do
[6] => -> _batch_page
[7] => Drupal\system\Controller\BatchController -> batchPage
[8] => -> call_user_func_array
[9] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
[10] => Drupal\Core\Render\Renderer -> executeInRenderContext
[11] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> wrapControllerExecutionInRenderContext
[12] => Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber -> Drupal\Core\EventSubscriber\{closure}
[13] => -> call_user_func_array
[14] => Symfony\Component\HttpKernel\HttpKernel -> handleRaw
[15] => Symfony\Component\HttpKernel\HttpKernel -> handle
[16] => Drupal\Core\StackMiddleware\Session -> handle
[17] => Drupal\Core\StackMiddleware\KernelPreHandle -> handle
[18] => Drupal\page_cache\StackMiddleware\PageCache -> pass
[19] => Drupal\page_cache\StackMiddleware\PageCache -> handle
[20] => Drupal\Core\StackMiddleware\ReverseProxyMiddleware -> handle
[21] => Drupal\Core\StackMiddleware\NegotiationMiddleware -> handle
[22] => Stack\StackedHttpKernel -> handle
[23] => Drupal\Core\DrupalKernel -> handle
Review patch.
None
None
None