Port Field Permission Example to Drupal 8

Found a couple of typos, and rearranged the module file to a more logical order.

Correct handling of users requires a little more code; now added.

Probably a good time for some feedback. There are probably some typos and formatting issues that need fixing, but this should give you a sense of how I approached it.

The code works, and while I haven't posted it yet, I have a test based upon the ones used by the Field module in core (SimpleTest KernelTests, because that's what's currently in core for fields). These cover enough cases that I have some confidence in the code.

I've gotten things pretty well cleaned up, and scanned the verbiage to make sure that it reflects changes in the code between versions.

Pretty happy with the test class. Run it as

php scripts/run-tests.sh --non-html --verbose --url http://YOUR-IP/ --class '\Drupal\field_permission_example\Tests\FieldNoteItemTest'

to see what combinations it hits. 36 in all. Plus the regular tests that core plugins get. I've just checked against today's RC1-post HEAD; all tests pass.

Hopefully this does what you need. I suspect that you'll want some formatting changes, but this should be close to what you want, I think.

Checked against phpcs with drupal policies. All errors have been fixed, most warnings as well.

I'm not sure if anything needs to be changed to fit documentation standards, but at this point, it looks like Drupal code.

Noting #2567501: [meta] Add _permission: 'access content' to applicable routes; I'll post another patch to handle this, already done locally.

Just discovered #2102699: Port field_permission_example module to Drupal 8; making this a child and claiming the parent.

Starting this one back up. Test is now in.

The new patch is not interdiff-able with the old ones for some reason. There will be interdiffs going forward.

Patch applied properly (although there were whitespace warnings).

Anyone have advice how to get "git diff" to generate patches that don't have these errors on "git apply"? I'm using a Mac, and beginning to think that's a Mac related thing.

After enabling, there was no menu item added as a child of "Examples" in the toolbar.

Ah, I see that the Block Example does that. I'll be the monkey in Monkey See, Monkey Do, and add this.

When I visit the admin page for the submodule (/examples/field_permission_example) I get an Access Denied error.

This is new misbehavior since I last did the dev on this. I'll see it also, and I'll see what's up with that.

OK, just discovered hook_toolbar, and apparently, *.routing.yml uses _permission instead of _access. So let's try this one on for size.

Fixed the typo.

@jlbellido -- we may want to agree what's a reasonable level of "deprecated" to removed it from Examples.

entity_create(), for example, is slated to go out, but only in Drupal 9.0. It is still listed as used > 450 places in Drupal 8.x.

I can remove these, but I think it makes more sense to get valid code checked in, and deal with 9.0 deprecation issues over the next several years, since 9.0 is likely more than 3 years out, and possibly as many as 5.

I've created #2662976: META -- how do we deal with deprecated APIs in 8.x-1.x, since I'd like to get a consensus as to how we handle APIs that are still in heavy use in Core (which is where I got the code @jlbellido is referring to), but are planned for removal in 9.0.

I'd argue we need to keep this issue in mind, but do not need to get very far ahead of Core in doing it.

You could un-assign yourself if you want someone else to deal with that part. Everyone still gets commit credits. :-)

?? Really??

In any event, here's the corrected code.

This whole docblock needs to wrap to 80 chars. Low priority though because I can fix coding standards stuff on commit.

No need, already set up with drupalcs and kin. I'll reflow it.

This isn't actually true. $this->container is the same one the kernel under test uses, and is also the same as \Drupal during the test run. It's correct that we want to use the supplied container, however.

What I meant here is that you can't (usefully) implement ContainerInjectionInterface, since this assumes the constructor will declare its injections (for a simpletest-style test, the constructor takes the test ID, and gets pissy if you do anything else). I will clarify the comment accordingly.

You can, as you point out, use $this->container to get at a reasonable container. Note that I'm already doing this to get at the entity storage.

This is a great idea, but it's untranslatable. We have to use the controller that returns translated text.

I forgot to wrap the HTML in a {% trans %} block. I've just done this locally and tested this with drush potx multiple --api=8. It will work fine once I check in the modified template:

# $Id$
#
# LANGUAGE translation of Drupal (-var-www-drupalvm-drupal-modules-examples-field_permission_example-templates)
# Copyright YEAR NAME <EMAIL@ADDRESS>
# Generated from file: /var/www/drupalvm/drupal/modules/examples/field_permission_example/templates/description.html.twig: n/a
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: PROJECT VERSION\n"
"POT-Creation-Date: 2016-02-08 23:11+0000\n"
"PO-Revision-Date: YYYY-mm-DD HH:MM+ZZZZ\n"
"Last-Translator: NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <EMAIL@ADDRESS>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=INTEGER; plural=EXPRESSION;\n"

#: /var/www/drupalvm/drupal/modules/examples/field_permission_example/templates/description.html.twig:12
msgid "<p>The Field Permission Example module shows how you can restrict view and edit permissions\n  within your field implementation. It adds a new fiel\
d type called Fieldnote. Fieldnotes\n  appear as simple text boxes on the create/edit form, and as sticky notes when viewed.\n  By 'sticky note' we mean '\
Post-It Note' but that's a trademarked term.</p>\n\n  <p>To see this field in action, add it to a content type or user profile. Go to the\n  permissions p\
age (@admin_link) and look at the 'Field Permission Example' section. This\n  allows you to change which roles can see and edit Fieldnote fields.</p>\n\n \
 <p>Creating different users with different capabilities will let you see these behaviors\n  in action. Fieldnote helpfully displays a message telling you\
 which permissions it is\n  trying to resolve for the current field/user combination.</p>\n\n  <p>Definitely look through the code to see various implemen\
tation details.</p>"
msgstr ""

This should resolve nicely on localize.drupal.org, or in any POT editing tool. And will be easier for a translator to handle, based on my experience with that crowd :-)

I've modified the comment, run the whole module through drupalcs, and inserted the needed L10n blocks into the template. Should be close enough for gov't work.