Jump to content

Nuwanda

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

9 Neutral

About Nuwanda

  • Rank
    Newbie

Recent Profile Visitors

982 profile views
  1. 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.
  2. 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 A
  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
  4. Why not just put all profile fields in the user page?
  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. 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... functio
  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?
  7. 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.
×
×
  • Create New...