Problem/Motivation

Facts for Drupal 8.0 & Drupal 8.1's REST:

1. REST module's EntityResource respects Entity Access & Field Access.
2. REST module requires every entity type to be explicitly enabled in rest.settings.yml.

Therefore it is very confusing that every entity type gets another permission, per verb, to be able to actually use that REST resource.

Proposed resolution

@klausi at #1816354-1: Add a REST module, starting with DELETE:

Access control is also a problem right now, we don't have that in the routing system yet (see #1793520: Add access control mechanism for new router system for work on that). And we don't have something like entity_access() or access controllers in core (see #1696660: Add an entity access API for single entity access for that). I think I will just expose my own permissions right now ("read resourceXY over REST API", "create resourceXY over REST API" etc.) and check for that.

That is the issue that brought REST to core. It was not at all discussed further. No follow-up was created. In other words: very little scrutiny was applied to the REST module before it could be committed to Drupal 8. I'm certain such a patch would not have been able to land in the past few years (say, since 2014) — it looks like we were far more lax in 2012.

It's totally possible that access handling in general and permission handling in particular were discussed elsewhere, but if so, I could not find it (I looked at all these issues).

The only other issue that was remotely related is #1866908: Honor entity and field access control in REST Services. In there, two commits happened:
the first marked \Drupal\rest\Plugin\rest\resource\EntityResource::permissions()'s permissions as "restricted" (this method no longer exists), as a stopgap. The second commit removed that, and instead added proper entity access checking. But … it did in fact NOT remove the permissions for entities! It just kept them!

In other words, the only reason permissions still exist, at least for EntityResource, is simply that this was overlooked. No follow-up issue was created, and thus it was simply forgotten. It makes sense to allow @RestResource to opt in to having a permission, for example in the case of DbLogResource. But it does not make sense to always have this, without even the ability to opt out!

We (which includes dawehner, Crell, I, and others) also discussed this at DrupalCon New Orleans and unanimously agreed that:

1. it does not make sense for Drupal 8 to continue to have permissions enabled by default for EntityResource
2. we should not break BC
3. we should therefore make sure that newly installed Drupal 8.2 sites don't need to enable these permissions for EntityResource, but existing Drupal 8 sites will continue to use that

This issue/patch therefore proposes:

1. we keep permissions enabled by default for @RestResource plugins: this guarantees BC for all custom/contrib REST resources
2. we remove permissions from EntityResource in Drupal 8.2.x by default, but keep them enabled for existing Drupal installations
3. we document A) why we have permissions, B) how you can opt out from permissions for a particular REST resource

Remaining tasks

None.

User interface changes

None.

API changes

• The EntityResource@RestResource opts out from generating the permissions that ResourceBase generates by default, but only for new sites.
• Other @RestResources continue to generate permissions. This means all contrib/custom ones continue to work as they do today.
• For details, see the change record: https://www.drupal.org/node/2733435.

Data model changes

New key in rest.settings configuration: bc_entity_resource_permissions. Upgrade path provided: rest_update_8203().

Problem/Motivation

The datetime views plugins have wonky timezone support. This needs to be fixed. While most evident in the argument plugins, the filter, and sort plugins have similar problems.

Proposed resolution

Because of coupling with the views architecture, fixing the individual plugins with separate issues is essentially impossible. In addition, a proper fix means moving some backend specific code out of the generic Sql class (date handling in SQL is not equivalent between the supported databases), and fixing some date support in Views itself.

Remaining tasks

Cry, then fix all the things and provide test coverage.

User interface changes

None.

API changes

TBD. It looks like some very low level Views classes may have interface changes.

Data model changes

Original Report

The datetime View Arguments don't take into account the user's timezone. That means that if you make a View that has \Drupal\datetime\Plugin\views\argument\YearDate argument then all users will same events even if the timezone for a user would push certain events into either the next or previous years.

This is probably an edge case for years but for the new arguments in #2567815: Add week, date, and year-month Views argument plugins would be more effect by this.

So if you used the FullDate argument then dates that would be in a different day because of the user's timezone don't show up correctly.

Working on a patch

Problem/Motivation

