Jump to content

Backend development tutorial


Ivan Gretsky
 Share

Recommended Posts

In tutorials section of the site we are encouraged to request tutorials. This topic is such a request.

ProcessWire is advertised to be great in not only building unique frontend features, but also custom backends. I would be very much interested in tutorial on building a custom backend for a site. I put some questions that could be covered in such a tutorial in a list below:

  • How to create custom backend pages
  • How to change the default starting page for admin users
  • How to serve different backends to different users depending on roles
  • How to style the page tree (I have seen it styled in some Soma's video tutorials, so it is a request for a best practice or an advice)
  • Anything else you think appropriate here)))

If someone could generously provide a screencast of a custom backend workflow it would be great tutorial in itself.

  • Like 7
Link to comment
Share on other sites

I agree on the need for such tutorials. Meanwhile, have search of the forums (using Google, of course); all your requests have been previously addressed in some way. These will give you an idea on how to approach the issues....But I agree, tutorials will explain them better and will be more visible than searching the forums for hidden gems :-)

Edited by kongondo
  • Like 3
Link to comment
Share on other sites

My thought on this is that a tutorial only can be build if you're in a process to build a theme yourself and 'record' every step you've done. (or you need a lot of experience building themes )

The development process will be a bit slower, but on the end you've the admin theme and a tutorial.

  • Like 1
Link to comment
Share on other sites

I am sure that it is not a simple task to produce a tutorial like that. Maybe the screencast of a backend system of a complex site would be an easier starting point. Sometimes it is nice to actually see something done (not just know it can be) and then do it yourself.

  • Like 2
Link to comment
Share on other sites

ProcessHello is a nice barebone starting point to just get a page to show stuff, but there's much more to custom admin pages, like using the existing fieldstylings of the admin-theme, creating tabs like in the page-edit view, so that your page also fits visually into the backend. Maybe you need a custom database to store information, too. 

  • Like 1
Link to comment
Share on other sites

hi ivan,

very good request!

Sometimes it is nice to actually see something done (not just know it can be) and then do it yourself.

what about a showcase thread or sub-forum for backend modifications? i would also be interested in soma's video you were talking about. do you have a link for that please?

  • Like 2
Link to comment
Share on other sites

  • 1 year later...

As a newbie suffering from information overload, as I am sure others are as well, I hereby bring forth this topic from the deep dark archives for further discussion. :)
 

...a custom backend workflow it would be great tutorial in itself.

 
 

+1 for this.
This would be super useful, as I tend to implement theme-related options for my frontend stuff, which would be nice in a seperate admin page.

 
 

...how to create custom pages (process modules) and to cater a advanced backend for clients.

 
 

+1 For backend tutorial
Really interested.

 
 

...But I agree, tutorials will explain them better and will be more visible than searching the forums for hidden gems :-)

PW is great for creating and managing the various aspects of a site. Most, if not all of my projects require a customized admin interface. By customized, I do not mean special css or js only files. It is more the end-user-centric workflow that is often required when satisfying client requirements. To me, this means that I limit the existing admin interface to that of a qualified user, whereas the everyday workflow needs to be presented in a manner consistent with current client procedures.  My confusion stems from having so many options that I don't yet know about -- I discover something new everyday. There is a wealth of information, suggestions, examples, etc., that the more experienced users have graciously provided ( and I want to thank them for their time and contribution ). These numerous references have lead me to re-factor multiple times, at a cost of time and productivity, in order to obtain the most efficient means of implementation; As ProcessWire's design itself has done.

Some of my projects are web-based applications only, which are integrated with a client's existing site. It would be nice to see how to tailor an administrative interface to fit any existing corporate identity standards. I would also like to see the 'custom' aspect of such a tutorial address the proper way to implement an advanced back-end. I realize that PW allows us to do whatever we want by staying out of our way, and that was the primary 'selling-point' when I elected to use PW for development. But from this simplicity comes a confusion, or complexity, when attempting to design and implement an advanced back-end, eg., what tools are available for a specific task? For example, if you don't know that you should use a repeater in these circumstances, or a pagearray for that, or..., you are left falling back on what you know, which causes you to re-invent a wheel that PW currently has in place.

