How do I get the render array for a route? I know the path, and have injected the renderer service so I can get the markup from the render array.
I am looking for something like:
$render_array = $route->getRenderArray();
$markup = $renderer->render($render_array);
I need to get the "placeholdered" markup, as I am working on the http://drupal.org/project/static_generator module, which generates static html pages with ESL includes.
API page: https://api.drupal.org/api/drupal/core%21modules%21user%21src%21Entity%2...
> If the preferred language is not set or is a language not configured anymore on the site, the site default is returned or an empty string is returned (if $fallback_to_default is FALSE).
This is phased as "If A or B, then C or D, if E".
So, what happens if A? What happens if B? You can't really tell...
Logically, if there no no language configured on the site, then there's no site default to return, so you'd get an empty string. But it takes a fair amount of picking that sentence apart to see that.
This should be rewritten in several sentences, and ideally with bullet points to explain what happens.
Im exporting a simple content type with a body and image for import into another site. the operation completes without error but the imported content type has lost the fields of the exported content type
from the source site...
/admin/config/development/configuration/single/export
select single item=>content-type=>my custom type
generates....
uuid: 03aa0f8b-a2bc-4809-a2c1-7ca70049594e
langcode: en
status: true
dependencies:
module:
- menu_ui
third_party_settings:
menu_ui:
available_menus:
- main
parent: 'main:'
name: 'Custom Page'
type: custom_page
description: ''
help: ''
new_revision: true
preview_mode: 1
display_submitted: truei import this into target site without error but the fields are lost.
thanks
It would be nice if users could visually select media when editing and creating content, instead of using the Entity Reference field widget.
We should create a new field widget that allows users to select media from the Media library view, and ensure that the widget is designed in a way that other selection interfaces (like upload, oembed, etc.) will also work in the future.
Write/review patches, wait for #2962110: Add the Media Library module to Drupal core to land.
A new field widget will be available to users who are already using the Media library.
TBD.
None.
In order to get to PHPUnit 6 and PHP7.2 compatibility we had to change SYMFONY_DEPRECATIONS_HELPER to weak_vendors because we were triggering deprecation notices from our mocks. PHPUnit 6 has a neat new feature that triggers deprecation messages from mocks if the method has an @deprecated annotation. So even if the method's real code has no @trigger_error its mock will do. This is great because it allows us to find tests which are mocking deprecated methods but it tricky for Drupal 8 because we have methods that were deprecated before we had the @trigger_error policy in place.
This was a hack to get around that. We should be on strict so that all deprecations in core are either skipped or expected. Eventually we should get rid of the skipped deprecations too. See #2959269: [meta] Core should not trigger deprecated code.
When it is set to weak_vendors we don't trigger deprecation errors for things like #2961688: Fix "Using UTF-8 route patterns without setting the "utf8" option" deprecation because this deprecation is triggered by vendor code calling vendor code - even though it is our usage of the Symfony API that triggers it.
Probably add all the deprecations to skipped so at least we know the size of the work.
It's important to run the tests on both PHP 5.6 and PHP 7+ to get the difference between PHPUnit 4 and PHPUnit 6.
None
None
None
#253157: Add "Translate own content" permission, rename "Translate content" to "Translate all content" was committed in earlier versions of Drupal 8 which allowed users to translate their own content. However, this feature was later removed from the core and it made https://www.drupal.org/node/1776752 obsolete.
Nowadays, multilingual community sites still have a requirement to allow users to translate their own content.
Based on @Berdir's feedback:
Options are:
Discuss.
I'm trying to use a custom process plugin to allow to choose conditionally which field to define as source.
Here is the migrate portion:
process:
'field_foo/value':
plugin: ifte
source: type
comparison: ==
this: news
then: field_bar/0/value
else: field_baz/0/value
And here is the 'ifte' process plugin code: https://gist.github.com/trepmag/d3957f919857e3f6a21bca89c2af0a9a
Unfortunately the 'field_foo/value' field get the fields strings ('field_bar/0/value' or ''field_bar/0/value') but not their values...
How could I get their values?
hook_custom_theme() fails to work under certain circumstances.
Call stack that causes the issue:
redirect_load_entity_from_path()media_token_to_markup()file_entity_file_load()token_replace() for the alt / title tags.system_token_info()l()l() wants to know the current theme thus drupal_theme_initialize() is called.drupal_theme_initialize() defines global variables e.g. $theme, $theme_key. Once those variables are set the main part of the function is skipped. Unfortunately drupal_theme_initialize() doesn't force menu_get_custom_theme() to initialize.Now what's the problem with that:
The call of the redirect module is made before menu_set_custom_theme() was called, which is normally called after drupal_path_initialize() in _drupal_bootstrap_full().
And the redirect module acts on hook_url_inbound_alter() which is triggered by drupal_path_initialize().
Because that call is skipped hook_custom_theme() never is invoked and we lose the control over the theme.
I see two approaches:
drupal_theme_initialize() to be able to re-set the global theming variables when calling the function in _drupal_bootstrap_full()drupal_theme_initialize() to force the initialization when calling menu_get_custom_theme()I think the first one is more unobtrusive and is the one I've added as patch.
Reviews needed.
None.
The function signature of drupal_theme_initialize() has changed but in a transparent way. This means already existing code will work as before.
Settings for reverse proxy are not used in standard request.
Taking a look at the code, I've seen that the class ReverseProxyMiddleware is used to read the reverse proxy settings and to apply them.
But this class is only used once in install.core.inc:426.
During the normal request handling process, through index.php, the class is never called and the settings are not used.
This results in Drupal ignoring the reverse proxy settings and generate wrong urls.
Consider this example architecture:
When I create a new user on the website, the e-mail sent to notify him about his new account has the wrong base url (http://web.drupal.loc). The same happens for other absolute urls, as for example the reset link, etc..
In DrupalKernel class, when handling the request and after the settings inizialization, it must be called ReverseProxyMiddleware::setSettingsOnRequest to read and apply the reverse proxy configuration (if present).
A proposed patch is attached.
If it could be useful, to replicate the problem and test the solution I've set up a docker environment with a fresh drupal installation that I can share.
There are a good amount of subclasses of BulkForm:
All just override to provide a custom message.
Move the message to a config setting in the BulkForm plugin.
Do it.
User will be able to configure the empty selection message on views bulk form fields.
@TODO
New config setting for views bulk operation fields.
If you have a temporary file and for some reason the file on the disk for it no longer exists, it logs an error every time file_cron() runs:
Could not delete temporary file x during garbage collection
The file is gone. Maybe log an error or warning once, then drop the record.
Steps to reproduce:
The problem is that lingotek, as well as content_translation, store metadata on the actual entity. Everytime this metadata is updated, things potentially call out to $entity->save(). Lingotek module avoids creating new revisions by using ->setNewRevision(FALSE), but sadly content_moderation overrules that.
Assume that entities are configured correctly and create new revisions already, and no longer overrule that in content_moderation.
When referenced in an entity reference field, the ContactForm entity has no 'rendered entity' output.
Add the view builder from Contact storage module to core.
Set this in the annotation for the ContactForm entity.
Add test coverage to verify that forms can be referenced from entity reference fields and doing so renders the message form.
All of the above
None
None
None
Some of Migrate’s cckfield plugin's method naming are not describing clear enough what they do and therefore may confuse developers using the API (therefore giving poor DX).
Review
Commit
None.
Yes.
processCckFieldValues()processFieldValues() will be deprecatedprocessField() will be deprecatedprocessFieldInstance() will be deprecatedprocessFieldWidget() will be deprecatedprocessFieldFormatter() will be deprecatedNone.
Those who know me know that I’m fairly fanatical about good DX in core APIs (or, indeed, any APIs). Because of that, certain aspects of Migrate’s cckfield plugins have been bugging me for a long time.
I have three main bones to pick:
The doc blocks for each of these methods in MigrateCckFieldInterface need to be improved as well. These plugins are crucial for contrib migrations from D6 and D7, so the interface should include short snippets of example code in the doc comments.
#2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code added the ability to test deprecated code. In order to get that done we add to add \Drupal\Tests\Listeners\DeprecationListenerTrait::getSkippedDeprecations() because core is exercising lots of deprecated code. This is all technical debt that we need to clear up. This issue is going to coordinate all the issues that need to be filed in order to stop using deprecated code.
The @todo list:
Done list:
Ensure each skipped deprecation has an issue to work on.
Create all the necessary issues
None
None
None
The ban module enables you to store single IP-addresses, from which any access of the website will be prevented.
In some cases spammers uses IP-ranges from where they spam contact forms. So it would be nice to have a comfortable opportunity to block IP-ranges or if the usage of wildcards would be supported.
There are times when the functionality to for the processing of batches is required to be swapped out.
Create an interface and class for the processing of batches and add it as a service.
The current functionality is not to be changed at this stage. The default batch processor service class will call the existing functions. Further issues will be created to migrate the functionality to the service class at a later stage. See #2875151.
None.
A service is to be introduced for processing of batches.
None.
Some modules need to act before an entity is loaded, and swap out the default revision with a different one.
For example, the Workspace module in core swaps the default revision with a workspace-specific revision, if one exists.
Add two new hooks: hook_entity_pre_load() and hook_ENTITY_TYPE_pre_load() that are called before the entity loading process.
Discuss, review.
Nope.
API addition, the two new hooks mentioned above.
Nope.
This blocks #2571235: [regression] Roles should depend on objects that are building the granted permissions and hence at least a major because it is blocking a critical.
Profiles can override configuration used in an install. For example, a profile can provide a user.role.anonymous that is used instead of the one in user/config/install. This works fine at the moment because user roles have no dependencies. But #2571235: [regression] Roles should depend on objects that are building the granted permissions will break this because that adds them and as user is installed right after system there is no way this can work without causing an \Drupal\Core\Config\UnmetDependenciesException error. This behaviour is tested in \Drupal\config\Tests\ConfigInstallProfileUnmetDependenciesTest.
This is not an ideal situation as it means we can't really add any new dependency information without breaking install profiles that do this. According to @Berdir we've done this several time over the 8.x dev cycle.
Maybe instead of replacing the configuration we can just install the configuration from the module and then when the install profile is instead we can update the configuration entity instead.
None.
None.
None.
We are currently skipping the Install profile will be a mandatory parameter in Drupal 9.0. deprecation.
Remove deprecation skipping and fix how it is triggered to be only when \Drupal::installProfile() results in setting a profile value.
None
None
None