ryan

if you use Page::loaded, it would be good to add that hook conditionally (like if $this->process == 'ProcessPageEdit', before attaching the hook). Otherwise that hook will get called on every single page loaded in the system -- that's great if that's what you want, but not so great if you are trying to deal with something very specific. If you are loading hundreds of pages in a request, this could be more overhead than you want. Even if you attach it conditionally, it could still involve overhead. For instance, if the page you are editing has Page reference fields, it's going to get called for every page in that page reference field too. Whereas something like ProcessPageEdit::execute would only get called once. But if Page::loaded suits your needs the best, then you could find more efficiency in removing the hook after it's done what you need, so that it doesn't get called any more: <?php public function init() { if($this->process == 'ProcessPageEdit') $this->hookID = $this->addHook(...); } public function runHook($event) { // run the hook // ... // remove the hook $this->removeHook($this->hookID); }

Okay now I see why Page::render doesn't work, sorry. Everything has already run by that time. But it looks like there is another option. Try hooking in before ProcessPageEdit::execute It looks like the breadcrumbs are already setup before that execute() method is called, so wire('breadcrumbs') should be set (and modifiable) in such a hook.

If I understand correctly, I think you are wanting to do something like this? <?php $p = $pages->get("template=news, popularpost=1"); echo "<p>"; echo "<a href='{$p->url}'>{$p->title}</a>"; if(count($p->images)) { $img = $p->images->first(); echo "<img src='{$img->url}' alt='{$img->description}' />"; } echo "</p>";

I didn't see any ways to hook into this at some point earlier than what I mentioned. You can't hook into WireArrays adding stuff... it would just be too slow since WireArrays deal with thousands of add()'s per request. While breadcrumbs don't deal with thousands of items, they do extend the WireArray class. So if you want to hook in via a module, I think you have to hook into something broader than specific to breadcrumbs. Adding a 'before' hook to Page::render would be an example. You could iterate the wire('breadcrumbs') in your module to modify them before the page is rendered: <?php if($process == 'ProcessPageEdit') { foreach(wire('breadcrumbs') as $breadcrumb) { if(strpos($breadcrumb->url, '/edit/')) { $breadcrumb->url = str_replace('/edit/?id=', '/list/?id=', $breadcrumb->url); } } } Personally I would just modify /site/templates-admin/default.php -- that's what it's there for, and this is why PW lets you customize your admin theme in /site/. Though the technique you use could be the same as in a module (like above). But in the template you could just do this in the existing output loop rather than creating another.

Hey Adam, These breadcrumbs are output in the admin template, so I think you'll want to modify /wire/templates-admin/default.php. But to make sure your changes persist between upgrades, make another copy of that templates-admin to your /site/ dir (http://processwire.com/talk/index.php/topic,161.0.html). When editing templates-admin/default.php, you should see this part: <?php <ul id='breadcrumb' class='nav'> <?php foreach(wire('breadcrumbs') as $breadcrumb) { $title = htmlspecialchars(strip_tags($breadcrumb->title)); echo "\n\t\t\t<li><a href='{$breadcrumb->url}'>{$title}</a> ></li>"; } ?> </ul> So you can modify that part to do whatever you need. OR, you can modify that wire('breadcrumbs') variable directly, anywhere before the part that outputs the breadcrumbs. It's just a WireArray, so you can manipulate it in the same way as any other WireArray. http://processwire.com/api/arrays/ ... and have a look at this file just so you know what the data type is (it's very simple): /wire/core/Breadcrumbs.php Here's how to determine if they are currently editing a page from the default.php template: <?php if($process == 'ProcessPageEdit') { // they are editing a page }

Thanks Jeff -- glad that Dictator has been working well for you. The problem I'm having with some other Dictator sites is that the clients don't seem motivated to upgrade. Going and working on 7+ year old code so isn't fun, even if it's still functional. But I sure wish I'd put Dictator out there as open source back in 2003. Get in touch next time you are passing through the city of Decatur. I'll get the second round.

I just emailed you a link to download the skyscrapers site profile/installation if you want to take a look at it.

