Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

2,371 profile views

Vigilante's Achievements

Full Member

Full Member (4/6)



  1. I've been trying Settings Factory and I simply used the kitchen sink file for testing. For some reason these errors come up on nearly every page load of the admin, not even editing my custom settings page, they just show up every time the page refreshes: I have valid URLs and Emails but these keep popping up all the time.
  2. You're right, just wrong syntax, though I could swear I tried that. I was using the method style on a bunch of other stuff, must have got mixed up. Thanks. Sometimes it's the little things.
  3. This one is nice, but also per-page scoped, so not really global. Also at one point of the lifecycle do you actually set those variables? Are they persistent? I assume we're not setting the all variables in the same template they are used, on every page load, so is there some other administrative area where you can set the data once to use? This is also nice, but not in the current release yet? I don't have these available in my version. Also, it seems to focus on template-specific fields, rather than globally available data. Although I assume maybe you can access this data of one page from another page. Even still that's a bit clunky, trying to remember which page has particular fields you need, etc. It's possible this client I'm working on, has Pro Fields. I'll double-check. But this is also per-template data. I guess that's just how PW works, haha. I would be nice to really have a completely separated, almost non-page area somewhere in admin, just to define site-wide data from the user admin. Like a custom admin page of arbitrary fields. That might be a winner.
  4. I have a page which is a subpage. So members/favorites for example. In the favorites template I have some code for ajax responses. In other words `if ($config->ajax()) { ... }` which runs just fine. I need to know the template of the page ID passed in because this same ajax is used from other templates, so slightly different code depending on which template we're on. A page ID is sent over ajax, just the id, so I grab the page with `$item = $pages->get($pid);` where $pid is from the $input. All this works fine. I get the page object back. When I var_dump the object, I can see it has the template in there, i.e. "[template]=>'product'" because the ID belongs to a product the user has added to favorites. Anyway, the problem is, I have this ID, I can get the Processwire page object, it has the template name listed in the var_dump, I can see it there, but when I try to access `$item->template()` I get this error. "Fatal error: Exception: Method Page::template does not exist or is not callable in this context (in /home/....../wire/core/Wire.php line 519)" Why if I have a valid ID, and grab a valid $page object, can I not access $page->template() even when I can see the data is in the object?
  5. I have a site where guest users become "limited" users. The limited users can't see any content on the site, but their account is pending review. Then there is our "member" role which is the standard user role for accessing the site. After a user registers, we need a super user or somebody with "administer users" to be able to add the "member" role to these new users. The problem is that this gives a little too much ability. Say I have a role named "member-manager" and give them admin user ability. Well not only can they add or remove the member role, but most other roles too. Thankfully, not super user, but for example they could make other users also be member-managers and this isn't right. We only want the member-manager roles to be able to access the limit users and convert them to members, that's about it. No other roles should be available, and they shouldn't be able to add member-manager either. Is there a way, once I've given the admin user ability, to further limit which users they can see, and what roles they can add or subtract? For another example, we have other roles like "editor" and these member-managers don't need to be able to add or remove this role from anybody. How could I do this?
  6. I have a feeling I know the answer, but maybe there is a simpler way. Basically, in order to avoid saving any hardcoded info in a template file, I'd rather store this data in some kind of global data set or 'settings' and then pull the value into templates as needed. A simple example would be a company phone number, or an administrative email address. Rather than put these things hardcoded into the template that needs them, I'd rather call them up as some kind of global data as needed. And then of course this would make it easy to edit this data in the backend. My guess is that you would have me create a special "page" using a custom template with a whole bunch of fields for every kind of custom data I need. I guess this would be fine, but it would require creating lots of fields which I think would clutter the fields area up. The objective is just to have some place in the admin where a bunch of random things could be saved which may be used from any number of templates. And is easy to edit by the client.
  7. In general, is there an easy way to know which method should be used to access the API? For example, when _ini.php is used in the theme, it would seem you have to use wire()->addHookBefore(...). But on other sites where they used ready.php, I've seen it go straight to just doing $this->addHookAfter() even though there is no class or namespace set up in the ready.php file. So how do I know when I can do $this, or $wire, or wire() to access things? And any other variables I'm not aware of. Thanks!
  8. Yes, if I build the logic myself to parse a given URL string and figure out which part of the path goes to the segmented page. I just thought a function like this might have already existed. The logic would handle that. If "this/is/long/url" is a 404, then it looks for "this/is/long" and if that's a 404 then it looks for "this/is" and if it finds a page here, it would then check to see if segments are on. Then if so, it would return "this/is" as a page object. If segments are not on for that page (or accepted segment strings are defined and my string doesn't match them) then it would also return a 404 and give up. Obviously this kind of recursive checking would be more costly in processing so that's why a dedicated function or a switch would turn it on only when necessary.
  9. It's not that I'm doing "custom routing", it's that I want to return the correct page that handles a particular URL. If I have "/some/page/here" and I "look it up" with whatever function might exist, it should return "/some/page/" if that is the correct page that handles that particular URL (because segments are on). I'm not trying to do custom routing here, I'm trying to lookup the correct page that handles a given URL. I'm only talking about routing because the PW router obviously already uses/has this logic. It knows the correct page to open for a given URL. I'm simply looking for similar function in the API that works like get(). I pass in a path and it returns the page that handles it. For some reason I thought this would be a pretty common thing to want to do, unless very few people make use of segments?
  10. I don't think it's that broad or mysterious really. Let's say I have a path as a string that came from somewhere or is auto generated, etc. Something like "/this/should/be/a/page". Now I just need to check if that's a valid URL or not. If I simply throw it in get() it will return 404 because it won't find that exact hierarchy in the page tree. It would be a relatively simple thing for the code to knock off "page" and instead search for "/this/should/be/a/". And if that doesn't exist, look for "/this/should/be/" and then bingo. If "be" exists, PW checks to see if segments are turned on and if they are, check if segments are limited to certain strings. If not, then get() ultimately would return the "be" page. Of course, all this should be optional. So the default get() would return 404 as it does now. But if you had something like `get("/this/should/be/a/page/", array("look_for_segments"=>true));` then get() would search and return a segmented page if that exists. The bottom line is this, I'm looking for a page "this/should/be/a/page/" which is a totally valid URL ("be" has segments turned on). But instead PW tells me it's a 404 not found. That automatically says something isn't right here. I can't have PW telling me a URL is a 404, but if I actually GO to the URL, it works fine due to segments. The PW routing system already knows how to handle URLs with segments, I'm just thinking that functions such as get() need to make use of that logic as well. It doesn't even need to be get(), it could be an alternate function, perhaps gets() where the 's' stands for "segments" and it will return the page relating to a URL where segmented pages are searched for and not just precise page tree location.
  11. I have segments turned on for the root/home page. This is because I'm doing some custom routing to remove a path from the URL. One of the grandchild pages itself has segments turned on. So when I'm doing my custom routing from the home page, I look to see if the URL is valid by using a standard get lookup on the segment string. Something like `$pages->get("/myroute/".$input->urlSegmentStr()."/");` The problem is, the segment string may have a path that itself includes segments, like "/route/allows-segments/segment". So get() returns nothing, essentially going to 404, because it can't find that path which has a segment in it. Is there a way to make get() smart enough to see that even though /segment/ isn't found as a page, its parent /allows-segments/ has segments turned on and thus it can get that page instead? I already programmed my workaround, it's not that big of a deal. I had to specifically test for the segmented URL though. Luckily I only have one page like this, but I can see it being an issue if I had a lot of them. Perhaps get() needs some kind of options (or another finder function entirely) that can deal with paths with segments. Where it will process the path and check for segments, returning the proper page.
  12. Thanks. Looks like a lot of stuff there, I'll have to play with it and see if it does what I need. Will it work when using alternate admin themes?
  13. I haven't spent a ton of time on PW, just a handful of sites, but some things would make it easier to use. I bet there are plugins but I haven't spent a lot of time seeing what others use to solve this. 1) Easier access to the real name of a field. I often have a page open in the editor, a field label might say "Description" but really the actual code name could be anything, such as "Markdown" I see sometimes for md fields. Also field names seem to be case sensitive and I've worked on sites that seem to have random field names with caps or not. Is there a way to make it easier to read the code-based field name when I have a page open? The current method is cumbersome. From a page edit scree, switch to the Settings tab to grab a look at what template its using. Then open the template to see what the fieldname is. 2) Direct link to template from page. In similar vein, when I'm on a page in the Settings tab, it would be nice to have a direct link to open the template rather than look at it and then go find it in the UI. 3) Open a field directly from inside template edit screen. When I'm viewing a template and I see the list of all the fields, I want a direct link to open the edit screen of a particular field. --------- These three things are very common on client work because I don't always have every template and field name/label matched up and memorized. I'm constantly playing this dance of being in a page, then wanting to know the field name for code, so I have to go see what template it's using, then go look that up to see the fields, then look that up to see what field type it is, etc. For example, even bypassing having to open the template first would be good. If I could see a field and link directly to the field edit screen. If any of you have techniques to simplify this, I'm all ears, or plugins or whatever you use.
  14. Well, the 301 was wanted, But only for true guest users. These other users had multiple roles. I ended up adding the logic to test if they are logged in from the template itself. If this is a bug, it needs tested from a sandbox or fresh install. I don't know why it acted that way. I mainly wanted to confirm whether PW uses an additive or restrictive model for the permissions.
  15. I'm creating a recursive PHP function for showing a 3 level menu. parent - child - child - - gc - - gc - - - ggc - - gc - child parent - child - - etc This is all easy stuff with the recursive function but the problem is I want to use some logic that has to bubble up from the great grandchildren to the parents. If one of the menu items does not have any related pages, I don't want to show it. Like an empty category in a blog or something. Again this is easy to just test for during the loops. It gets tricky at the next part. If a parent or grandchild is empty, it will still have to show up if one of its children has a related item. So if any child has an item, its parent must show. And likewise, if some great grandchild has an item, it's parent and grandparent have to both show. A work in progress of the function looks something like this, I've removed some logic to clean it up like assembling the href and classes and so forth. This is the gist of it. function menu($p = null, $ignore = false) { echo '<ul>'; foreach ($p->children() as $c) { // $ignore contains a pageArray of items that can be ignored, already determined that these are empty // it's just that I don't want to ignore it if a child or grandchild DOES have items if (is_object($ignore) && !$ignore->has("id={$c->id}")) { continue; } echo '<li><a href="HREF" class="CLASSES">' . $p->title . '</a>'; // Recursive call here if ($c->hasChildren()) { menu($c, $ignore); } echo "</li>"; } echo '</ul>'; return; }
  • Create New...