If you watch the original DrupalImage returns an object from the '_createDialogSaveCallback' function, which the DrupalImageCaption doesn't do it. This makes currently for me imposibble to edit in the right way it's values (the existing object has missing stuff which the returned one has, i.e. wrapper property is null in the existing one and the return one has the proper one). So I made a patch which will pass back the current widget, so later another module can use it.

This issue is only to address converting the current functional code to an OOP structure.
Please check the related issues or create a new ticket for further improvements.

Problem/Motivation

The batch system is still very much function based and it is not entirely obvious how to write batch operations, see http://api.drupal.org/api/drupal/core%21includes%21form.inc/group/batch/...

Proposed resolution

Create a new Batch object and move existing functionality into its methods to make batch processing easier to set-up.

An example of use would be:

use Drupal\Core\Batch\Batch;

$batch = Batch::create()
  ->setTitle('Tilte')
  ->setFinished('batchFinishedCallbackFunction')
  ->addOperation('batchOperationCallbackFunction', $callbackArguments);

$batch->enqueue();

The existing functions need to be re-written to use the new Batch object and maintain backwards compatibility.

A batch processing service is to be created as part of #2875151: Implement batch api as a service. Because of this, the Drupal\Core\Batch\BatchQueueController class is to marked as internal as the implementation may change.

Remaining tasks

User interface changes

None.

API changes

A new Batch object is to be introduced. Existing functions are to be re-written to utilise the new object to maintain backwards compatibility.

Hi, I have tried outputting rss feeds straight as RSS feed, RSS default and force as fields.

Still the feeds publish with ‘submitted by’ and ‘publishing date’, don’t want that :)

Have made sure that each content type has ‘authored by’ deselected, still no joy.

Is it hardcoded somewhere? Would most appreciate any suggestions on how to remove the unneccesary text that appears in my feeds.

I am creating two custom content type with reference to these pages:

https://www.drupal.org/node/2629550

https://www.drupal.org/node/2693979

Everything works fine. Content type with fields is created. But While installing, it throws an exception and as a result hook_install is not executing, i think. The error is as follows:

Uncaught PHP Exception Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException: "You have requested a non-existent service "router.route_provider.old". Did you mean one of these: "router.route_provider", "router.route_preloader"?" at ...\\core\\lib\\Drupal\\Component\\DependencyInjection\\Container.php line 157

Could anyone please help me, why this is happening and how to fix it ?

I am using Drupal 8.1.8 version.

Problem/Motivation

#2574767-36: Views listing page displays too few items on a page removed the "Tags" column from the list of views at /admin/structure/views, because it was rarely used.

I don't personally use Views Tags on every project, so I understand with, and largely agree with the reasoning in that issue. Also I couldn't find any other issues asking for it to be re-added, which probably also indicates that the feature is not used that often.

That being said, I do find Views tags very useful in specific situations, e.g.: for managing technical debt on a site with multiple developers and a tight timeline... I tag views by their base table, contextual filters, whether they use aggregation, and where they are used; so that it is easy for developers to find an existing view they can add a new display to (rather than creating an entirely new view), and it is easy to see which views could be combined when they are already a mess.