Thanks. Since this is a PHP 'notify' error, I'm guessing you have $config->debug set to true? These notifications should be suppressed if debug is false. Though I usually keep debug on during site development, and off for production. This particular error looks like one that is good to know about though, because it seems to indicate a value that shouldn't be there. If that's the case, it needs to be fixed, so I will keep an eye out for it too.

Great -- looks like it works well!

I'm confused by the field/page names -- is the name of the field "sliderat" or "slider1"? But lets assume there is a field named "images" on the page "/mypage/" and you wanted to pull a random image, like in your example: You'd do it like this: <?php $mypage = $pages->get("/mypage/"); if(count($mypage->images)) { $image = $mypage->images->getRandom(); $thumb = $image->size(400, 200); // if you need a thumbnail // then output the thumbnail and/or image like in previous examples } Also, you had mentioned templates in a context that I'm not sure I understood. Templates define a type. You don't pull data from a template, but from pages that use that template. So think of templates like the database schema for a table, and pages like the rows of data in that table.

Not sure about this one then. Haven't seen that particular error message, and it doesn't seem to make sense, at least not on the surface... but I will look at it again in the morning. Let me know if you see it occur anywhere else. Thanks, Ryan

Glad that worked! It does sound like the PageListSelectMultiple is the right choice for your needs. If it needs to traverse a tree and there are hundreds of possible options, then this is the best bet. We'll also be adding an autocomplete page selection fieldtype at some point, which could be useful here as well.

Have you added a field named 'collapsed' in your system? It looks like I need to add that to the reserved word list, but just wondering if that's the issue here...

I fixed this problem on Jeff's server and wanted to reply here to follow up on what the issue was. The problem involved the URL starting with a "~", like this: /~theameri/process/ Apparently Apache needs the RewriteBase directive set in your .htaccess file if you are using this style of "~" URL off of your domain. And it needs to be set with the part that includes the "~" (something that we didn't cover earlier in the thread). So on Jeff's server, with PW installed in the /process/ directory off of his web root, I set the RewriteBase directive in the .htaccess file like this: RewriteBase /~theameri/process/ If it weren't installed in the /process/ subdirectory (and installed in his web root), it would be this: RewriteBase ~/theameri/ There were two other problems in the PW code that also prevented the "~" URLs from working: 1. PW's htaccess doesn't send any URLs with invalid characters to ProcessWire. I had to add the optional "~" at the beginning of the request URI in the .htaccess so that it would still send that to PW. This has been committed to the source. 2. PW's method of determining the root URL was also not compatible with "~" URLs. I changed it to determine it from $_SERVER['SCRIPT_NAME'] rather than $_SERVER['DOCUMENT_ROOT'], and this has also been committed (not sure why I didn't do this before!). So that's what the issues were, and hopefully we've got this figured out so that nobody else runs into it in the future. Jeff--thanks for your patience in troubleshooting this and helping me to resolve it.

Jeff, dns stuff should not matter... PW doesn't care. But I am curious to see if it works at root ( without the ~theameri part). I got your email with the phpinfo, and it looks perfect, I can't find anything wrong there. This is quite a mystery. If you want to set me up with a shell or FTP access, I can go in and solve it hopefully. Malheur is great stuff btw.. Finally got around to trying it the other day, and think I'm going to have to enjoy another once we figure this out.

Jeff, do you have a phpinfo() page? If not, upload a test.php to your server with this in it: <?php phpinfo(); Look at the result. See if it says anything about mod_rewrite. It really sounds like mod_rewrite is inactive or not working.

Jeff, One other thing to try: Open your .htaccess file and paste a bunch of random characters at the top, like "alkjzb0983t093ozjvozubzb" Load your site. You should get a "500" Server Error. If not, then Apache isn't reading your htaccess at all. To fix that you may need to edit your httpd.conf file (/etc/httpd.conf, /usr/local/apache/conf/httpd.conf, or equivalent). To do that, edit the file and locate your <VirtualHost> directive for the domain where you've installed PW. Add a line within that directive: AllowOverride All You might also just want to do that for the whole server, as it's kind of expected in a hosting environment to be able to use .htaccess files and other things. So you could locate your <Directory "/">: <Directory "/"> Options All AllowOverride All </Directory> I'm not an expert on Apache configs. Just found this has worked for me in the few situations where I've run across servers that weren't reading htaccess files.

