Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by Nuwanda

  1. 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.

  2. 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
  3. 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
  4. Why not just put all profile fields in the user page?

    I have a social network made in PW with +40k users registered, my solution was to create a template for the profile, having some important fields directly to the user template like gender, city (fields I can use for a search so it's good they stay inside user template) and additional info into the profile, linked to the user with a page field. 

  5. 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.


    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:




    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.

    • Like 2
  6. 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?

    Great tutorial Soma! Thanks for making it.

    One thing I wanted to mention is that this syntax:

    wire("fuel")->set("helper", $this);

    has been replaced by this syntax:

    wire('helper', $this); 
    // or this: 
    $this->wire('helper', $this); 

    But of course your tutorial is correct in using 'fuel' since it would be compatible with past versions of ProcessWire too. Just wanted to mention it since I think the API is simpler if all getting or setting of API variables is just done through the wire() or $this->wire() functions. But the old syntax will always continue to work as 'fuel' is itself an API variable, but one that I figured makes more sense as an internal-only API variable.

  7. My first post here, coming from mainly Wordpress. The holy grail for me is exactly the description below:

     As Ryan describes it: Processwire is a CMF or a framework for mostly CRUD Operations in PHP shipped with an adminbackend for a Content Management System (/processwire).

    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.

    • Like 2
  • Create New...