The app.root and site.path services were converted to container parameters as Symfony 6 enforces services as objects, but these were strings that pretended to be services. This is critical to the Symfony 6 upgrade path.
Remove these services and any tests relating to them.
Symfony has added return types to Symfony\Component\HttpKernel\Controller\ArgumentValueResolverInterface:
public function supports(Request $request, ArgumentMetadata $argument): bool;
public function resolve(Request $request, ArgumentMetadata $argument): iterable;
We need to do the same for compatibility with Symfony 6.
Add the return types.
In Symfony 6, return types have been added to methods in Symfony\Component\Console\Application:
protected function getCommandName(InputInterface $input): ?string {
protected function getDefaultCommands(): array {
public function getDefinition(): InputDefinition {
We need to add these for our applications to work on Symfony 6.
Add the return types.
Follow-up from #3224299-40: [META] Make Drupal 7 core compatible with PHP 8.1
Deprecated function: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in system_modules() (line 842 of /var/www/html/web/modules/system/system.admin.inc).
Go to /admin/modules after a fresh install of drupal standard profile. Download a dev copy of probably any module (I used feeds) and version is null
Write tests
We currently have a token [site:url]. The URL of the site's front page. The language prefix is added if the page is multilingual (e.g. http://www.example.com/pl).
In many cases a language prefix is unnecessary.
Example:
Open graph image path
[site:url]/sites/default/files/og_image.jpg
JSON LD ImageObject path
[site:url]/sites/default/files/logo.jpg
We need a new token that returns the base url without the language prefix.
Add token [site:base-url]. Base URL.
Add test.
Users can use the new token [site:base-url].
The problem I encountered occurred when I was attempting to update from Drupal core 9.2.10 to Drupal core 9.3.2. It fails on the "drush updatedb" command and the site becomes unusable. Rolling back the updates with composer doesn't fix the problem as has been done on other update testing. Once the "drush updatedb" command is executed after the Drupal core and the sqlsrv module are updated, the site becomes un-recoverable without restoring a previous version of the DB.
After I ran into this error, I found one Drupal issue with the same basic problem (search_api issue 3256944). But it appeared for a specific contributed module. So, I'm posting this issue for the core level as it appears the problem affects basic user related stuff.
Our website configurations as of 2021-12-22:
We started using earlier, stable versions of all of the above in 2016 and have kept them all as current as possible.
We updated to Drupal 9.2.10 from an earlier 9.2 version on 2021-12-22 using composer and had no issues then or since.
We have been using the "Drupal driver for SQL Server and SQL Azure" project to interface between MS SQL Server and Drupal. Drupal 9.3 required version 4.3.1 and I attempted to update with that as well. All the composer update operations finished without errors.
This is the sequence of commands processed before the failure happened:
composer global update
drush -y config-set system.performance css.preprocess 0
drush -y config-set system.performance js.preprocess 0
drush cache:rebuild
composer require drupal/core-recommended:^9.3.2 drupal/core-dev:^9.3.2 drupal/core-composer-scaffold:^9.3.2 drupal/core-project-message:^9.3.2 drupal/core-vendor-hardening:^9.3.2 drush/drush drupal/devel composer/installers --update-with-dependencies
composer require drupal/sqlsrv:^4.3.1
drush updatedb
The output from the updatedb command:
Do you wish to run the specified pending updates? (yes/no) [yes]:
> yes
> [notice] Update started: user_update_9301
> [notice] Update completed: user_update_9301
> [notice] Update started: block_post_update_replace_node_type_condition
> [notice] Update completed: block_post_update_replace_node_type_condition
> [notice] Update started: node_post_update_rebuild_node_revision_routes
> [notice] Update completed: node_post_update_rebuild_node_revision_routes
> [notice] Update started: system_post_update_delete_authorize_settings
> [notice] Update completed: system_post_update_delete_authorize_settings
> [notice] Update started: system_post_update_sort_all_config
> [notice] Update completed: system_post_update_sort_all_config
> [notice] Update started: user_post_update_update_roles
> [notice] The role anonymous user has had the following non-existent permission(s) removed: access site map, see menu_editor placeholder pages, use exclude node title.
> [notice] The role authenticated user has had the following non-existent permission(s) removed: access site map, use exclude node title.
> [notice] The roles anonymous user, authenticated user have had non-existent permissions removed. Check the logs for details.
> [notice] Update completed: user_post_update_update_roles
> [notice] Update started: views_post_update_sort_identifier
> [notice] Update completed: views_post_update_sort_identifier
In ProcessBase.php line 171:
Unable to decode output into JSON: Syntax error
{
"0": {
"user": {
"9301": {
"results": {
"query": null,
"success": true
},
"type": "update"
},
"update_roles": {
"results": {
"query": "The roles <em class="placeholder">anonymous user, authenticated user</em> have had non-existent permissions removed. Check the logs for deta
ils.",
"success": true
},
"type": "post_update"
}
},
"block": {
"replace_node_type_condition": {
"results": {
"query": null,
"success": true
},
"type": "post_update"
}
},
"node": {
"rebuild_node_revision_routes": {
"results": {
"query": null,
"success": true
},
"type": "post_update"
}
},
"system": {
"delete_authorize_settings": {
"results": {
"query": null,
"success": true
},
"type": "post_update"
},
"sort_all_config": {
"results": {
"query": null,
"success": true
},
"type": "post_update"
}
},
"views": {
"sort_identifier": {
"results": {
"query": null,
"success": true
},
"type": "post_update"
}
}
},
"drush_batch_process_finished": true
}
The double quotes within the "update_roles":"results":"query" string appear to be what are causing the upset. (The carriage returns in that string were part of the actual output.)
Subsequent "drush updatedb" commands simply state that there are no updates with no errors reported. But attempts to open any page (public or admin) failed.
Since the admin interface was no longer available to check if Drupal caught any errors, I used a Perl/Tk tool of my own design that directly reads the database to report on what is in the watchdog table and other events. That tool showed that Drupal does report an error when I try to open anything page on the site (I replaced the actual site path with {thesitebase}):
'%file' => '{thesitebase}\web\core\lib\Drupal\Core\Plugin\Context\Context.php',
'%function' => 'Drupal\Core\Plugin\Context\Context->getContextValue()',
'%line' => 73,
'%type' => 'Drupal\Component\Plugin\Exception\ContextException',
'@message' => 'The 'entity:user' context is required and not present.',
'@backtrace_string' => '#0 {thesitebase}\web\core\lib\Drupal\Core\ParamConverter\EntityConverter.php(140): Drupal\Core\Plugin\Context\Context->getContextValue()
#1 {thesitebase}\web\core\lib\Drupal\Core\ParamConverter\ParamConverterManager.php(100): Drupal\Core\ParamConverter\EntityConverter->convert('770', Array, 'node', Array)
#2 {thesitebase}\web\core\lib\Drupal\Core\Access\AccessManager.php(90): Drupal\Core\ParamConverter\ParamConverterManager->convert(Array)
#3 {thesitebase}\web\core\lib\Drupal\Core\Menu\DefaultMenuLinkTreeManipulators.php(210): Drupal\Core\Access\AccessManager->checkNamedRoute('entity.node.can...', Array, Object(Drupal\Core\Session\AccountProxy), true)
#4 {thesitebase}\web\core\lib\Drupal\Core\Menu\DefaultMenuLinkTreeManipulators.php(92): Drupal\Core\Menu\DefaultMenuLinkTreeManipulators->menuLinkCheckAccess(Object(Drupal\menu_link_content\Plugin\Menu\MenuLinkContent))
#5 [internal function]: Drupal\Core\Menu\DefaultMenuLinkTreeManipulators->checkAccess(Array)
#6 {thesitebase}\web\core\lib\Drupal\Core\Menu\MenuLinkTree.php(149): call_user_func(Array, Array)
#7 {thesitebase}\web\core\modules\system\src\Plugin\Block\SystemMenuBlock.php(193): Drupal\Core\Menu\MenuLinkTree->transform(Array, Array)
#8 {thesitebase}\web\core\modules\block\src\BlockViewBuilder.php(171): Drupal\system\Plugin\Block\SystemMenuBlock->build()
#9 [internal function]: Drupal\block\BlockViewBuilder::preRender(Array)
#10 {thesitebase}\web\core\lib\Drupal\Core\Security\DoTrustedCallbackTrait.php(101): call_user_func_array(Array, Array)
#11 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(772): Drupal\Core\Render\Renderer->doTrustedCallback(Array, Array, 'Render #pre_ren...', 'exception', 'Drupal\\Core\\Ren...')
#12 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(363): Drupal\Core\Render\Renderer->doCallback('#pre_render', Array, Array)
#13 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(435): Drupal\Core\Render\Renderer->doRender(Array)
#14 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(201): Drupal\Core\Render\Renderer->doRender(Array, false)
#15 {thesitebase}\web\core\lib\Drupal\Core\Template\TwigExtension.php(463): Drupal\Core\Render\Renderer->render(Array)
#16 {thesitebase}\web\sites\default\files\php\twig\61d746f61cd7b_page.html.twig_-mba0TK8lmguGuiDYYaNh9lp7\oCZvPHaeT84n6YaBbJqRvhCqZ7uVWA_83aBD0zyo_ss.php(72): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true)
#17 {thesitebase}\vendor\twig\twig\src\Template.php(405): __TwigTemplate_ddbd5026d0d4341c27e21b762350bfe96e8a92622d09598b9a624eb9d8b36cc4->doDisplay(Array, Array)
#18 {thesitebase}\vendor\twig\twig\src\Template.php(378): Twig\Template->displayWithErrorHandling(Array, Array)
#19 {thesitebase}\vendor\twig\twig\src\Template.php(390): Twig\Template->display(Array)
#20 {thesitebase}\web\core\themes\engines\twig\twig.engine(55): Twig\Template->render(Array)
#21 {thesitebase}\web\core\lib\Drupal\Core\Theme\ThemeManager.php(384): twig_render_template('themes/custom/d...', Array)
#22 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(422): Drupal\Core\Theme\ThemeManager->render('page', Array)
#23 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(201): Drupal\Core\Render\Renderer->doRender(Array, false)
#24 {thesitebase}\web\core\lib\Drupal\Core\Template\TwigExtension.php(463): Drupal\Core\Render\Renderer->render(Array)
#25 {thesitebase}\web\sites\default\files\php\twig\61d746f61cd7b_html.html.twig_J17zj6MPfb7Nq7zxjmcGsAbdD\T4hxiOGif2VSQDw6UtWjNm07SKXQyWzwXz7-GzafMN8.php(84): Drupal\Core\Template\TwigExtension->escapeFilter(Object(Drupal\Core\Template\TwigEnvironment), Array, 'html', NULL, true)
#26 {thesitebase}\vendor\twig\twig\src\Template.php(405): __TwigTemplate_cb7e698015803eec233db9f6c379f81a2821ad92cfc4696b76a442ae5b538b1f->doDisplay(Array, Array)
#27 {thesitebase}\vendor\twig\twig\src\Template.php(378): Twig\Template->displayWithErrorHandling(Array, Array)
#28 {thesitebase}\vendor\twig\twig\src\Template.php(390): Twig\Template->display(Array)
#29 {thesitebase}\web\core\themes\engines\twig\twig.engine(55): Twig\Template->render(Array)
#30 {thesitebase}\web\core\lib\Drupal\Core\Theme\ThemeManager.php(384): twig_render_template('themes/custom/d...', Array)
#31 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(422): Drupal\Core\Theme\ThemeManager->render('html', Array)
#32 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(201): Drupal\Core\Render\Renderer->doRender(Array, false)
#33 {thesitebase}\web\core\lib\Drupal\Core\Render\MainContent\HtmlRenderer.php(162): Drupal\Core\Render\Renderer->render(Array)
#34 {thesitebase}\web\core\lib\Drupal\Core\Render\Renderer.php(564): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#35 {thesitebase}\web\core\lib\Drupal\Core\Render\MainContent\HtmlRenderer.php(163): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure))
#36 {thesitebase}\web\core\lib\Drupal\Core\EventSubscriber\MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\CurrentRouteMatch))
#37 [internal function]: Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#38 {thesitebase}\web\core\lib\Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher.php(142): call_user_func(Array, Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#39 {thesitebase}\vendor\symfony\http-kernel\HttpKernel.php(163): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object(Symfony\Component\HttpKernel\Event\ViewEvent), 'kernel.view')
#40 {thesitebase}\vendor\symfony\http-kernel\HttpKernel.php(80): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1)
#41 {thesitebase}\web\core\lib\Drupal\Core\StackMiddleware\Session.php(58): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#42 {thesitebase}\web\core\lib\Drupal\Core\StackMiddleware\KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#43 {thesitebase}\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(191): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#44 {thesitebase}\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(128): Drupal\page_cache\StackMiddleware\PageCache->fetch(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#45 {thesitebase}\web\core\modules\page_cache\src\StackMiddleware\PageCache.php(82): Drupal\page_cache\StackMiddleware\PageCache->lookup(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#46 {thesitebase}\web\core\lib\Drupal\Core\StackMiddleware\ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#47 {thesitebase}\web\core\lib\Drupal\Core\StackMiddleware\NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#48 {thesitebase}\vendor\stack\builder\src\Stack\StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#49 {thesitebase}\web\core\lib\Drupal\Core\DrupalKernel.php(708): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#50 {thesitebase}\web\index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request))
#51 {main}',
So, as it stands, we cannot take Drupal 9.3 until this gets fixed.
As reported at #3257592: permission/option that an administrator can create/update/delete users although domain is blocked, server-side validation of invalid user accounts is preventing editors from reaching the cancel account form via the 'Cancel account' button at the bottom of the user profile form.
There is no reason to run validation on the form when using an action which is effectively a link to elsewhere, with no form processing occuring.
Expected behaviour: Browser loads the cancel account form
Current behaviour: User profile form reloads with validation error on email field
There are several ways we could tackle this:
$element['delete']['#limit_validation_errors'] = []; to the cancel button in \Drupal\user\ProfileForm.None
None if we use option 1 or 2.
None
N/A
We've stumbled upon this issue when working on exposing responsive images in the graphql module. Src attributes of the img tags output by image styles are (and should be) absolute
* @return string
* The absolute URL where a style image can be downloaded, suitable for use
* in an img tag. Requesting the URL will cause the image to be created.
Source: https://github.com/drupal/drupal/blob/8.4.x/core/modules/image/src/Image...
However, the responsive image module strips out the protocol and domain part and uses just the relative parts making it impossible to embed an image in an external site (including a decoupled frontend).
Make the responsive image return absolute urls.
None
None
None
Since having lots of block derivatives has various implications for performance, it would be great to only create field blocks for entities that are customised with layout builder.
I have a site where 1600 block plugins are being created for webform submission bundles, which will never require field blocks. This number will grow for every webform added to the site.
Ensure FieldBlockDeriver only creates blocks it needs.
Quite a long time ago, before Drupal 8.0, we made the decision to make Views more intelligent about which entity table to select from by default. Before, we always started of the base table and then almost always joined the data table if it exists, because that's where all the data is (except the UUID).
Unfortunately, we never updated entity query accordingly and it is actually far worse there:
* It always picks the base table first, that was the same as views
* It always adds a join as soon as you start to add conditions. *even* if that happens to be the UUID, then it just joins itself or an entity type without a data table.
* It always joins other entity types through the base table and then adds yet another join even if they have no data table. Because reasons.
This is an attempt at making things more sane and possibly considerably more performant.
Just like views, it starts of at the data table if possible, I'm also avoiding the duplicated join by initializing the entity tables (really, joins) mapping table. And I'm trying to improve actual joining as well by skipping the initial join as well.
I've only tested it with a simple example queries, didn't even run the tests yet, I just wanted to start this before I forget about this again (Had the idea of doing this probably a few times already).
My test script:
echo "\nQuery 1:\n";
$ids = \Drupal::entityQuery('node')
->execute();
print_r($ids);
echo "\nQuery 2:\n";
$ids = \Drupal::entityQuery('node')
->condition('title', 'First node')
->execute();
print_r($ids);
echo "\nQuery 3:\n";
$ids = \Drupal::entityQuery('node')
->condition('uuid', '20478baa-64e4-4b01-bf68-5ea34e3db78b')
->execute();
print_r($ids);
echo "\nQuery 4:\n";
$ids = \Drupal::entityQuery('node')
->condition('uid.entity.uid', 1)
->execute();
print_r($ids);
(conditions only work on my specific nodes of course). I also added a 'echo $this->sqlQuery . "\n";' so I can see the generated SQL query.
HEAD:
Query 1:
SELECT base_table.vid AS vid, base_table.nid AS nid
FROM
{node} base_table
Array
(
[1] => 1
[2] => 2
[3] => 3
[4] => 4
)
Query 2:
SELECT base_table.vid AS vid, base_table.nid AS nid
FROM
{node} base_table
INNER JOIN {node_field_data} node_field_data ON node_field_data.nid = base_table.nid
WHERE node_field_data.title LIKE :db_condition_placeholder_0 ESCAPE '\\'
Array
(
[3] => 3
)
Query 3:
SELECT base_table.vid AS vid, base_table.nid AS nid
FROM
{node} base_table
INNER JOIN {node} node ON node.nid = base_table.nid
WHERE node.uuid LIKE :db_condition_placeholder_0 ESCAPE '\\'
Array
(
[1] => 1
)
Query 4:
SELECT base_table.vid AS vid, base_table.nid AS nid
FROM
{node} base_table
INNER JOIN {node_field_data} node_field_data ON node_field_data.nid = base_table.nid
LEFT OUTER JOIN {users} users ON users.uid = node_field_data.uid
INNER JOIN {users_field_data} users_field_data ON users_field_data.uid = users.uid
WHERE users_field_data.uid = :db_condition_placeholder_0
Array
(
[4] => 4
)
With my patch.
Query 1:
SELECT base_table.vid AS vid, base_table.nid AS nid
FROM
{node_field_data} base_table
Array
(
[1] => 1
[2] => 2
[3] => 3
[4] => 4
)
Query 2:
SELECT base_table.vid AS vid, base_table.nid AS nid
FROM
{node_field_data} base_table
WHERE base_table.title LIKE :db_condition_placeholder_0 ESCAPE '\\'
Array
(
[3] => 3
)
Query 3:
SELECT base_table.vid AS vid, base_table.nid AS nid
FROM
{node_field_data} base_table
INNER JOIN {node} node ON node.nid = base_table.nid
WHERE node.uuid LIKE :db_condition_placeholder_0 ESCAPE '\\'
Array
(
[1] => 1
)
Query 4:
SELECT base_table.vid AS vid, base_table.nid AS nid
FROM
{node_field_data} base_table
INNER JOIN {users_field_data} users_field_data ON users_field_data.uid = base_table.uid
WHERE users_field_data.uid = :db_condition_placeholder_0
Array
(
[4] => 4
)
Comparison:
1. Very similar except that my select is on the node_field_data table.
2. No join necessary with my version.
3. This actually requires a join in the new implementation, and this query is currently unfortunately very common (loadByUuid()). But the current implementation joins itself which is likely not much better?
4. A single join instead of *3*
* Figure out things that dont' work yet, pretty sure that translations will be one such case as I'm possibly skipping the language condition now in at least some cases on the base table.
* Is this an API change or not?
Generated queries change, which might break query alters?
With #3124762: Add 'lifecycle' key to .info.yml files committed, we now have a lifecycle key to indicate the status of a module/theme.
Currently, experimental themes use the key/value pair: experimental: true in their .info.yml-files and obsolete extensions are not indicated on the admin status report page.
Use lifecycle: experimental for experimental themes.
Add a warning on the status page when an deprecated or obsolete module or theme is enabled.
Followup: #3250342: [PP-1] Deprecate "experimental: true" in .info.yml
Review
Commit
New info shows on admin/reports for deprecated projects.
After screenshot
N/A
N/A
N/A
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...
The attribute description "(string, optional) A string containing the textual contents of the tag" does not tell the reader whether HTML escaping is performed. I'd prefer instead:
#value: (HTML string, optional) The markup content of the tag. No escaping is performed on output.
In the fight against spam more and more ISP's require mail send though the php function to originate from the main domain. The contact form however uses the senders email as "from:" address.
I'd like to see a field in settings to optionally set a fixed "from address" (for example contactform@domain.tld) and use "reply-to" to enable replies to the sender, while still using the fixed from address which is accepted by the isp.
This issue was fixed for Drupal 8: committed to the 8.3.x branch on 2 August 2016 and the 8.4.x branch on 27 January 2017.
As of 29 October 2017, the issue is RTBC for Drupal 7, so it may be fixed in an upcoming release of Drupal 7.
Until then, you can either apply the patch from this issue or use a contrib module to get the same effect. One module mentioned in the comments below is Contact Reply-To. There may be other options.
Using a link field with the 'Link' display formatter, internal links with a query string with brackets are broken.
/resources?tid_1[30]=30/resources?tid_1%5B0%5D=30&tid_1%5B1%5D=30, which does not work/resources?tid_1%5B30%5D=30, which worksIf the link is absolute rather than relative, it also works, e.g. https://google.com/resources?tid_1%5B30%5D=30
N/A
N/A
N/A
N/A
On a theme's settings page there is a toggle for "User verification status in comments", but this is inaccurate as it's not entirely restricted to comments. For example you could allow anonymous users to create nodes of a certain type, and if you display authoring information for that content type it will still say "Anonymous (not verified)". To make matters worse, if the comment module is not enabled you cannot uncheck the toggle.
We should either rename the setting and remove the module_exists() check around it, or split it up like user pictures, which has "User pictures in posts" and "User pictures in comments".
Claro is aimed to be an experimental admin theme in Drupal 8.8.0 which according to Drupal development roadmap is aimed to be released on December 4, 2019. Drupal 8.8.0 feature freeze is on the week of October 14, 2019. Claro must reach at least beta status by then to be included in a stable release.
Once the following level of feature completeness has been reached, we will consider tagging stable release for Claro:
When alll that is done we can move to #3167121: Make Claro the default admin theme
-
Once the following level of feature completeness has been reached, we will consider tagging beta release for Claro:
This issue has been reported privately to the security team but it was decided to handle this as public security improvement since no direct vulnerability is involved. This issue was reported by mvonfrie.
valid_url() report http://- as valid URL:$valid = valid_url('http://-', true);
Urls look like this after the scheme (protocol) according to RFC 3986, section 3.2:
authority = [ userinfo "@" ] host [ ":" port ]
host = IP-literal / IPv4address / reg-namereg-name should be "conform to the DNS syntax"
Important quote from below research:
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.
UrlHelper::isValid() should reject a hostname that starts, ends, or is only a hyphen.
Improve the regex in UrlHelper::isValid() (valid_url() in Drupal 7).
Write a patch.
Review
Commit
none.
none.
Original comments:
#1 benjy commented April 2, 2015 at 6:35am
Component: » Code
This just seems like a bug to me at this point and could easily be handled in public.
Comment #2 Pere Orga commented April 2, 2015 at 3:43pm
I have tried a few browsers and all think URL http://- is valid.
http://-: http://i.imgur.com/zjaPlzv.png
http://localhost: http://i.imgur.com/UzXV4Xe.png
Comment #3 benjy commented April 3, 2015 at 3:57am
From: https://www.ietf.org/rfc/rfc3986.txt
Scheme names consist of a sequence of characters beginning with a
letter and followed by any combination of letters, digits, plus
("+"), period ("."), or hyphen ("-"). Although schemes are case-
insensitive, the canonical form is lowercase and documents that
specify schemes must do so with lowercase letters. An implementation
should accept uppercase letters as equivalent to lowercase in scheme
names (e.g., allow "HTTP" as well as "http") for the sake of
robustness but should only produce lowercase scheme names for
consistency.
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
So the example with the hyphen is valid because technically it could be part of the scheme?
Comment #4 benjy commented April 3, 2015 at 4:09am
OK, more reading, my first comment wasn't the reason.
So as this issue reports, the format after the scheme is: host = IP-literal / IPv4address / reg-name
And reg-name is made up of: reg-name = *( unreserved / pct-encoded / sub-delims )
And unreserved is: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Which explains the valid url when starting with a hyphen.
Comment #5 mvonfrie commented April 4, 2015 at 4:07pm
Yes, but exactly before the definition of
reg-name = *( unreserved / pct-encoded / sub-delims )
the RFC says
Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters.
This is not covered by the formal syntax specification. That means every host name can contain hyphens, but neither start nor end with them or just be a hyphen:
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.
https://tools.ietf.org/html/rfc1035, 2.3.1
So in my understanding http://- is not a valid url as - is not a valid hostname.
Comment #6 Pere Orga commented April 4, 2015 at 7:36pm
In any case I also think this could be discussed in public. It doesn't look like any harm could be done.
Comment #7 benjy commented April 6, 2015 at 6:11am
+1 for public from me.
A custom date format including a two byte character bracket "（", e.g. "Y/m/d（D）- H:i" is not processed correctly; it shows junk characters. In this case, the brackets "（" and "）" are two byte characters frequently used in Japanese instead of single bye character brackets like "(" and ")". See the screenshot.
I identified the following code at line 101 in lib/Drupal/Core/Datetime/DrupalDateTime.php causes the problem but I have no idea about how to fix it.
$format = preg_replace(array('/\\\\\\\\/', '/(?<!\\\\)([AaeDlMTF])/'), array("\xEF\\\\\\\\\xFF", "\xEF\\\\\$1\$1\xFF"), $format);
FYI, the Unicode of two byte bracket （ is \uFF08 and urlencode is %EF%BC%88.
Meta for triage credit, please note: you only need to add a comment for one issue that was triaged and closed, not every one.
Remember to add the tag 'Bug Smash Initiative' to issues that are triaged.
Meta for triage credit, please note: you only need to add a comment for one issue that was triaged and closed, not every one.
Remember to add the tag 'Bug Smash Initiative' to issues that are triaged.