Provide a list of blocks and the modules that provide them

[ghost]

As per #345 (comment)

---

Latest PR from @docwilmot: backdrop/backdrop#1528

[ghost]

Some other ideas I had for this page (that aren't implemented yet) are:

• Display block description under block name (need to work out how to style it so the block name stands out - I thought of making the description a lighter colour or making it italic)
• Add another column that lists (and links to) the layouts/regions where the block is enabled (need a new function for this I think)

[ghost]

Here's what it currently looks like:

[quicksketch]

Add another column that lists (and links to) the layouts/regions where the block is enabled (need a new function for this I think)

That sounds like a great feature. It'd let you know if it was safe to delete a custom block for example.

As-is, what value is this page providing? It's true that the only place you can get a listing of blocks is through Layouts' "Add block" dialog, but is it necessary to see it anywhere else? This might be equivalent to seeing a listing of Views fields available or Actions registered. You can't see either other than within where these systems are actually necessary.

The use-case of a custom block's usage, perhaps it'd be better to inline that warning when you delete a block, warning you that it is in use on layouts before deleting. All other blocks, it's unusual that you'd disable modules that provided in-use blocks (and if you did, they'd just show up as "broken" placeholder blocks in the admin UI).

[ghost]

As-is, what value is this page providing?

I thought of this when migrating blocks to views and realised that I couldn't tell if a certain block still existed or not, so thought a list of blocks would be nice.

This might be equivalent to seeing a listing of Views fields available or Actions registered. You can't see either other than within where these systems are actually necessary.

Actually, a list of Views fields is available here: admin/reports/fields/views-fields 😄

[ghost]

Also, once people start using layouts more, and they have lots of layouts for nodes, user accounts, pages, forms, etc., it might be handy to see where a specific block is being used, rather than having to check each layout manually...

[quicksketch]

Actually, a list of Views fields is available here: admin/reports/fields/views-fields 😄

Touché. ;)

it might be handy to see where a specific block is being used, rather than having to check each layout manually...

Yeah, I think this would make the page worth it. The views page isn't a list of all views fields, it's a list of which Field API fields are used within Views.

[ghost]

Ha! It seems someone else was also missing the block listing: http://enzolutions.com/articles/2014/12/29/backdrop-cms-first-impressions/
😃

[ghost]

Updated PR for latest code.

[herbdool]

I'll vote for this too.

[docwilmot]

I'd vote for this but not under reports menu; under layout

Layout
-Add layout
-List layouts
-List available blocks

Makes more sense there.

[docwilmot]

Posted an update of @BWPanda's PR at backdrop/backdrop#771

• switched to use existing layout_get_block_info() rather than loading all layouts
• added two new columns for
  • required contexts
  • block usage
• added new function layout_get_block_usage($delta = NULL) to get data about where blocks are being used.

[docwilmot]

May not get into 1.4.0 given the time, but wont be from lack of trying 😄

[quicksketch]

The PR looks good. A few things:

• A test to check that block usages are shown.
• Some help text would be useful at the top of this page describing what is being displayed.

[klonos]

@BWPanda++ on the filtering ...not so sure about splitting layouts and regions to separate columns though ...although some region names are common in many layouts (header/footer, top/bottom, content etc).

Anyways, I would like to take this chance to shamelessly promote #503 (introduce a reusable, instant, find-as-you-type filtering system that has consistent look/feel in various listing pages).

[jenlampton]

No progress made on this since May, officially bumping from 1.5 to 1.x-future.

[docwilmot]

New PR up, although bumped to future.
backdrop/backdrop#1531

[olafgrabienski]

Seems that the test site of the PR haven't been installed. Clicking the link, I get the install page (core/install.php).

[jenlampton]

If you close and open the PR you can generate a new test site.

[olafgrabienski]

Found the new test site, thanks!

Regarding the block list: As a newer backdrop user, I'm late here. Wanted to ask why the vote to put the block list not under Reports but under Layout (#449 (comment)) isn't in the PR. I guess it would be helpful to have the Block list near the Layouts, and I didn't find any objection in the issue. Did I miss something?

If the list however remains under Reports, shouldn't the name of the menu item be "Blocks" (in analogy to "Fields" etc.) and not "List blocks" (which in return would make perfectly sense under Layout)?

[quicksketch]

This functionality looks great. When reading the issue here I found myself again resisting it, but then when I saw what it actually did, I thought it was very valuable. Nice job @docwilmot again on this.

Wanted to ask why the vote to put the block list not under Reports but under Layout (#449 (comment)) isn't in the PR. I guess it would be helpful to have the Block list near the Layouts, and I didn't find any objection in the issue. Did I miss something?

I think we may have a consistency issue here. Right now we have two other major modules providing very similar pages under Reports: Views and Field. I think we should create a separate issue to decide on rearranging all of these reports at the same time. How does that sound?

[quicksketch]

I left some feedback on the PR: backdrop/backdrop#1531 Looking great though! I'll slate this for 1.5.0 and we can see if we can make it in. We can move it if it's looking unlikely.

[olafgrabienski]

That sounds good! Even though, in the moment, I'm not sure what to propose exactly. Have to think about it!

[docwilmot]

I'll slate this for 1.5.0 and we can see if we can make it in. We can move it if it's looking unlikely.

Great. Its not urgent obviously so no rush.
Also need to do column priority for mobile.
And @quicksketch you OK with my fake tablesort?

  $order = tablesort_get_order($header);
   $sort = tablesort_get_sort($header);

   backdrop_sort($rows, array($order['sql'] => SORT_STRING));

I made an issue (#2149) to modify backdrop_sort() to allow sort direction because this implementation only allows sorting one direction: ascending. Should we keep this?

[quicksketch]

And @quicksketch you OK with my fake tablesort?

Yeah fake table sort is fine, as we don't have any way to tablesort on non-SQL columns currently.

I made an issue (#2149) to modify backdrop_sort() to allow sort direction because this implementation only allows sorting one direction: ascending.

As we don't have a reverse backdrop_sort() yet, but you need one now, why not do a standard-backdrop_sort() and then just array_reverse() the order?

[docwilmot]

just array_reverse() the order

Brilliant. Worked of course.

[quicksketch]

Merged backdrop/backdrop#1531 into 1.x for 1.5.0. Way to knock out another one @docwilmot! Thanks @olafgrabienski for your input and @BWPanda for getting the ball rolling on this so long ago.