Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2015-12-13 11:24:12

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Custom filters for lists in the admin area

Currently the output in the admin list panes is not modifiable with “pluggable_ui”, presumably because the row output and table header output are in different places and interdependent, and search fields etc.

It’s possible to filter the list by section / category, etc. to show a subset of articles, but would it be possible to provide a facility for a plugin to inject further conditions into the db-retrieve-query so that particular types of content can be excluded from the list output. All after-the-event methods (e.g. jQuery etc.) result in incorrect page counts and strange page lengths.

This would make it possible, for example, to prevent some content being listed in the Content > Articles pane so that they can be listed in a separately constructed admin pane, using smd_tabber for example. Three potential purposes spring to mind:

  1. Makes it possible to separate out certain data input / content types into other tabs so that they can be listed according to their specific requirements. Examples:
    • Event listings by date, place etc.
    • Glossary or FAQ entries
    • Anything with its own data structure, e.g. projects, books, films, paintings, photographs …
  2. De-clogs the normal article / image / list panes when stuffed full with large quantities of chunked content, e.g. …
    • Glossary or FAQ data that changes rarely once set but takes up lots of entries in the article pane
    • Image galleries that only appear in the context of a gallery and are not referenced as site content but quickly add several pages to the image tab
  3. Allow authors to edit only their own articles, plus certain common articles by defining a custom filter.

This should be linkable to the admin user’s privileges so that the superadmin can view them as normal if required.

smd_tabber, for example, could then conceivably be extended to include an optional admin-definable filter for the respective list page.


TXP Builders – finely-crafted code, design and txp

Offline

#2 2015-12-13 12:04:41

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Custom filters for lists in the admin area

Aren’t admin_crireria callbacks what you are looking for?

Offline

#3 2015-12-13 21:57:31

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,250
Website GitHub

Re: Custom filters for lists in the admin area

Number 3 on your list is already doable as etc says with criteria callbacks. See mrd_for_your_eyes_only as an example.

As for the other stuff, I’ve wanted to find a way to allow plugins to add columns to tables for years but can’t find any satisfactory way to do it. As you correctly surmise, the problem stems from the way the code is built up: header first, content second. So it’d currently need two callbacks that would have to be closely synchronised by the plugin hooking into them, to prevent the tables rendering badly.

Coupled with this, not having any proper chaining (yet) between plugins means that if two plugins were to hook into the same callbacks for rendering their own columns, fire would rain from the sky and scorch the earth. Or something.

Part of this drive is on my list, and some work has been done towards this already. Some of the functionality that was built into admin-side pages has been split into its own functions so it’s reusable by plugins. Previously, for example, smd_user_manager had a helluva time hooking into saves because there were no callbacks raised to say a save had succeeded (besides the save event itself), and at the end of the save, the user list was automatically redrawn by the same function that did the work. So the plugin had little choice but to completely hijack the entire page and reinvent (copy) tonnes of core code. Now, there’s an API (of sorts) where the UI handling stuff gathers the input field data, passes control to a separate function to do the database work, and then returns, at which point the UI is redrawn. And a callback is raised during the process. So the next plugin version can be a little simpler by only hooking into the save.success callback and saving the extra data to the custom tables. Still have to hijack the page to render the table though :-(

Although it’s still not true MVC, the ‘model’ stuff is gradually being farmed out to atomic functions. Phase two of this drive will probably be to do that in classes, and then migrate existing panels one by one to use a class-based architecture. And, if I have my way, use templates for each panel’s content into which dynamic data is injected. Though that would still require two callbacks, it makes it simpler to supply custom content to admin side screens because the ‘model’ callback can fetch the data and ‘view’ callback can replace the base template with your own to draw the table columns you want. Quite how this would fit in with multiple plugins calling things fries my brain though, so maybe it’s not doable that way.

In summary: would be great. In practice: we’re not there yet.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#4 2015-12-22 21:22:11

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: Custom filters for lists in the admin area

Gah, I overlooked this one too. Thanks for showing me the light, Oleg! I’d not noticed that.

Stef, I did see mrd_for_your_eyes_only. Thank you for pointing that out to me again. How might one go about 1 and 2, then?


TXP Builders – finely-crafted code, design and txp

Offline

Board footer

Powered by FluxBB