Review/update block_content hook_help text

The following text is not clear: ( /admin/help/block_content)

Uses

Creating and managing custom block types
Users with the Administer blocks permission can create different custom block types, each with different fields and display settings, from the Custom block types page. The Custom block types page lists all of your created custom block types, and allows you to edit and manage them. For more information about managing fields and display settings, see the Field UI module help.

Creating custom blocks
Users with the Administer blocks permission can add custom blocks of each of their defined custom block types. Created custom blocks are then listed on the Blocks administration page.

**********************************************************************
I think it should be clearer that a custom block is created from a block type.

This patch changes wording to make explanation a bit clearer regarding the differences between a custom block and a block content type.

This text looks great to me! I like the changes, and I think it's clear.

Someone should manually test both the Custom Blocks help page, and the text provided by this at the top of admin/structure/block/block-content and make sure the links work correctly.

Also, was this issue supposed to be for the Block module or the Custom Block module or both?

Right component

- $output = '<p>' . t('This page lists user-created blocks. These blocks are derived from block types. A block type can consist of different fields and display settings. From the block types tab you can manage these fields as well as create new block types.') . '</p>'; + $output = '<p>' . t('On this page you can create and view blocks of the different <a href="!types">block types</a>.',array('!types' => \Drupal::url('block_content.type_list'))) . '</p>'; return $output;
This text was added to specifically address that the types tab and the fact that blocks can have fields has lower discoverability in the ui.
Side note:Why are we doing this again, other than a name change the module hasn't changed since the help text was added.

larowlan: This patch is mostly just making minor changes to the help... the idea is that now that features are fairly stable, it's a good time to review all the help and make sure it makes sense and is accurate.

And... I don't see why on the page that lists the individual block items you've created, we need to explain that block types can have fields? Linking to the block types page seems like the right thing to do?

Since this is now a "fix the help" issue, changing parent.

Instead of having one critical parent issue I have been asked to change the status of each child issue.

This one doesn't feel critical or major to me, so leaving as-is. Doesn't mean we shouldn't work on it though!

Coming back to this patch..

I did some more rewriting. As a note, help should provide concepts and a road map to the functionality, but it should not get specific about how to use the (hopefully obvious) user interface. That is especially true for the page-level help.

Also we have to be careful about Field UI, because this is not a required module, so to make a link to its help we need to check if it's enabled.

With that in mind, here's a new patch. As every line differs from the last patch, I did not make an interdiff file.

Fixing component

Based on https://www.drupal.org/patch/reroll I ran git log --before="January 14, 2015" and could not find the commit for the issue.

I'm not sure if I am suppose to see it.

I re-ran the test (which passed on January 14, 2015) today and now its showing (failed). I'm just not that clear on the next step to do the re-roll?

- needs manual testing
+ needs reroll

rerolled patch

sorry i didn't notice that the routes.yml changed so i adjusted the patch to the new routes..

Revised and tested manually, since the automatic test passed. The change looks good!

Screenshot attached.

+1 RTBC

attaching missing interdiff from #25

Thanks for rerolling and reviewing!

Can you confirm @jribeiro that you tested all of the links in the help and verified that they go where they should? And that you verified that the text in the help, when it refers to page names, button or link text, etc. matches what you actually see in the Drupal UI?

Also adding beta eval to issue summary.

I'm at the Bogota sprint and I will verify that the links go to the right place.

I have checked all the links and they all go to the right place.

Excellent, thanks very much! Should be good to go then.

git diff --color-words
is helpful to review

---

I wondered why some links have page inside the html anchor tag, and some do not.

I wondered if this might effect translators.

I looked in core to see if one was THE way.

$ ag --literal "</a> page"  | wc -l
      56
[~/foo/drupal2]
[ctheys]  [git:8.0.x]
$ ag --literal " page</a>"  | wc -l
      93

So it seems we have both. And not something to worry about in this issue.

rtbc from me too.

------
this applies. so removing the needs reroll tag.

Great work!

Committed and pushed to 8.0.x. Thanks!