* \Drupal\Core\Entity\EntityInterface has a createDuplicate() method with which other code can create a duplicate of an entity.
* There is no such method for fields. But fields really should know how to create a copy of themselves.
* A nontrivial use case for this is paragraphs (or any other fieldable-fields-like module): When copying the field, the referenced paragraph must be copied. Note that a paragraph is just a behavior of the underlying reference field, and there are reference fields that should not get the referenced entity copied.
* We have a contrib module replicate which implements this (and which dawehner ported to D8), but this should really live in core.

Proposed resolution

(inspired by dawehner's replicate port)
* Provide a method \Drupal\Core\TypedData\TypedDataInterface::createDuplicate which basically
** delegates to contained TypedDataInterface or does a clone
** fires an event (that e.g. paragraph can subscribe)

Remaining tasks

* Decide on architecture
* Roll a patch and get it in

User interface changes

None.

API changes

API addition, no BC break.

Data model changes

None.

Regarding the classes in Drupal\views\Plugin\views\argument

I agree with the class description for Formula and Date - that they should be abstract. So we should insert the abstract keyword?

I am just going to create a patch with abstract inserted and see what blow up.

Phase 2

As a follow up there are things that flow from this train of thought.

I think there are some interfaces that need to be created.

For example Drupal\views\Plugin\views\argument\DayDate::format

it is documented with a @inheritdoc which is incorrect but can be made true by adding an interface!

Problem/Motivation

1. Currently, "page" views override all GET routes with the same path.
2. Consequence: REST GET routes are overridden too.
3. Consequence: the default Taxonomy Term view makes it literally impossible to GET a Taxonomy Term via REST.

Proposed resolution

1. \Drupal\views\Plugin\views\display\Page should only override routes that are render array-based, i.e. that have no _format
2. (although perhaps those routes should get a default _format route requirement, just like \Drupal\Core\EventSubscriber\RouteMethodSubscriber::onRouteBuilding() already sets a default _method requirement?)
3. \Drupal\rest\Plugin\views\display\RestExport shouldn't alter any routes

Remaining tasks

TBD

User interface changes

None.

API changes

TBD

Data model changes

None.

Problem/Motivation

Text Formats are running on REST json requests. This makes Drupal less useful for a REST backend and can lead to duplication of effort when attempting to use Drupal to feed data to another source.

Proposed resolution

Make Drupal use text input formats for long text fields.

Problem/Motivation

Unauthenticated users send a POST request on http://mysite.com/entity/user get a 403, and rightfully so because creating users in an administrative task.
That being said registering a user should be allowed if the site permits.

Proposed resolution

Create a user registration resource that allows users to be registered into the system following the settings on admin/config/people/accounts.
This means anonymous users can register an account just as if they could on a regular drupal form.
A workaround would be to login as an admin and create a user the regular way.

Remaining tasks

1. Land blockers:
   1. #2626298: REST module must cache only responses to GET requests
2. Get patch to RTBC

User interface changes

None

API changes

None

Data model changes

None

Original report by [username]

I have enabled /entity/user REST end point for POST request.
I have give anonymous user permission "Access to POST on user entity"
I have also enable "visitor" to create an account on my Drupal site.

My rest.setting has an entry as shown below

'entity:user':
    GET:
      supported_formats:
        - hal_json
        - json
      supported_auth:
        - basic_auth
    POST:
      supported_formats:
        - hal_json
        - json
      supported_auth:
        - basic_auth

I tried a POST request on http://mysite.com/entity/user

with headers

Content-Type : application/hal+json

and with body

{"_links":{"type":{"href":"http://tntfoss-vivekvpandya.rhcloud.com/rest/type/user/user"}},"name":{"value":"ronak1"
  },"mail":{"value":"ronak1.patel@gmail.com"
  },"pass":{"value":"ronaK123"
  }

}

It give me 403 forbidden.

If I pass credential in Authorization header it works for me.

It should also work for anonymous user because always visitor(anonymous) user will try to create account on the site.

I need review from community is it a bug ?

Discussed with @catch on IRC to close #23298: Entity bundles should declare a plural form of their label in favour of this.

Problem/Motivation

Entity types can define now plurals for their labels starting with #1850080: Entity type labels lack plurality, cannot generate UI text based on label if plural is needed. It's possible now to have the variants "content item" (singular) and "content items" (plural) for nodes. We want the same for bundles. We want to be able to have "article" (singular) and "articles" (plural).

It's not the same as for entity types. Entity types can define the label plural variants in the annotation while for bundles the site builder should be able to add such variants. Thus we need to store the variants in the bundle config entity and provide UI for site builders.

Proposed resolution

1. Make \Drupal\Core\Config\Entity\ConfigEntityBundleBase implement a new interface ConfigEntityBundleInterface.
2. Add next methods to the new ConfigEntityBundleInterface interface: getSingularLabel(), getPluralLabel() and getCountLabel(). These are similar to those implemented to entity types.
3. Create a 'bundle_config_entity' schema that contains the new storage keys: label_singular, label_plural, label_count.
4. Implement the UI and storage for NodeType entity type.

Remaining tasks

Open issues for each bundle type that requires label plurals.

User interface changes

User is able to add plural variants in NodeTypeForm UI.

The site is installed in English (2 variants)

The site is installed in Romanian (3 variants)

API changes

New interface \Drupal\Core\Config\Entity\ConfigEntityBundleInterface:

• getSingularLabel()
• getPluralLabel()
• getCountLabel()

Data model changes

The bundle config entity has new keys/values: label_singular, label_plural, label_count.

Problem/Motivation

When many queries happen on the same tables the sheer volume of preg_replace() calls can easily save upwards of 100ms-200ms on approx 8000 sql calls by avoiding doing the preg_replace on the same table or field names.

More typical 10-30ms savings on a 600 sql query page.

Proposed resolution

Add a static to each method to memo-ize the preg_match results.

Problem/Motivation

When providing a contextual filter, users are given the option to override the title when the filter value is available. I created a view that required the override for this title in a block but when showing, it always removed the override title and showed the regular set title.

Proposed resolution

The view block needs to have all the information for the title before proceeding. Currently the title is just falling back to the original. Moving title creation lower allows the view block to know it has an overridden title.

Remaining tasks

I have found the issue and will post a patch shortly. The only remaining task would be to review.

Problem/Motivation

Follow-up discovered while testing #2405059: Replace menu images with Libricons.

A menu in the sidebar configured to display expanded sub-menu items does not properly indent.

Steps to reproduce

1) Modify the Home link in the main menu to "Show as Expanded".
2) Create a Basic Page, and add it as a sub-menu link of the Home page in the main menu.
3) Move the main menu out of the Header region, into one of the Sidebar regions of Bartik theme.
4) Configure the Menu Block to display an unlimited number of levels.