Ideally, the list of views at /admin/structure/views would become a view of its own (e.g.: as part of #1823450: [Meta] Convert core listings to Views), which would allow me to simply add a tags column on the sites that required it; and leave it at the default everywhere else.

However, in the meantime, it would be handy to have a patch to apply to add the tags column back.

Proposed resolution

Write a patch to re-add the tags column.

Remaining tasks

1. Write a patch.

I'll leave it to others to determine whether this is something we want to add back to Drupal core; or just leave here for people to apply when they need it.

User interface changes

Adds a "tags" column between Description and Displays to the list of views at /admin/structure/views

API changes

None.

Data model changes

None.

Context

I'd like to set twig.config.debug:true(services.yml) only in certain conditions for developers. Not statically in services.yml. I need PHP for that. For example activate debug by an URL parameter or user permission.

Problem

I can't find a way to set / alter this in PHP

What I've tried

• Searched for a hook without success
• Tried to set $conf['twig.config']['debug'] in settings.php without success
• Tried to set $$settings['twig.config']['debug'] in settings.php without success
• Tried to set $conf['twig.config.debug'] in settings.php without success
• Tried to set $$settings['twig.config.debug'] in settings.php without success

But could not find a way to alter or set this in code?

Can somebody help me please?

Hi All,

I am working on Drupal 8.2.0-dev for website on linux server with MariaDB as database server. The site setup is based on 3 instances of website setup or file system using one database. Whenever updates are made to the site cache is cleared from all 3 instances / nodes for changes to work properly esp. twig template changes.

Here is more detail about site configuration on server :-

The website is actually a 3-node cluster behind a load balancer.
Each node (node1,node2 and node3) are part of a MariaDB Galera Cluster, and each node is hosting the Drupal website.
Each drupal website communicates with it’s own DB. So this means when node1 is serving a page, it is reading/writing to the DB on node1. Likewise, node2 read/writes to node2’s DB and so on.
The website files on main location are replicated between the nodes using lsyncd and csync2.

So, when a visitor hits the website, traffic flow is :
HTTP Traffic -> HAPROXY Load Balancer -> (one of the 3 Nodes)
a. Node1 website communication to MariaDB on node1 (localhost)
b. Node2 website communication to MariaDB on node2 (localhost)
c. Node3 website communication to MariaDB on node3 (localhost)

I face an error :-
1. While using drupal admin interface for making updates or inserts website admin often gets error below.
2. Wen cache is cleared using Drush on website on the frontend also.

Uncaught PHP Exception Drupal\\Core\\Database\\DatabaseExceptionWrapper: "SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction: INSERT INTO {cache_entity} (cid, expire, created, tags, checksum, data, serialized) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6) ON DUPLICATE KEY UPDATE cid = VALUES(cid), expire = VALUES(expire), created = VALUES(created), tags = VALUES(tags), checksum = VALUES(checksum), data = VALUES(data), serialized = VALUES(serialized); Array, referer:

After searching on similar issues I found that solution suggested are using modules which are not ported to Drupal 8 yet e.g. https://www.drupal.org/project/apdqc. This issue was reported for Drupal 7 several times but not Drupal 8. I am not sure if its bug so adding support request.

Have not been able to find any reliable solution for this.

Just to add in my case the deadlock always is related to cache tables. Also can "Entity/field definitions" , " Mismatched entity and/or field definitions " as on page /admin/reports/status has any relation to this?

Any suggestions would be appreciated.

Thanks
Atul

Just inherited a D8 site, tried clearing opcache (because none of my php edits will take) and am getting the error:

The website encountered an unexpected error. Please try again later.

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "broken" plugin does not exist. in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 52 of core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

There is no plugin/module I can find called Broken...

Log error:

[22-Feb-2018 17:14:40 America/New_York] Uncaught PHP Exception Drupal\Component\Plugin\Exception\PluginNotFoundException: "The "broken" plugin does not exist." at /mnt/nfs/html/mountaincreek.com/public/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php line 52

Any help on where to start greatly appreciated, and should I start another thread for the php cache issue?

Thanks!

It isn't very clear what this option does. We ran into the issue when upgrading an existing site to the latest drupal 8: the views would display content in the source language rather than in their translation. As a workaround, we started changing the setting to "Content language selected for page".

We only found out, that the setting "Content language of view row" works if used together with the filter "Content: Translation language”. It would be great if there was some explanation on how the rendering language options work. If my assumptions are correct: If the "Content language of view row" option is set, it could also check for the "Content: Translation language" filter to exist and if not output a warning?

Problem/Motivation

See: #2489460: [Meta] Move module.theme.css files to Classy

Proposed resolution

Move the CSS file to Seven.
Create a library for the CSS file.
Add the library in the seven twig template.

Remaining tasks

Apply the latest patch and provide some screenshots before/after like on #13.

User interface changes

None for Seven. Stark will be more stark.

API changes

Data model changes

Problem/Motivation

Follow-up to #2918761-80: Break up MigrateUpgradeForm into smaller forms.

+++ b/core/modules/migrate_drupal_ui/src/Form/IncrementalForm.php
@@ -111,17 +111,14 @@
-    if (empty($valid_legacy_database)) {

On the form page, can we make it a little easier for folks and not require a new uid/pwd if we previously had a uid/pwd stored. And if it is empty, then don't overwrite the previous creds. We'll want to add a descriptive comment on the creds page stating the uid/pwd is optional if it doesn't change.

Proposed resolution

Remaining tasks

• Do it.
• Test it.

User interface changes

API changes

Data model changes

This would allow developers to get the country names in a language different from the current UI language.

My current use case: when a user submits an entity with a country field, a mail containing the selected country name is sent to another user. The country name in the mail should be in the preferred language of the recipient user, but of course it might not be the language the first user used when filling the form. I get the country code, but I have no way to get the country name in the recipient's language.

Problem/Motivation

In #2862041: Provide useful Views filters for Content Moderation State fields, I noticed that a view with a missing/broken filter handler returns results as if the filter were not there. This could be dangerous because the filter could have been limiting results in a way that is now bypassed.

Proposed resolution

I thought that #2212081: Remove views optional handler handling or #1879774: Catch plugin exceptions for invalid views display plugins had made it so that views with broken handlers returned no results, but the scope of those issues is different. The first issue simply removed the optional handlers and let the view to continue to work; the second was only for display plugins, not all handlers.

We should discuss whether the view should return no results in this bad data integrity scenario, whether it should be disabled somehow, whether it should actually be throwing an error, etc.

Making the view return no results could be very disruptive, because if existing sites have broken handlers then updating to a release where this was fixed would make pages that were returning content suddenly return no content. Throwing an error to end users would be even more disruptive. So I'm not really sure what to do here.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Hi,

I'm not sure if this is a bug or this has been done intentionally, but in /core/modules/user/src/Form/UserPasswordForm.php the help text 'Password reset instructions will be sent to your registered email address.' is put in $form['mail']['#markup'] instead of #description.

This means that if you want to control the position of the description text (before/after) then the above text is ignored.

Should this not live in #description?

Cheers

Tom

Since #1446932: Improve statistics performance by adding a swappable backend was committed statistics_title_list function is not used anymore.

It's specific use was to generate a query to pass into node_title_list for the statistics block, but now all queries have been abstracted we can't even use node_title_list anymore.

In theory we shouldn't remove this function, but as soon as someone uses a no-sql backend for statistics it will not work, and never can, because the function returns a query. It seems safer to remove than deprecate.

Problem/Motivation

For revisionable entity types, core's SQL entity storage always creates dedicated data and revision tables for configurable and multi-valued base fields.

However, DefaultTableMapping::getTableNames() does not return the revision table name for multi-valued base fields of a revisionable entity type.

Proposed resolution

Fix \Drupal\Core\Field\BaseFieldDefinition::isRevisionable() to return TRUE when the base field has multiple values.

Remaining tasks

Review.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope, the storage correctly creates the table already.

Problem/Motivation

In the Ideas queue, on #2592487: [meta] Help system overhaul, we are proposing adding the currently-sandbox Help Topics module to Core as an Experimental module.

The main new features this adds are:
- Ability for modules, themes, and distributions to distribute arbitrary numbers of help topics (instead of just one and just for modules). This allows topics to be task-based and user-centered rather than organized by module.
- Because help topics are config entities, they can have dependencies (such as one of module A's help topics depending on also having module B installed).
- The help topics can be arranged hierarchically and have cross-links: topics can have a parent topic, plus a list of "related topics", and topic X can also say "I'm related to topic Y" so that if topic Y exists, X will be listed as related on that topic (allowing contrib topics to list themselves on core topics, for example).
- The admin/help page lists top-level topics only (for less clutter).
- Administrators can edit topics and create their own (to make a help system specific to their site).
- Help topics bodies are HTML, with a text format, so they can be edited much like Node module content items.
- Each help topic is broken up into paragraph-sized chunks, and stored as translatable configuration (so they can be translated on localize.drupal.org by paragraph). See also #1885192: Field locales_source.source is not suitable for long texts and huge config objects -- this is not only desirable but necessary -- long topics definitely need to be broken up into smaller strings.
- No PHP knowledge is required to author help topics.
- The existing hook_help() system and Tour module are not replaced by this system, since they complement each other.

Proposed resolution

a) Approve the Plan on #2592487: [meta] Help system overhaul so that this becomes an official Initiative. Note: There are alternative proposals, so we need to finalize that decision.

b) Add the Help Topics module to Core, initially as an Experimental alpha module (this issue). To do that, we need to resolve these issues and get them into the patch here:
- [DONE!]#2942643: Remove the Preview functionality
- #2943919: Make sure route tokens have cacheable metadata
- [DONE!]#2943923: Connect help topic view page to admin page

c) Once this is in Core as an alpha experimental module, we'll open a Meta issue to get this to Beta quality (which will be necessary to keep it as a live Experimental module in a full Drupal release). Sub-issues that we currently have for that phase (which are currently filed against the Sandbox module, but will be moved to Core once we have the module in there and an issue component):
- [DONE!]#2942644: Config export contains CR characters
- #2942645: Translation UI must not allow changing HTML structure
- #2664830: Add search capability
- #2923918: Theme autocomplete is not ordered
- #2943917: Don't use Entity::url()
- #2943920: Use newer API for getting module info
- #2943921: Move body set/get to a unit test

