We should add the missing languages that are not in Drupal core but supported on localize.drupal.org. This is how the localized Drupal install profile looks now with the .po files in place for all l.d.o languages:
Not pretty. We should have an explicit listing for the missing languages. Here are Drupal 6 and 7 patches.
In #56357: Login issues with multiple sites in the same domain (session cookie collision) while fixing various session cookie problems, code was added that strips a leading www. from the cookie domain by default
At the time it may have made sense that people did not want to get logged out switching between www and the bare domain. Now, most sites force one or the other for security and consistency and to avoid possible SEO hits for duplicate content.
This behavior is actually a bug, however, because makes sites less secure because the session cookie is then sent to ALL subdomains by default.
e.g. see http://erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains/
It also make it much harder to defend against file uploads attacks like the one described at https://soroush.secproject.com/blog/2014/05/even-uploading-a-jpg-file-ca...
If www. is not stripped it would be easier to point a different subdomain at your site just for serving files.
Remove the www. stripping behavior, or make it configurable and off by default.
patch
review
None (unless there is a setting page for the behavior)
Small change to session cookie behavior
none
| Issue category | Bug because Drupal will (unexpectedly) send session cookies to subdomains |
|---|---|
| Issue priority | Major because this has security implications |
| Prioritized changes | The main goal of this issue is security |
| Disruption | Possible disruption for any Drupal 8 site that's already in production and relying on this behavior |
Following on from #3203611: Wrong typehint in \Drupal\field\Entity\FieldConfig::loadByName, the documented return type of \Drupal\field\Entity\FieldConfig::loadByName is still not exactly correct.
The return type should be fully qualified, to not cause tooling like PHPStan to blow up, and PHP Storm to report errors.
I was doing view import, In between site shown "The website encountered an unexpected error. Please try again later."
While looking to error logs in web server it gives,
Error: Unsupported operand types in Drupal\views\Entity\View->mergeDefaultDisplaysOptions() (line 472 of modules/views/src/Entity/View.php).
Prior to https://www.drupal.org/project/media_vimeo_domain_privacy I was getting generic/"Bad" thumbnails with bad names when using videos hosted on vimeo. (that module solved that problem for NEW media... They correctly generate thumbnails and names now...)
How do I regenerate the thumbnails and names for each media entity now?
For example ^^^ the first item in that image is an auto generated name, because prior to using media_vimeo_domain_privacy there were issues getting that meta data out of privacy protected vimeo videos (even if they were allowed to be embeded on the domain).
The bottom two are examples of "good" videos that correctly generate a thumbnail and name based on the vimeo.com provided information.
.... Is there a way to '"regenerate" the thumbnails and displayed names?
Thank you!
Follow up to #2301393: Deprecate all of mail.inc, move drupal_mail to method on Mail plugin manager. Some of the methods in MailFormatHelper could be helpful outside the mail system and can be moved to a more generic helper class. e.g.
Create a new helper class, and move methods there.
Hello,
I have Upgraded to 9.30 a few days ago and when I try to uninstall a module or clear cache I receive the following error page;
"The website encountered an unexpected error. Please try again later.
Error: Call to undefined method Drupal\jsonapi\ResourceType\ResourceTypeAttribute::withRelatableResourceTypes() in Drupal\jsonapi\ResourceType\ResourceType->Drupal\jsonapi\ResourceType\{closure}() (line 390 of core/modules/jsonapi/src/ResourceType/ResourceType.php).
Drupal\jsonapi\ResourceType\ResourceType->Drupal\jsonapi\ResourceType\{closure}(Array, 'drupal_internal__geoid')
array_reduce(Array, Object, Array) (Line: 392)
Drupal\jsonapi\ResourceType\ResourceType->setRelatableResourceTypes(Array) (Line: 137)
Drupal\jsonapi\ResourceType\ResourceTypeRepository->all() (Line: 115)
Drupal\jsonapi\Routing\Routes->routes()
call_user_func(Array) (Line: 146)
Drupal\Core\Routing\RouteBuilder->rebuild() (Line: 83)
Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() (Line: 581)
drupal_flush_all_caches() (Line: 31)
Drupal\php\PhpUninstallValidator->removeFilterConfig() (Line: 18)
Drupal\php\PhpUninstallValidator->validate('php') (Line: 633)
Drupal\Core\Extension\ModuleInstaller->validateUninstall(Array) (Line: 99)
Drupal\Core\ProxyClass\Extension\ModuleInstaller->validateUninstall(Array) (Line: 148)
Drupal\system\Form\ModulesUninstallForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 531)
Drupal\Core\Form\FormBuilder->retrieveForm('system_modules_uninstall', Object) (Line: 278)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 564)
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: 158)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
"
Thanks for you suggestions.
In \Drupal\Core\Mail\Plugin\Mail\PhpMail::format() there is a conversion from HTML to text which occurs without checking if the input is an instance of MarkupInterface. This causes corruption of a mail that was in fact plain text and contains text that resembles HTML.
E.g.
Today I learnt Greek letters alphaβ they are hard to write.
In HTML, ampersand must be written as &.
I saw your house and <wow> it is great.
If a<b and b<c then a<c.Install a contrib module that allows sending of messages in plain text format. An example is simplenews. Type a message like the example above.
Only call htmlToText() if the input implements MarkupInterface.
None.
None.
None.
None.
None.
Current settings included in module, theme and profile .info.yml files should be separated into more appropriate config files, like .settings.yml, .libraries.yml, .regions.yml.
examples with more details:
https://www.drupal.org/project/ideas/issues/1398772#comment-10533558
Minimize the configuration included in .info files, as a preparation to use composer for dependency management.
Create subtasks to clean up the .info files.
Docs:
Module .info: https://www.drupal.org/docs/creating-custom-modules/let-drupal-know-abou...
Theme .info: https://www.drupal.org/docs/theming-drupal/defining-a-theme-with-an-info...
Profile .info: https://www.drupal.org/docs/distributions/creating-distributions/how-to-...
Hello,
I have just faced a problem - I need menu link produced by a view display to be hidden if the view output is empty. I've searched in the web, but could't find good solution. Nevertheless, I've discovered, that there is such function for blocks - under "Advanced" -> "Other" -> "Hide block if the view output is empty:Yes/No".
Is there a way to accomplish same effect for menu link/tab? Is it possible to implement this functionality in the view module?
Thanks in advance!
There's an issue to support adding third party settings to sections: #2942661: Sections should have third-party settings, but it would be great to also support third party settings for individual components (blocks) within a section.
For example, modules like Block Class, Field Formatter Class or Fences Block use third party settings on block config entities to allow the user to add arbitrary CSS classes to a block. It seems that the only way to do this with a Layout Builder block is to modify the settings form for the individual block plugin you want to modify and store the configuration along with the other configuration for that block.
SectionComponent should implement ThirdPartySettingsInterface
N/A
N/A
Because there was an existing similar approach ($additional)), deprecations are added with full BC
Data model addition
N/A
After investigating this issues:
#2764651: Global: View Result Counter does not evaluate properly in IF statements
#2821221: Views Counter variable only equal to zero with Twig
I have discovered that uncacheable view fields are not evaluating correctly in twig statements inside rewrite output. So for example if you put IF Statement inside the rewrite output to check the View Result Counter it will not work correctly.
{% if counter==2 %}
Hello World
{% endif %}
or even(string comparison):
{% if counter=='2' %}
Hello World
{% endif %}
From what I have understood while reviewing the source code when the Drupal\views\Plugin\views\style\StylePluginBase::renderFields renders the field the Drupal\views\Plugin\views\field\UncacheableFieldHandlerTrait::render return the placeholder of that field. So during the evaluation of the statement the variable will contain the placeholder instead of the actual value and the above example converts to:
{% if '{{ counter }}'=='2' %}
Hello World
{% endif %}
which results always to false.
A simple way to confirm this is put inside the rewrite output of a View
{% if counter=='{{ counter }}' %}
Hello World
{% endif %}
which results always to true.
Currently from what I saw only Counter and BulkForm are using UncacheableFieldHandlerTrait.
This lays out what remains to be done after #3231364: Add CKEditor 5 module to Drupal core lands in Drupal core.
This plan was originally taken from the IS at #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10, and after that from #3201824: Roadmap to core.
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.
This issue is here to replace that with the key/value pair: lifecycle: experimental.
The patch in this issue started out in #3215045: Highlight obsolete module's status at admin/reports/status page, providing warning and link with explanation, but was split into its own issue to prevent scope creep.
- Replace all occurrences of key/value pairexperimental: true in Core's *.info.yml-files with lifecycle: experimental.
Currently there are 2 occurrences:
core/modules/system/tests/themes/experimental_theme_test/experimental_theme_test.info.yml
core/themes/claro/claro.info.yml
- Key/value pair experimental: true will be properly deprecated in #3250342: [PP-1] Deprecate "experimental: true" in .info.yml
Review
Commit
Please assign credit for this patch according to issue #3215045: Highlight obsolete module's status at admin/reports/status page, providing warning and link with explanation up to #34
As mentioned in the parent issue #3238306: [META] Where possible, refactor existing jQuery uses to vanillaJS to reduce jQuery footprint, we are working towards reducing our jQuery footprint. One of the ways to accomplish this is to reduce the number of jQuery features used in Drupal core. We have added eslint rules that identify specific features and fail tests when those features are in use.
There are (or will be) individual issues for each jQuery-use eslint rule. This one is specific to jquery/no-is, which targets the jQuery is function.
core/.eslintrc.jquery.json Change "jquery/no-is": 0, to "jquery/no-is": 2, to enable eslint checks for uses of jQuery css(). With this change, you'll be able to see uses of the undesirable jQuery feature by running yarn lint:core-js-passing from the core directorycore/scripts/dev/commit-code-check.sh so the DrupalCI testing script can catch this jQuery usage on all files, not just those which have changed# @todo Remove the next chunk of lines before committing. This script only lints
# JavaScript files that have changed, so we add this to check all files for
# jQuery-specific lint errors.
cd "$TOP_LEVEL/core"
node ./node_modules/eslint/bin/eslint.js --quiet --config=.eslintrc.passing.json .
CORRECTJQS=$?
if [ "$CORRECTJQS" -ne "0" ]; then
# No need to write any output the node command will do this for us.
printf "${red}FAILURE ${reset}: unsupported jQuery usage. See errors above."
STATUS=1
FINAL_STATUS=1
fi
cd $TOP_LEVEL
# @todo end lines to remove
Add the block about 10 lines before the end of the file, just before if [[ "$FINAL_STATUS" == "1" ]] && [[ "$DRUPALCI" == "1" ]]; then, then remove it once all the jQuery uses have been refactored.
is() to use Vanilla (native) JavaScript instead.Follow-up to #2528988: Remove the option to specify a base_url from within settings.php
- $base_url is not the same as $base_root . $request->getBasePath() in Symfony.
- This leads to lots of problems with TrustedRedirectResponse() as it thinks we redirect to an external path.
- Therefore #2528988: Remove the option to specify a base_url from within settings.php did not reach its goal to unify both approaches, but made it in fact almost impossible to work-around the mismatch
- Use Symfony function to find the script instead of $_SERVER['SCRIPT_NAME']
- Do it
The ContentEntity source plugin throws an exception when it is configured to use a bundleable entity as source, but the bundle source configuration cannot match an existing bundle. IMHO this shouldn't happen.
This source plugin is used by the d7_entity_reference_translation follow-up migrations which are (re-)generated on the fly, while the migrations are executed. See EntityReferenceTranslationDeriver, MigrateUpgradeImportBatch and MigrationWithFollowUpInterface for reference. The problem is that when e.g. node migrations (and the supporting configuration migration d7_node_type) gets rolled back, the previously generated d7_entity_reference_translation follow-up migration derivatives still exist, but since the node_type config entities do not exist anymore, the ContentEntity plugin throws an exception without any good reason: since it adds the bundle condition to its entity query, that will return zero rows for a missing bundle.
See above.
Do not throw exception when the bundle source configuration cannot match an existing bundle. Instead, log a debug message.
I just discovered that entity queries can handle relationships -- these docs in QueryInterface::condition() explain it:
* @param $field
* Name of the field being queried. It must contain a field name, optionally
* followed by a column name. The column can be the reference property,
* usually "entity", for reference fields and that can be followed
* similarly by a field name and so on. Additionally, the target entity type
* can be specified by appending the ":target_entity_type_id" to "entity".
* Some examples:
* - nid
* - tags.value
* - tags
* - tags.entity.name
* - tags.entity:taxonomy_term.name
* - uid.entity.name
* - uid.entity:user.name
It would be really nice to be able to do reverse relationships as well.
Currently it is not possible to group REST results in views.
Implement grouping functionality.
Add grouping select to views formatter settings.
The list of fields in the field mapping section of the media type form is not sorted.
The $options should be sorted with natcasesort().