Proposed resolution

Add indentation for sub-menus using CSS margins.

Remaining tasks

Write a patch.
Screenshots.

User interface changes

Sub-menu items will be displayed hierarchically using indentation.

API changes

None.

Data model changes

None.

Problem/Motivation

#states do not work with 'datetime' form elements.

Proposed resolution

Update logic in the Datetime element to handle the nested elements.

Remaining tasks

Fix test fails.

User interface changes

None, other than #states working.

API changes

None.

Data model changes

None.

Original Report

While trying to create a custom field widget containing a "datetime" form element, I discovered that the #states attribute does not work on it.

Some states can be achieved with a workaround: put the datetime element in a container, and put the #states on the container. But this is obviously no clean fix, and it doesn't work for all states. (Works for "visible" for example, but not for "required".)

I was not able to figure out why this is not working, but I noticed that there have been a lot of issues regarding the #states attribute in the issue tracker. Most of them for were for specific elements like submit buttons, select elements with multiple values, ...

Problem/Motivation

We have a really flexible exception system which was a bit designed around the usecase of HTML, which requires you to have a different behaviour for every XYZ HTTP status code.
For the case of JSON/XML etc. this is though not the common case so its really cumbersome to create for example a 40X method for every possible one.

Proposed resolution

Introduce onX** methods, which catches all respecting cases.

Remaining tasks

User interface changes

API changes

Data model changes

Patch to commit is in #9.

Problem/Motivation

Software has bugs, so errors are there and will be logged.
Sadly by default Drupal just puts the line of the broken code, which is already helpful, but on the other hand often now really helpful, because you need a full backtrace to figure something out.

Proposed resolution