I understand that it would be impossible to generate a sort-of overall task-analysis:procedural site map since we would be talking permutations. So why don't we use a common client scenario, and build upon it?

 

Link to comment
Share on other sites

It's funny to see you quote my request for such an tutorial and now I'm very much feeling able to answer your questions here. Currently the best resource for handling all those mentioned things is really ProcessWire itself.

If you want to know how to handle a custom CI Design in the backend - take a look at AdminThemeReno - it was born out of a custom backend interface and then ported over to pw. Maybe the new custom colorschema feature of Reno does fit your needs, but otherwise just clone one of those admin themes to site/modules/ and tinker away. 

About custom interfaces: All the Process* modules represent (full) interface-pages in the backend, and lot of the 3rd party modules are injecting things into those pages. Just take a look at those an see how they handle things. Maybe the most interesting Process module is ProcessPageEdit, as it is maybe the most used one. For module that inject things I'd say BatchChildEditor is a quite sophisticated one. After a little playing around with those files and creating own ones, you'll see that even the backend consists of only a few concepts: the Process/Module Interfaces, the Form api, the Inputfield / Fieldtype interfaces and Wire / WireArray classes. The other core classes should only be from interest if you really need them. 

  • Like 7
Link to comment
Share on other sites

I suspect there are two types of backend development perspectives: modifying the appearance and functionality of the PW interface itself (aka admin themes), or creating highly-customised listing/editing/configuration pages.

I've always regarded the existing PW backend as the place for superusers/developers only. A separate backend should be developed for users/editors/authors who wish to edit their own content and adjust basic settings related to how they interact with the frontend. This as opposed to something like Wordpress where the backend is usually quite suitable for all types of users from mere subscribers all the way up to admins.

I mean, let's say you use PW to build a site where users can edit their own content. It seems much cleaner to provide a custom edit area, themed identically to the frontend, than to drop users into the PW backend even though you've hidden all the stuff the user doesn't have permissions for. That being the case, backend devlopment is nothing more than an extension of frontend development with robust auth/permission checks.

I'd like to see tutorials on the pitfalls and best practices of that type of narrow, highly-customised admin area.

Further, I concede there's a crossover between user-centric admin areas and a fully-exposed backend. I may be at cross purposes with the OP.

  • Like 3
Link to comment
Share on other sites

I have been messing with some frontend editing for a while and do not think making custom backend for editors is worth the effort in most cases. The interface will most likely be inferior to the one present in admin. Especially with addons like ListerPro. I do think that "modifying the appearance and functionality of the PW interface" is the more easy, cheap  and capable way to go. I can see lately there is a lot of useful modifications to PW, like abilities to rename and hide tabs, add new pages from menu, new permissions and so on, making this path easier. Dynamic Roles module is really usefull here (too bad it is not even in modules directory yet). Pro Drafts is on its way.

I think maybe creating a custom admin theme with stripped out functionality could be an option. Though I do not know abouit it as I have not tried it. Tom Reno is the man to ask about it)

But of course you can do a totally custom backend as complicated as you wish, but I would not do it for anything but submitting an article type of workflow.

Link to comment
Share on other sites

I'm not sure where you see that WP is so much different than PW from the user perspective, except maybe the initial Dashboard. It's neither themed like the frontend nor can it provide more or less than what's possible in pw and people seem to love it. The posts / site listings can be mimiced by listers, the plugin and settings area shouldn't be visible to less-permissioned users anyway (our fields/templates). The Design area is simply a page somewhere in the pagetree (there are various ways to get this special page in the navigation). I'm not sure about comments, as I don't use them, but I doubt them being handled overly different. Users are already shown in a lister. There's a page to edit the own profile. 

