You need an icon (if that is the worst anyone can find its doing well).

The beta installed nicely and worked. I could have used this (or recommended it to a customer) a few weeks back when they lost track of the page they had used an addon block on and thought it was an addon issue. I can see it becoming one of those tools that sits unused for ages, then for a few minutes becomes incredibly useful.

Does it search stacks & global areas?

I have not read the code. Before PRB you should double check the code yourself for exec or die and t() etc and other submission guidelines. Its amazing how many addons spend too much PRB time on such simple points.

I had a look at the code. It is very cleanly structured.

In the controller, the usual place for addHeaderItem() is in the on_start handler.

In the css, you have some selectors like table#id. As #id is unique anyway, do you really need the element type prefix?

In the tool, do you need to cache data? Does it make a significant difference to speed, especially as you advise users to clear it?

You have a few single line if()xxx; These may be against the code style guidelines (please check).

The note you have at the bottom of the dashboard page could also usefully be duplicated in the help, but in normal size text.

This is great! Looks clean on the first impression.

Drop me a message once you're done with coding and I'll make sure there's a German translation for it!

- "You need an icon..."
Agreed - it's been an active Github issue for that repo for a while. Good eyes :)


- "Does it search stacks & global areas?"
As of 0.9.0.4, no it doesn't. I can easily remedy that by allowing system pages to be searched as well (the permissions check during PageList requests should prevent users without view access from seeing those results)


- "In the controller, the usual place for addHeaderItem() is in the on_start handler."
Made it an issue.


- "In the css, you have some selectors like table#id. As #id is unique anyway, do you really need the element type prefix?"
Made a reminder to clean it up. I usually keep them during development so I quickly recall the type of element it's for.


- "In the tool, do you need to cache data? Does it make a significant difference to speed, especially as you advise users to clear it?"
I ran this on a site with 150+ pages and changing the pagination/sorting took as long as the initial search (which didn't seem right). With the caching it does speed things up quite a bit.

I only use the cached search results if the user changes the sorting, goes to a different paginated result page or adjusts the # per page option. As soon as they search for a new block type it ignores the cache and gets the latest data.


- "You have a few single line if()xxx; These may be against the code style guidelines (please check)."
Will do.


- "The note you have at the bottom of the dashboard page could also usefully be duplicated in the help, but in normal size text."
Good idea.


- "Drop me a message once you're done with coding and I'll make sure there's a German translation for it!"
Thanks! I'll bug you when I have the final text in place.


Thanks a lot for the feedback so far :D

About: "Does it search stacks & global areas?"

That might be my personal opinion but to me it would be great if your add-on would let me know that there are blocks on pages I'm not allowed to see.

Why? Quite often when we update an add-on we uninstall it first because it's easier than writing a complex upgrade method for an add-on which is in use on two sites. However, when I uninstall an add-on which contains a block I'll mess up the existing site. Your add-on could be very handy in this situation but only if it would search stacks and global areas as well.

Is this worrying about rights to see blocks a misleading requirement?

I can't envisage any user less than admin or super admin needing access to this tool, in which case, just show them everything, no holds barred. Would make things simpler.

So, any use-cases for anyone less than admin or super-admin to need this?

I do have one project where an end-user might want to know where a certain block type exists, but that's a pretty rare thing and I wouldn't mind if he'd just call me..

So I agree, admin it is / supposed to be!

I've read grumblings where a user wants to see where every block is on their site before uninstalling it, if only to review where the block is actually displayed so they can replace it with something else. The list itself seems like a nice idea, though I would think that it should maybe just be handled by core and written to a log?

-Scott

I agree, something like that should be in the core but even with this add-on, I'd be happy. Better than nothing I think!

But since there's already a list of objects when you uninstall a package, a button next to each block showing the page instances where it's been placed, would be nicer...

Well, the SuperUser bypasses the permissions and out of the box, users in the "Administrators" group have near SuperUser access anyway so they will see everything.

As for use cases, I know we've built sites with several different user groups each with their own specific access to the dashboard pages, areas and blocks, however, I'll go out on a limb and say this isn't the standard for the average concrete5 site.

My whole reasoning for checking page/block permissions is to prevent the results from displaying a page to which the user cannot visit or go to a page with a block that have no view access to. They'll either get a login screen or they will load the page but will not be able to see the block from the search results; even more confusing.

I'm guessing the users that need this add-on to find all instances of their block before uninstalling it will have SuperUser or Administrator access anyway so it shouldn't be a problem.

Unless I'm mistaken, the PageList used for the Page Search dashboard page also checks permissions (which also inspired me to follow suit; in fact I just noticed I'm not checking unapproved pages which I'll add as well).

As mentioned before, the performance hit is being mitigated by the caching to keep things relatively snappy.

Given all of this, I am still not convinced it's better to just open up the flood gates and show everything regardless of the current user's role/permissions.

That said, I really do appreciate the discussion around this as I probably wouldn't have thought as hard about this as you are all making me :D

Just a quick follow up: I implemented the suggestions from this thread (minus the icon - still working on that) and the latest release can be downloaded from:
https://github.com/beebs93/c5-where_is_my_block/tags...

I think the previous posters helped me get this to a near finished state, but if anyone still feels inclined to provide feedback please feel free.

I'll probably be submitting to PRB within the next few weeks (once work dies down) so I'll post again once it makes it to the marketplace.

Thanks! :D

I have been using this actively for the last few days while updating my addons for 5.6, to find pages where I have used/tested blocks and re-visiting the tests. It has been incredibly useful.

One glitch, the link given when a block is found is relative to the web root and needs to be relative to the C5 site root. The usual reason for such a glitch is usually not using the C5 url helper to build the url.

Thanks for the bug report, John! I'll add it to the issues list. :D

Quick update:

I have resolved the major outstanding issues and have a stable release for c5 v5.5.2.1
https://github.com/beebs93/c5-where_is_my_block/downloads...

"Now with 100% more icon!"

I'll be fixing the remaining styling issues to make the form 5.6.x compatible and submitting to the c5 Marketplace.

Cheers!