Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
[request] "Docs" panel
I would love a plugin that added a top-level “Docs” panel (a tab next to last to “View site”), that followed the model of the Write panel but the only controls in the Docs panel are:
- A single big editing box (like the ‘body’ textarea alone; no title or excerpt).
- The ‘Edit’ and ‘Preview’ state buttons (no HTML view button).
- Save
That’s it!
The content simply saves in the panel—a single screen (no pagination)—it’s doesn’t go to the front-side.
The plugin has only one preference, which is to set at which role (and up) users can see the panel in ‘write’ mode. Everyone below sees it in ‘read’ mode and without the “Edit” and “Save” button in view. By default the ‘write’ access is set for admin/publisher roles only.
(Maybe there’s a second preference for selecting Textile or Markdown, depending on how Text filters are handled in future releases of core.)
This would be great for at least three different scenarios that involve my work:
- Personal: Leaving notes to myself in my own site.
- Clients: Providing documentation in context of the CMS instead of a Google document, PDF or whatever.
- Collaboration: Useful to keep editorial instructions for multi-authoring workflow.
In fact, I seem to recall there was something like this once, but what I’d like is specifically as described above. No frills and extras.
Possible?
Offline
Re: [request] "Docs" panel
Hey Destry, I can’t find a link to it, but asy_dashboard was one, adi_notes is another which should fill your task.
I think there was another too…. from eric, but I can’t remember
Last edited by tye (2012-11-11 22:21:27)
Offline
Re: [request] "Docs" panel
Ah, yes, adi_notes was the one I was recalling. But it’s more than I want. I don’t need note inserts in every panel (nor want the extra noise in the UI… no offene to the plugin), nor a link hidden away in Extensions. I’d just like one front-and-center “Docs” menu link with a single editing box on the panel that renders a text filter.
Now that I think about it… was there a dev rule about not allowing plugin menu items outside of Extensions? That would suck for me. ;)
Offline
Re: [request] "Docs" panel
jmd_dashboard & upm_insert_tab
I don’t know if either still work
Offline
#5 2012-11-12 00:36:50
- gomedia
- Plugin Author
- Registered: 2008-06-01
- Posts: 1,373
Re: [request] "Docs" panel
Destry wrote:
Ah, yes, adi_notes was the one I was recalling. But it’s more than I want. I don’t need note inserts in every panel (nor want the extra noise in the UI… no offene to the plugin), nor a link hidden away in Extensions. I’d just like one front-and-center “Docs” menu link with a single editing box on the panel that renders a text filter.
adi_notes can do a Notes tab under the “Home” tab (as well as in Content/Presentation/Admin) if that would suit.
Offline
Re: [request] "Docs" panel
Yep, all of the above are good suggestions. Alternatively, roll your own tab using smd_tabber. You can put what you like on it then and save the content to the prefs table, for example.
Last edited by Bloke (2012-11-12 08:55:03)
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
Re: [request] "Docs" panel
Destry wrote:
Now that I think about it… was there a dev rule about not allowing plugin menu items outside of Extensions?
The API doesn’t offer a way to create new top-level menu items (panels). Tho, you can add panels to any existing menu area, but any added panel goes to the bottom of the list.
In other terms, the menu item can either be added under Home, Content, Presentation, Admin or Extensions, where it always will be the last item. Sorting, moving, duplicating or making the panel the menu’s default isn’t supported. Any added panel will be affected by the menu area’s top-level permission restrictions. These top-level restrictions can not be elevated.
Last edited by Gocom (2012-11-12 10:46:45)
Offline
Re: [request] "Docs" panel
Destry wrote:
Now that I think about it… was there a dev rule about not allowing plugin menu items outside of Extensions?
It didn’t used to be possible and, although it’s not advisable to litter the menu bar with top level items for usability reasons, it can be done since 4.30 or 4.4.0 (I forget which). That’s what smd_tabber uses to register top-level menus, although as Gocom says the API could be nicer so plugins don’t have to hard-code the admin areas (hmm, maybe in light of recent code improvements it is better, I haven’t checked that part recently: must revisit).
At the extreme end of the scale, combining smd_tabber with smd_user_manager you could create a new user level and give certain people access to only the designated tabs of your choice, which may well be custom tabs / menus. I’ve used that in the past to clamp down access so self-registered ‘customer’ accounts can only see exactly what I want them to see: no Write panel, no nothing except Admin->Users (to change their password/bio details) and a few custom prefs. Other account types get slightly higher permissions and can do pre-defined admin tasks but with a reduced, simpler workflow.
I prefer working this way than coding it all by hand on the public site — especially if the back-end and front-end themes are similar to offer a seamless experience — because you get logging in and a nice tab / menu structure to play with for free from the admin side. That’s the great thing about Textpattern: more than one way to do stuff.
Last edited by Bloke (2012-11-12 11:28:18)
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
Re: [request] "Docs" panel
Oh, right, you can use register_tab() to push new undefined keys to the array. Not exactly sure if that is a real feature or a oversight, especially considering that there is that empty ‘start’ value.
Bloke wrote:
nicer so plugins don’t have to hard-code the admin areas
If you are referring storing the menus in database, I do disagree. In my opinion the API shouldn’t be persistent and there should be no storage involved. For instance there is no reason to even store permissions in database, especially if you are just going cramp them in as some serialized blob as planned. At that point having them as an array in a PHP file is the exactly the same thing.
Many of the common practices we do are not features, but hacks due to the API being limited and lacking. For instance I do consider that Textpattern does not offer a way to register temporary language strings on runtime and there is no way to remove preference even. Anything that composes of altering global variables is not a feature. Heck we can’t even parse our own propriety distribution formats (e.g. textpacks, plugins).
Last edited by Gocom (2012-11-12 12:28:03)
Offline
Re: [request] "Docs" panel
Gocom wrote:
Not exactly sure if that is a real feature or a oversight
The former. No doubt it could be done better with a $areas global.
If you are referring storing the menus in database, I do disagree.
Not at all. Why would we do that?
there is no reason to even store permissions in database
OT: I agree it’s the API that’s at fault, not the storage mechanism. The fact that things like smd_user_manager and bot_privs et al have to jump through a tonne of what I consider hacky hoops (and, at the time, I had to duplicate many hunks of the admin->users panel code) just to allow people to create new user group / priv areas is a deficiency. If the permissions/user management could be abstracted or made into reusable functions like you did with image_data() then I’m happy. One could argue such a feature is not necessary because the core has 6 built in levels already and fixed permissions for those levels. But then one could argue that 10 built-in 255-char custom fields is enough :-)
no way to remove preference even
I thought this was planned for 4.6? Don’t think remove_pref() is hard to achieve.
Anything that composes of altering global variables is not a feature.
Sure. Then we should make it unnecessary.
Last edited by Bloke (2012-11-12 12:46:30)
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
Offline
Re: [request] "Docs" panel
Gocom wrote:
Don’t see it in the issue tracker, tho.
/me slacker.
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