Jump to content

alkahest

Members
  • Posts

    36
  • Joined

  • Last visited

Everything posted by alkahest

  1. Thanks Ryan! Ultimately I concluded the same: that I need to set $config->urls->root to /admin/ in any template that makes calls like these. That worked.
  2. Ahhh, that does the trick! When I do $brand->meta_image->first->url, I get the filename as well. However it still outputs /5gum/ as the root: /5gum/site/assets/files/1033/slim_cobalt.png I know my setup is strange, basically there is a brand under each directory in the top-level domain: /5gum/ /some-other-brand/ /another-brand/ And they all share the same assets (images, markup, etc) from the /assets/ folder. By visiting /5gum/, the system pulls in all the includes it needs from /assets/includes/ like the footer.php and header.php and other files. However all PW is managing in this case is order information, so that's why it's bootstrapped in and cordoned off in its own folder under /admin/. I'm not using any template file output from PW, I just talk to PW via Ajax to send/retrieve order information (and some basic information about the products). What I suspect is that somehow PW thinks /5gum/ is the root of the site. In fact, when I ask for: $config->paths->root PW says the root is /5gum/ as opposed to /admin/. Is there a way to tell PW what the root of the site is? (And yes, if you go to mysite.com/5gum/ you hit index.php, which calls in header.php, which is where PW is bootstrapped.)
  3. I'm having a weird situation where I'm trying to get the URL for an image attached to a page, but I'm getting back the wrong paths. The URL is mysite.com/5gum/. My file structure is like this: /admin/ <-- ProcessWire is in here -- /site/ -- /wire/ /5gum/ <-- my site templates are in here -- index.php (calls header.php below) /assets/ -- /includes/ ---- header.php I'm bootstrapping PW into header.php of a file under /5gum/. I'm trying to do something like this: $brand_slug = basename ($_SERVER['REQUEST_URI']); // this would get me "5gum" $brand = wire('pages')->get("name=".$brand_slug); // this gives me a specific page echo $brand->meta_image->url; // this should output the path to an image attached to the page If meta_image is a field that accepts a maximum of 1 image, shouldn't this return the full URL to the image? Instead, it returns: /5gum/site/assets/files/1027/ What doesn't make sense to me is that the root of the site isn't /5gum/, it should be /admin/ right, according to PW? Do I need to set the root somehow?
  4. I think I'm missing where they posted vectors - I definitely see the PNGs/GIFs tho!
  5. Does PW have an official icon? Like some 16x16 dealio?
  6. So, when I try: $state_set = $pages->find('template=state'); echo $state_set->getArray(); I get Array(); as the output. If I try: var_dump($state_set->getArray()); I get Proust.
  7. Well, I have something as simple as a list of US states and their children (which are Schools). The US states just have a title, as do the Schools. I have looped through all the states and split them into two arrays for display purposes. All I want to do is var_dump the array that contains the objects, but PW spits out an insane 20 page novel about the contents of the states and their children.
  8. Is there a way to do a var_dump() in PW without getting a massive incomprehensible array returned? The amount of data that's inside the object is so extensive that it often crashes the browser. Is there a wrapper function that's just for debugging?
  9. I don't think this approach would work in that situation, though, because in the case I was describing over there, I still want the client role to be able to add children in the admin, just not from the home tree. If the sectioned-off tree were under the admin, the client role wouldn't be able to access it, right? Or am I missing something?
  10. It sounds like this would be way more widely accessible than prepending a functions file before each template, I think I'll go this route.
  11. Sweet, I had no idea about that. I'll try that... Not sure what's going on either.
  12. This is pretty basic, possibly more PHP-related than PW: Where do we put generic functions that are specific to the installation? In WordPress, this was in the functions.php theme file, where if you put functions there, they become accessible throughout the application. I've made an init.php file that I include before the header/footer for all the templates in the /site/templates folder, but functions I define in there don't seem to be accessible to files included in those templates. (So like, page.php includes init.php, header.php, callout.php, and footer.php, but when I call someFunction() defined in init.php from callout.php, it tells me the function is undefined). I have a group of common functions I'm using across multiple sites defined in a module as static public functions of a single class, and that's working everywhere. Do I need to make a module for my functions specific to the installation?
  13. Yes, that makes sense. My only gripe has to do with presentation to the user in the admin; while right now I have the ability to slice off irrelevant/non-navigable parts of the main tree so that client user roles can't see it (like these colors in this case, which are not part of the hierarchy of the site in the client's mind), PW doesn't provide a built-in way to do that. From what I've read around the forum, there's no real hook to stop certain parts of the tree from rendering; I have to pop them out of the JSON per soma's technique.
  14. PW continues to surprise me with its simple goodness.
  15. Ah, I see that this module's approach isn't relational... So I guess, since I'm already hiding branches of the tree from the client user role, what I'll do is just make a page called "colors" with its children being each "color" object. Then I'll hide that page and the children from the home tree [like so: http://processwire.com/talk/topic/4154-first-steps-to-making-new-admin-tabs/], this way the client role can't get at that part of the site except when choosing the children to associate with other pages.
  16. This seems really simple but I'm missing it: How do I create a fieldtype that's just a select box with a set of hardcoded values? Like: -- Choose -- - Red - Blue - Green I don't want to create pages for each select option using the Page field type.
  17. Interestingly, the problem I was experiencing seemed to solve itself... It's probably because I was constantly clearing my cookies for a different project. The admin menu tabs do stay open if you're on submenu items and they achieve it through a cookie. But kongondo makes a good point.
  18. Is there a proper way to do this? I'm using the Ergo admin theme, so should I just go in and edit the js used by the admin theme?
  19. Okay, so here's what I came up with: Goal: Make a branch of pages in the Home tree completely hidden from a "client" role, say of Menus or Sidebars, but that is visible from a tab in the admin's primary menu so that the client is just dealing with pages in the "Home" tree. The end result being just "Pages," "Menus," and "Sidebars" in the primary admin menu. Steps: 1) I make a template called "node" for any parent page that starts a branch of pages that shouldn't be viewable in the Home tree to the client role. This isn't necessary but I feel like it's helpful because now these pages don't resemble the regular page template if the user somehow stumbles upon them. 2) I make a page called "Menus" and assign it the "node" template in the Home tree. All my custom menus are children of this page. 3) I make a page called "Menus" as a child of the hidden Admin page in the Home tree. This causes PW to make a tab with the message about not having a process assigned to it. 4) I make a module that assigns a process to the new template: (http://processwire.com/talk/topic/1272-new-page-nav-in-admin/): class UtilityMenuList extends Process { public static function getModuleInfo() { return array( 'title' => 'Custom Menu List', 'summary' => 'List all custom menus.', 'version' => 100, 'permission' => 'page-edit' ); } public function execute(){ $pl = $this->modules->get("ProcessPageList"); $pl->set('id',1057); // or any other parent page return $pl->execute(); } } Here we set the ID to the "Menus" page from step 2. This is the branch of pages we want to appear on the Menus tab. 5) We go back to the Menus admin page from step 4 and choose UtilityMenuList from the Process field. This makes PW show a Home tree that only includes the Menus branch. 6) Now we want to exclude the Menus branch from being visible on the Home tree, since that should only show "regular" Pages. I followed Soma's tutorial here for extracting branches from the JSON, since it's not apparent how to hook into ProcessPageList according to this thread: http://processwire.com/talk/topic/1272-new-page-nav-in-admin/. We create another module: <?php /** * Utility Hide Nodes * * Hides pages with a node template from display in the admin. * * ProcessWire 2.x * Copyright © 2010 by Ryan Cramer * Licensed under GNU/GPL v2, see LICENSE.TXT * * http://www.processwire.com * http://www.ryancramer.com * */ class UtilityHideNodes extends WireData implements Module { public static function getModuleInfo() { return array( 'title' => 'Hide Node Pages', 'version' => 100, 'summary' => 'Example module to hide page in the admin per user per page. Add a page field "pagelist_hidden" with a PageListSelectMultiple input type to the user template. Select or add pages you want to hide in the admin.', 'href' => '', 'singular' => true, 'autoload' => true ); } public function init() { // only add hook only if the render parameter is set // (as used by ProcessPageList) if(!isset($_GET['render'])) return; $user = $this->user; $roles = $user->roles; // loop thru each role foreach($roles as $role) { if (!$role->pagelist_hidden) return; } $this->addHookAfter('ProcessPageList::execute', $this, 'pageListHiddenPages'); } public function pageListHiddenPages(HookEvent $event){ $user = $this->user; $roles = $user->roles; foreach($roles as $role) { foreach($role->pagelist_hidden as $hidden_page) { $hidden[] = $hidden_page->id; } } // make sure it's an ajax request if($this->config->ajax){ // manipulate the json returned and remove any pages found from array $json = json_decode($event->return, true); foreach($json['children'] as $key => $child){ if(in_array($child['id'],$hidden)) unset($json['children'][$key]); } $json['children'] = array_values($json['children']); $event->return = json_encode($json); } } } 7) I altered Soma's code to make it work with roles. We go to the Role template instead of User and add a new field called "pagelist_hidden" of the type Pages, with the following settings: Details = Multiple Pages (PageArray) and InputFieldType = PageListSelectMultiple. This will let us choose specific pages to make hidden from the Home tree on a role-by-role basis. 8) In my case I have a "client" role, so I assign this field to the Role template and then pick my Menus branch on the "client" role. 9) If I log in as the client role, the Menus branch doesn't appear at all in the Home tree, but I can still see it in the branch that gets outputted under my new Menu tab. So as a result we can add as many tabs as we need (potentially to create the illusion of more content types beyond pages) and hide as many branches thru the admin interface by simply adding them to the client's user role. The Menus parent page still appears on this tab, which is unfortunate but not so bad. If this were a Blog section, it would still make sense visually. I just set the parent to be uneditable, that way the client can't mess with it, but the children are still editable. Next step would be... can we somehow paginate a branch? Anyhoo it's pretty neat so far. Edit: Altered Soma's code to work with roles & not individual users.
  20. Does this still work? I'm testing it out with several different parent IDs, but the admin page always returns the full, default tree. Edit: Oops it does - one clarification is that whatever you name the class, you have to pick that from the dropdown for the admin page after the module's installed.
  21. Thanks for these links & the advice guys, this board is pretty solid.
  22. Sweet, I'll check that out tomorrow. RE: the article; I appreciate the article's discussion of a "master geography" or single kernel of truth, suggested by the system, as the basis for all relationships between content types. I also agree with Ryan's comment in the article about how we need a master tree so that content doesn't get disconnected from the URL maps that the Web/Google depends on. I guess when I say I'd like to bucket out content in the admin, I don't mean to actually separate the content from the "home" tree. That is, it looks like all pages, no matter what templates they use, live off the "home" tree in PW and are connected to it, whether they generate real URLs or not. What I'd like to try and do is make separate tabs/admin pages for content like sidebars, widgets/blocks, and menus since they don't have URLs in the front end, and definitely do behave differently than regular pages in the system (since, for example, there are things like custom menus, global sidebars, and global widgets/blocks and so on). I think this might be as easy as having a page called "Sidebars" in the hierarchy that's hidden from the "home" tree (excuse my lack of familiarity with the PW terminology here), but made visible, with all its children (presumably the individual sidebars that can be assigned to pages throughout the site, and their child widgets), if you visit a tab like "Sidebars" in the main admin navigation. Same for menus. So really, for me, it'd just be a matter of making a new admin page that can be linked to from the main navigation, and then listing out a particular subtree of the home tree. As far as philosophy's concerned, my driver's really the client; my experience is that they have less success searching for stuff that behaves like an attachment to the real content in a tree than in its own cordoned-off little area.
  23. As an early foray into PW, I've been porting over a WP site I built not too long ago. Needless to say it's been pretty amazing so far and I'm excited to keep going. The way the selectors work is a dream compared to WP, even if PW is in its infancy when it comes to the admin interface. Now, there are probably more bad WordPress developers out there than good ones, and I know this having spent the past five years working in WP and making the transition, but one thing WP does have down right is the clear separation of content types in the Dashboard: Content types like Pages/Posts/Custom Post Types with taxonomies are organized differently than Menus or Sidebars & Widgets, and so on. By this I mean, visually, of course: that is, I go to a different part of the admin to administrate different types of data, and my experience with clients I've built installations for is that this visual separation of content makes sense to them, often without my having to explain anything when I release a build. This is of course as compared to say, the way Drupal organizes its content in the admin, which only ever gives clients headaches. Anyway, I want to experiment with the Ergo admin theme and see what complexities are involved in adding new tabs to the main menu, potentially to create the illusion that specific pages and/or trees of pages are stored in separate parts of the PW admin. Has there been any talk in the forums about this? If anyone can point me to discussions you've come across, that'd be great.
  24. Cool, I'm going to mark this as solved because it seems like it's just a matter of selectors/ingenuity at this point. Thank you for the investigative help! Edit: In fact, has_parent!=1057 works for all grandchildren! Both the superuser & the client gets the restriction. The only weirdness that remains is that the superuser also sees all the little admin cluttery pages, but that's not a big deal for me because the client's list is clean.
×
×
  • Create New...