Additionally you can really limit your users down to the bare minimum they need to see. Hide pages, they don't need to edit, or even hide the whole pagetree and let them only use listers. There's a lot you can do there. And if some feature is really not present (dashboard) you can still look in the modules directory or code an own process module to resemble your needs. By now I did lot's those custom process modules and it's really not that hard to integrate own layouts / views into the backend with the cohesive styling it's providing. 

If you find that users cannot grasp what their changes in the backend do in the frontend there are various examples where people integrated the fredi module or links to the backend. So people can decide in the frontend what they want to edit and from there go directly to edit it in the backend interface.

When talking about "casual" users, who can edit their own content, but shouldn't know about a backend – that's 100% frontend – at least in my opinion. It's part of the service you offer the user. This can look like a "backend" but you're really better of not trying to integrate that in any way with the real pw backend. Just code it like any other frontend-part and use the api. Think about when the code of the backend would change a bit. Suddenly your users cannot edit their content anymore. That's not what you want. 

  • Like 2
Link to comment
Share on other sites

When talking about "casual" users, who can edit their own content, but shouldn't know about a backend – that's 100% frontend – at least in my opinion. It's part of the service you offer the user. This can look like a "backend" but you're really better of not trying to integrate that in any way with the real pw backend. Just code it like any other frontend-part and use the api.

Yes, this specifically what I'm talking about and it depends on use-case. If you're developing, say, a site that allows users to list items for sale, it seems to me that it makes the most sense to create a custom admin section for the user as part of the frontend. That way it's easier to mimic styling and it's a lot easier, it seems, to use the api to create all that's necessary for that type of user to edit and maintain individual settings without dropping them into the PW backend.

I wasn't clear with my Wordpress remarks so I'll go at it from another angle: the development of the WP REST API has excited developers for many reasons, among them being the ability to code custom backends for users that don't require interaction with the standard WP dashboard especially for reasons of styling consistency and unecessary complexity. Much easier to do a custom admin using the new api.

Of course PW already has a great api and I'd suggest that any site that is allowing users to create accounts and user-specific content (such as ads, personals, subscriptions, products, forum posts, etc.) a custom backend with identical styling to the frontend is the way to go. The admins and developers can use the PW backend for site management.

  • Like 2
Link to comment
Share on other sites

I hadn't thought about this two points of view around admin. I have seen some apps made in processwire around the forum, like for example this preview of an intranet, is this the same kind of "front end edit" you are talking about LostKobrakai?

Just in case it's that, I would also be pretty excited to learn how to do that  :rolleyes:

Yes, that's it.

Ivan originally asked:

I would be very much interested in tutorial on building a custom backend for a site.

I may have missed the point of that original question but I was really trying to make the distinction between what regular site users (members, subscribers, shoppers, etc.) need in terms of account and content administration, and what superusers like admins, owners and developers need. The former certainly don't want to be dropped into a PW backend that looks and feels way different than the site itself.

Link to comment
Share on other sites

I hadn't thought about this two points of view around admin. I have seen some apps made in processwire around the forum, like for example this preview of an intranet, is this the same kind of "front end edit" you are talking about LostKobrakai?

Just in case it's that, I would also be pretty excited to learn how to do that  :rolleyes:

the mentioned office application is nothing else than a custom frontend - PW original backend is only used for storing the data....so no limts on this side. ;)

for the PW backend there are much options on this so you could go:

1. using Lister Pro for creating dashboard like pages in the admin for special selectors you preselect or let the user select...

2. using AdminCustomPages module to simply have the option to work with a "normal" page template in the backend and don't have to code a Process module

3. other options that work but i don't know now....since i've learned that in PW there is always a another way... ;)

take a look at existing modules if you wanna learn something about the backend - you could take a look at:

- Soma's imagemanager

- Code examples from LostKobraKai about using datatable module on own admin pages

- renobird's example of a simple process module for admin pages

search the forum

regards mr-fan

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...