Chrome extensions, Manifest v3 and local storage views

The other day I started coding a Chrome extension that makes heavy use of Chrome’s IndexedDB. Until this time then I had no problem inpecting any local storage using the DevTool’s “Application” tab. Those were extensions that used Manifest v2 but as of June 2023 Google will only acept Manifest v3 extensions.
One of the main changes is that background pages are replaced with service workers. So I changed my code accordingly from:

"background": {
    "page": "background/background.html"


"background": {
	"service_worker": "background.js",

and coded happily on. When I reached the local storage part and wanted to check the local storage by clicking on the new “service worker” link:

Surprisingly the IndexedDB pane in the “Application” tab was empty though I definitely knew that there was data stored:

So what was happening? After a long search on the Internets I came across an answer on StackOverflow that saved my day.

If your extension contains a popup you can right click and select “Inspect” to open the correct DevTools window:

And there you go:

But what do you do if your extension does not containa popup? There is a solution though it’s a bit more complicated.
Open the extension page and look for the extension’s ID:

Copy that ID and enter the following URL into the address bar, replacing “ID” with the actual ID:


Right click on the window and select “Inspect”:

One last problem: In contrast to the standard DevTools popup this one disappears if you reload the extension. Fortunately you can bookmark the tab:

Update: You don’t actullay need to insert the ID manually but you can click on any script in your default Devtools window (opened with “Inspect views service worker” link), right click on any script in the “Sources” pane, select “Open in new tab” and, just like above, right click the tab and select “Inspect”:

The only question that remains is: Why, Google, why has this be so complicated?

Supperfood – Not so tasty after all

This month’s surprise box from Degustabox contained two bottles of “Superfood” by the Austrian company Friya. With basil seeds. OK, nowadays basil seems to be a superfood, too.
The stuff isn’t too tasty after all. The basil seeds are covered with a slimy substance. The whole thing looks like frog spawn.


The drink is quite alright but the frog spawn (the basil seeds) is quite disgusting. I really don’t need to have it a second time. I have another bottle containing Chia seeds but I’m not sure about it…

WordPress: add_filter or add_action? It actually doesn’t matter!

It’s a doctrine of WordPress plugin development:

Use actions to expand the functionality and filters to change information.

We’ve all heard it, we always follow that demand. Always? Well…

… if I want to add some functionality and nowhere near or far there is an action hook in the core but only a filter hook, I use that hook without considering the doctrine.

Surprisingly it works. But why? If we all insist that you have to use the right hook type, there has to be a difference between them. Let’s take a look behind the scenes (/wp-includes/plugin.php):

function add_action($tag, $function_to_add, $priority = 10, $accepted_args = 1) {
   return add_filter($tag, $function_to_add, $priority, $accepted_args);

What? add_action does nothing but call add_filter and nothing else? There is no difference in functionality, it’s only a different name. So there is no reason why you shouldn’t use add_filter instead of add_action if you have no other solution.

I don’t say that you should interchange filter and action hooks at will. Using the correct hook type makes your code more readable and maintainable, for yourself and for others. Nevertheless, if there’s not other way to accomplish your goal but to use a filter hook instead of an action, don’t hesitate, it virtually makes no difference.

Firefox Add-On version hack: Cutomize titlebar

If I want to tweet a link of a site currently opened in my Firefox/Waterfox browser I using the “Hootlet” from “Hootsuite“. This little Add-On simply takes the text  of the titlebar of the browser and adds an link so I can tweet it with a single click.

Unfortunately Firefox adds “Firefox” to the titlebar which I have to delete manually every time. But hey, computers are for automationing things so this should be automated, too. The Add-On repository contains an Add-Ons called “Customize Titlebar” which would do exact the requested task but it hasn’t been updated 2009 and is compatible with Firefox 3.9 (!).

In many cases those Add-Ons still work with current versions of Firefox the only problem is that they are marked incompatible. It’s always worth a try to simply increase the entry and check if it still works. Especially Add-Ons that are not critical like “Customize titlebar“. In this case this little hack actually works and I’m happy to be able to use the plugin.

I set the compatibility information of the Add-On to “50.*” so it should work for some while.


WordPress: New Version 0.5 of LinkList plugin

For a long time there was no update of my Linklist plugin because it simply worked, no need for a change. The other day I got a request to expand the functionality and I agreed to the proposal.

Version 0.5 now contains the option to include/exclude individual posts or pages from displaying the linklist:


The plugin still assumes that you want to add the linklist ater each post or page because that’s why you installed the plugin after all. Nevertheless you can disable the list by de-selecting the provided checkbox.

If you want to change the display for an existing post/page you not need to go to the posts edit page but can easily do it using the Quick edit feature:


I decided to use a drop down menu instead of a check box because WordPress renders the edit screen in a wilful manner and it can’t be manipulated (Can it? Drop me a mail!).

To change the display of the linklist for a large amount of posts/pages you do not need to edit every single post/page individually but can use the Bulk Edit feature:


(If you don’t know how to use Quick or Bulk Edit you can learn it on

You can update your installation by using WordPress’ own update feature or by downloading it from the repository.

WordPress – You’ve got updates!

On March, 11th an update of the popular plugin “WordPress SEO” was published because the previous version contains serious security vulnerabilities (CSRF and blind SQL injection).
During the day some people noted that Yoast didn’t use all possible channels to call attention to the situation.

I personally couldn’t understand the problem because I already had installed the new version before noon. How could this be? Continue reading WordPress – You’ve got updates!

New version of Linklist (v0.4) WordPress plugin

A user of my WordPress plugin Linklist wanted to use it in conjunction with a Like/Unlike plugin.

Unfortunately Linklist also listed the like/unlike links of the plugin and put the list behind the Like icon:


This is not the way it’s supposed to be. So I added two more options:

  1. You can define several class names of DIVs that will be excluded from being searched by Linklist. This option will also deal with incomplete DIVs (<div> without any closing div).
  2. You can set the priority of the plugin. This will enable Linklist to collect the links and add the list in the post before other plugins are adding their own content to the post.

In the above example the result will look like this:


… and yes, Linklist is compatible with WordPress 3.8.

Minor update to pagebar plugin (v2.65)

The last update to the pagebar plugin has been made over a year ago. Since all new ideas will be included in version 3 and the plugin was working fine with every new update of WordPress there was no need for an update.

The other day Borisa Djuraskovic of “Webhosting Hub” wrote me an email that he has created a Serbian language file. This was a good opportunity to introduce a small feature that was spinning in my head for some time:
Continue reading Minor update to pagebar plugin (v2.65)