Nuwanda

Yes, that's it. Ivan originally asked: 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.

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.

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.

Why not just put all profile fields in the user page?

Hmm. Wordpress uses a script/styles wp_enqueue_scripts hook and a wp_enqueue_script/style function that is quite intelligent. It allows you to enqueue a script and any dependencies. WP then makes sure the dependency is loaded before the script that depends on it. Even if the dependency is not itself queued to be loaded on that page, the dependency argument will force it to be loaded. https://codex.wordpress.org/Function_Reference/wp_enqueue_script For instance, if your script depended on jquery but jquery was not loaded by default (or you wanted to ensure it was), doing this... function my_scripts_loader(){ wp_enqueue_script('my_script_handle', 'my_script_url', array( 'jquery' )); } add_action( 'wp_enqueue_scripts', 'my_scripts_loader' ); ...would load the script previously enqueued with the handle jquery. And then if your script was itself needed for another dependent script, you could: function next_script_loader(){ wp_enqueue_script('next_script_handle', 'next_script_url', array( 'my_script_handle' )); } add_action( 'wp_enqueue_scripts', 'next_script_loader' ); So the script load order would be: jquery my_script_handle next_script_handle Scripts/styles enqueued this way are spat out in the wp_head or wp_footer template function. There's an in_footer argument for putting a script in the footer. Probably wouldn't be hard to use that system in PW core, or roll your own. It's all about queueing the enqueued scripts and loading any given dependencies in the right order.

Hi, Ryan, Soma Just tried out Soma's original code with PW 2.5.1 and the old call to... wire("fuel")->set("helper", $this); ...failed: call to non-object. It worked with the updated code. So the old call is not backwards compatible any longer?

My first post here, coming from mainly Wordpress. The holy grail for me is exactly the description below: That's really it, isn't it? For years I've been stuck between the lightweight PHP framework (like Codeigniter) versus full-on CMS (like Wordpress) thing. The former requires a lot of monotonous coding to get an api + admin set up, and the the latter gets you bogged down in superfluous features.