d) To get this module to full release, we will additionally need to do this:
- #2687107: Write some core help topics

e) And there are a couple of issues that we may or may not eventually need:
- #2927346: CKeditor buttons for DL lists
- #2665784: Add a token for images and a way to manage images

Remaining tasks (and how to help)

On this issue, the task is to get the patch approved for this to be an experimental module (see Proposed Resolution for list of issues to be resolved). We are simultaneously updating the sandbox project so that it stays in sync with the patch here. So, you can review/test either the code in the patch here, or the code in the sandbox repository.

For this issue to be completed, the tasks are:

(0) Prerequisite: Agree on whether this is the best approach -- see #2592487: [meta] Help system overhaul

(a) Module tested, including usability testing. Usability demos resulted in a number of issues being fixed. See Proposed Resolution section above for remaining issues that need to be resolved.

(b) Code in patch reviewed. No known issues at this time, but the code needs a final review.

(c) [Done] Choose name for module -- See
#2921120: Change name of the module
The name "Help Topics" chosen on that issue has been incorporated into the patch here.

(d) Patch finalized with feedback from above items
(patch is being kept updated on each commit to the Sandbox repository, so all Fixed issues are reflected in this patch)

(d) Patch committed

We are using individual issues in the sandbox project to track what needs to be done to improve the code and module. Issue list:
https://www.drupal.org/project/issues/2369943
If you review the code or test out the module, please file issues in the sandbox project if you find things that can be improved. Or you can comment here and someone else can turn them into issues.

