WBCE CMS Forum

rinse

Developer

A dashboard module for WBCE — looking for feedback before I build it

A dashboard module for WBCE - looking for feedback before I build it properly

I have a working draft of an admin tool I would like to develop further, and I would rather hear what you think now than after I have painted myself into a corner.

What it is

An Admin-Tools screen that shows the state of an installation: what is broken, what is untidy, and a few numbers about the site. It contains no checks of its own - it is a framework. The checks are widgets, and a widget is simply a folder with one file widget.php (samples provided)

No info.php, no installer, no row in the addons table. Drop the folder in and it runs; remove it and it is gone. Anyone can write one.

The one idea that makes it a framework

Widgets do not write their own loops. They subscribe to one, and the framework walks each collection once and hands every item to every subscriber.

class WD_W_page_meta extends WD_BaseWidget implements WD_OnPage
{
    public function group() { return 'Pages and content'; }
    public function title() { return 'Pages without a description'; }
    public function loops() { return array(WD_Widget::LOOP_PAGES); }

    public function onPage($page, $ctx)
    {
        $ctx->ok();
        if (trim($page['description']) === '') { $this->missing[] = $page; }
    }

    public function after($ctx)
    {
        if ($this->missing) {
            $ctx->warning(
                count($this->missing) . ' pages have no meta description',
                'Search engines then compose their own snippet from the page text.',
                $this->firstFew(), 'pages:description'
            );
        }
    }
}

Ten widgets that all need every page cause one pass over the pages, not ten. There are five loops so far: addons, pages, sections, settings, media. A widget can also use no loop at all.

Everything a widget may read goes through $ctx->site - one shared, cached read model, which also keeps the 1.6 (mysqli) / 1.7 (PDO) difference in a single place instead of in every widget.

What it deliberately does not do

- The checks never change anything. A widget reads and reports; there is no path from widget code to a write. No "repair" buttons. A tool that both diagnoses and fixes has to be trusted twice.

- No health score. The top of the screen shows counts - 5 errors, 4 warnings, 51 checked - because a count can be clicked and a score of 83 cannot be explained to anyone.

- One finding per cause, not per instance. Twenty deleted language files are one line, not twenty. (That mistake was in my first version and it pushed the one real problem off the screen.)

- Every finding carries its evidence: file and line, table row, the query that fails. A finding without evidence is an opinion.

Findings you do not want to see can be hidden; what is hidden is stated at the top with a "show again" button beside it. The framework keeps one small table for that - its own preferences and nothing else.

What is in the draft

Four example widgets, three of them on different loops and one that checks the other widgets: unknown loop names, handlers nobody calls, and code that breaks the read-only promise. If we invite people to write widgets, the first thing they need is something that tells them what is wrong with theirs.

Tested against WBCE 1.6.8 and 1.7.0 with the same database: identical output.

Where I would like your opinion

1. Are these the right loops? What would you want to walk that is missing - users and groups, templates, droplets, the search table?

2. Folders or real modules? A widget as a full WBCE module would gain the addon installer, but also an info.php, a version in two places and a function column per widget. I chose folders. Convince me either way.

3. Preferences: own table or the settings table? I made a small table of my own so uninstalling leaves nothing behind.

4. Which checks do you actually want? This is the part where the community beats me every time. What have you spent an evening looking for that a dashboard could have told you in a second?

5. Where should it live? It is an Admin-Tools entry, because the top-level menu is hard-coded in the core. Is that good enough, or is this something that belongs on the start page?

Last edited by rinse (20.08.2026 21:30:31)

florian

Administrator

Re: A dashboard module for WBCE — looking for feedback before I build it

I had a quick glance at it. The module itself looks promising. I guess you had a Wordpress-like function in mind, and generally spoken it's a good idea to use the WBCE dashbord for more / current / useful information than now.

Thus said, and as you have noticed too, the current dashboard is hard-coded and there's no way to change its contents without larger rework of core functions and templates. So I would suggest to keep this in mind for an upcoming version of WBCE, fttb the simplest way of integration is indeed keeping it as an admin tool.

Useful information - just my 2 cents

- list of last updated pages
- list of last active users
- latest form entries (miniform, mpform)
- failed logins (not sure if we even store this information somewhere)
- error log size
- available updates for installed modules
- Forum RSS feed (announcements / security warnings)

Information storage - I would prefer the tool to use its own table, the settings table is already quite large and confusing.

Regarding the widget installation method, I think we should stick to methods which are used for other expandable modules too, see droplets / output filter dashboard, e.g. import from zip. No FTP'ing on the server.
Nevertheless there's afaics no way to avoid that a widget contains malicious code, so there's a security flaw if some bad guy creates a widget.php which is actually a backdoor or erases the whole database.

Last edited by florian (20.08.2026 20:16:05)

---

Wir Benötigen: Cents, Euros... jetzt spenden!

rinse

Developer

Re: A dashboard module for WBCE — looking for feedback before I build it

Updated the attachement on the opening post:

- layout now in default styling
- installation widgets now by editor form (like droplets)