So a user named 'needmore' was throwing duplicate entry exceptions? ;D

For some reason I don't have this enabled by default. But here's how you do it: 1. Go to 'Admin > Modules' and make sure that the 'Inputfield > PageListSelectMultiple' module is installed. 2. While still in 'Admin > Modules', click on 'Inputfield > Page' and add 'PageListSelectMultiple' to the list of allowed Inputfields. Save. 3. Edit your Page field and change the Inputfield to the one you just added. Save. Let me know if that does it? The PageListSelectMultiple Inputfield is great for two situations: 1. Where you want to be able to select from multiple pages that may live at different parts in the tree hierarchy. This Inputfield can traverse the tree hierarchy just like PW's PageList. 2. Where the number of selectable options is too much to be reasonable for use with checkboxes or asmSelect. This Inputfield supports pagination of selectable options, just like PW's PageList. The place where I use it most often is in my homepage template where I want to be able to select a few "featured" pages on the site, and I want to be able to select any page, anywhere in the site. I couldn't do this in a scalable manner with any other inputfield. The only other way to accomplish it is to add a "featured" checkbox to all my page templates, and $pages->find('featured=1') to get them (which also isn't a bad solution). The situation you described makes me wonder if this is the best inputfield, because you only need to support two different types (distributors and products in your projects template), and your code will have to differentiate between the two in your template. Assuming you select a single 'distributor' and multiple 'products', and that product pages are children of distributor pages, an alternate approach might be to split it in two fields that are in your 'projects' template: - distributor: Page (single using select) - products: Page (multiple using asmSelect) The parent page for the 'distributor' field settings would be '/distributors/' or whatever it is in your site. For the 'products' field, you would use the "Alternate/custom code to find selectable pages" option in the field settings. And you'd paste in something like this: return $page->distributor ? $page->distributor->children() : new PageArray(); That basically says to return the distributor's children as selectable pages if there is a distributor. Otherwise, return a blank PageArray. Not sure if this is totally applicable to your needs, but just wanted to provide it as an example of what the "alternate/custom code..." option does, just in case it does suite your needs better.

Gena, Glad that you got it working! With the line that generated the error, you can add a check like this to make sure the field is populated: if($slide_page->video_poster) { $img = $slide_page->video_poster->width(300); } With fields that have multiple images, you can perform a check like this: if(count($slide_page->images)) { $img = $slide_page->images->first()->width(300); } I am thinking about adding a 'default image' option to the image fieldtype so that you can optionally have it use a default image when not populated. That way, you wouldn't ever need to perform the if() statements in your code.

;D

That is the intended use. Fieldset will group multiple fields together for editing ease. If you use the FieldsetTab it will place them in a separate tab in the editor (like children and settings). Both can be nested as much as needed. I work on a couple sites that have 50+ fields in a template. So grouping of this sort becomes important. For sites that don't deal with a lot of fields, these fieldtypes will likely not get much use. These fields don't have much use outside of the admin, unless you needed to perform some kind of grouping on the front end.

Gena, thanks for your feedback and glad you like ProcessWire so far. I think Adam had great suggestions. Of those he mentioned, my first thought is something about your php version or configuration. If you want, pm me a link to your phpinfo. Or, if you prefer, try installing a blank copy of processwire to your server. The installer should notify you of any potential issues and workarounds.

Jeff, Open the .htaccess file in a text editor. Around like 70, you'll see this: # ----------------------------------------------------------------------------------------------- # Optional: Set a rewrite base if rewrites aern't working properly on your server. # ----------------------------------------------------------------------------------------------- # RewriteBase / # RewriteBase /pw Uncomment one of the lines above, and set it to your RewriteBase. Try: RewriteBase /process/ or RewriteBase /~theameri/process/ Not sure that'll solve it, but it's worth a try.

I think he means the one from this video: http://processwire.com/videos/page-fieldtype/ I am not at a place where I can test here, but will test and reply a little later when at my desk. Thanks, Ryan