Testing notes: After applying this patch and installing the Help Topics (help_topics) module, you can go to
admin/help
and see the current (fairly small) list of top-level help topics (there's an issue about writing more: #2687107: Write some core help topics). Click on one, and you'll see related topics. Also, you can try out links within the text of some topics that will take you to related administrative pages, or to other help topics. The other thing to test is the UI for editing and creating new help topics:
admin/config/development/help

User interface changes

A new Experimental module providing configurable help topics is added, along with a few new help topics. It has an administrative UI for authoring and translating help topics.

The only change to existing UIs is that this module adds a section to the admin/help page that lists the top-level topics, and a section to admin/config to reach the admin UI for authoring help.

API changes

No changes to existing APIs.

Defines a new config entity type (for the help topic).

Data model changes

No changes to existing data models.

The new help topic config entity defines a new schema for saving the help topics to config YAML.

People to credit on this patch

This patch was made by the following people, who contributed patches/tests/reviews on either
#2351991: Add a config entity for a configurable, topic-based help system
or on various Sandbox module issues at https://www.drupal.org/project/issues/2369943, or at Usability group meetings, or here on this issue:
alexpott
amateescu
andypost
benjifisher
catch
ckrina
Fabianx
Gábor Hojtsy
gnuget
jhodgdon
jibran
larowlan
MariaDenysyuk
miro_dietiker
Mixologic
sandboxpl
SenthilMohith
tim.plunkett
tstoeckler
vijaycs85
webchick
webflo
yo30
yoroy

Problem/Motivation

Views page with exposed text filter set as required filter will show an empty error message and a form error for the required filter when first loading the page, before you actually have a chance to input anything

Steps to reproduce:
- Go to the Content admin view
- Make the title filter to required
- Look at the preview or go to the content admin page

Proposed resolution

Only show the error after searching without the required filter.

Remaining tasks

Make a patch
Add tests

I can see that "Content:Has taxonomy term (with Depth)" is available as a contextual filter.
But I would like to use the Group by function to display my Taxonomy Terms in their hierarchical form, if nothing else than to provide a menu to use to select the term for the contextual filter view.
Am I just not finding the built-in functionality to do that, or is this a feature request?

After trying to upgrade to 8.5.0-beta1 aswell as following upgrade path for Media entity module we have errors on our site, I tried to go back to 8.4.4 (dump) and do the update again but it resulted in getting these errors.

The website encountered an unexpected error. Please try again later.</br></br><em class="placeholder">Drupal\Core\Database\DatabaseExceptionWrapper</em>: SQLSTATE[42S22]: Column not found: 1054 Unknown column &#039;revision.revision_default&#039; in &#039;field list&#039;: SELECT revision.vid AS vid, revision.langcode AS langcode, revision.revision_user AS revision_user, revision.revision_created AS revision_created, revision.revision_log_message AS revision_log_message, revision.revision_default AS revision_default, base.mid AS mid, base.bundle AS bundle, base.uuid AS uuid, CASE base.vid WHEN revision.vid THEN 1 ELSE 0 END AS isDefaultRevision
FROM 
{media} base
INNER JOIN {media_revision} revision ON revision.vid = base.vid
WHERE base.mid IN (:db_condition_placeholder_0); Array
(
    [:db_condition_placeholder_0] =&gt; 1
)
 in <em class="placeholder">Drupal\Core\Entity\Sql\SqlContentEntityStorage-&gt;getFromStorage()</em> (line <em class="placeholder">455</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php</em>).

To resolve this i managed to do so with adding manually a column 'revision_default' on the table: 'media_revision'. So i could access my website.
But if i go to content/media, or try to add media types it works, but creating a new media or editing an existing one (i had only one so far) results in this error:

<em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;media_bundle&quot; entity type does not exist. in <em class="placeholder">Drupal\Core\Entity\EntityTypeManager-&gt;getDefinition()</em> (line <em class="placeholder">133</em> of <em class="placeholder">core/lib/Drupal/Core/Entity/EntityTypeManager.php</em>