Log a backtrace on top of the actual error message.
This will just make the backtrace available in the variables section, but won't be displayed as part of the watchdog site.

Remaining tasks

User interface changes

API changes

Data model changes

A single user creating nodes continously results in PDOException: SQLSTATE[08004] [1040] Too many connections in lock_may_be_available() exception.

To simulate the problem, create nodes (e.g. article) continuously. Typcially on my machine i get the exception on creating 44 nodes.

my machine is a WAMP stack on Windows 7 with 3GB memory and i5 processor

Steps to create:
1. Login as admin
2. create a shortcut to node/add/article and call the short cut Article
3. run the attached seleinum test (which just creates nodes with text hello

after creating 44 nodes, the above exception occurs.

I've marked this as critical as the apachae has to be restarted for the site to start working again.

Follow-up to #2772235: Add test coverage for GoogleCurrencyConverterForm validateFinal Method

Embedded Form validation errors not showing on page.They are showing if you'll refresh the page.

Usecase :
Google Currency Converter module embeded the custom form into Block plugin ::build method, the validation provided by form is not working as defined.

Steps to Reproduce :

1. Define a block Plugin like GoogleCurrencyConverterBlock which embeds the form in build
2. Add a Custom form so that we embed in in the block build method. Define the custom validation method in the form.
3. Now place the block on home page.(Note: The block configuration validation is not working due to #2537732: PluginFormInterface must have access to the complete $form_state (introduce SubFormState for embedded forms) so don't post about it)
4. Go to homepage and select from and to currency as same, Now the validation will work and it will focus on the wrong data element but it will not show the error, what's the exact error it is.

Testing of exact problem in google currency converter project on simplytest.me :

1. Go to https://simplytest.me/project/google_currency_converter/8.x-1.x
2. Add the patch in Apply patches section on the screen https://www.drupal.org/files/issues/2772235-5.patch
3. And follow the steps to reproduce as mentioned above.

In admin/structure/menu/manage/account, the "My account" link has "(logged in users only)" appended.
The same should show for "Log out".
Also, it should show not only for menu items provided by the user module, because the same behaviour hold for manually created menu items targeting these paths.

Finally, for "user/login" and "user/register" the opposite holds, and the menu items should be appended "(anonymous users only)".

Problem/Motivation

My use case for this is a SAML authentication module (https://www.drupal.org/project/samlauth). Since authmap was removed, I need another way to store a mapping between local and remote users. The users_data table is a good place for that. However, when the external authentication service redirects back to the Drupal site, there's no way to find a uid in the users_data table given the unique ID that the authentication service hands us. The same is true for OAuth and likely everything else.

Proposed resolution

Add a query service.

Remaining tasks

Change UserData::get into a wrapper of this and move it into a UserDataBase class so other classes implementing UserDataInterface doesn't need to bother with the weird return data structure of UserData::get. This can be a novice followup.

User interface changes

None.

API changes

New service.

Data model changes

None. It's a simple query service.

Hello.

I just noticed image styles do not apply to the images I uploaded to a private folder. It just opens original image file. At the same time the same image style works as expected with images from public directories.

Thank you.

Problem/Motivation

Sporadically we get the following warning:
Warning: uasort(): Array was modified by the user comparison function in Drupal\Core\Plugin\DefaultLazyPluginCollection->sort() (line 100 of core/lib/Drupal/Core/Plugin/DefaultLazyPluginCollection.php).

A 100% repo is to use the "Entity Browser Module" when using a file field (in our case inside a field collection) with the File Browser widget.

Proposed resolution

According to this link:
http://shout.setfive.com/2013/06/14/symfony2-usort-array-was-modified-by...

The problem lies in the lazy loading of the plugin collection. So the fix is simple. In the sort() function (DefaultLazyLoadingPluginCollection) iterate through the array like this:

  public function sort() {
    // iterate to populatae the array
    foreach($this->instanceIDs as $id){
      $pluginId = $this->get($id)->getPluginId();
    }
    // original code
    uasort($this->instanceIDs, array($this, 'sortHelper'));
    return $this;
  }

Remaining tasks

reviews needed, tests to be written and run

User interface changes

none

API changes

none

Data model changes

none

Original report by [username]

none