renobird

echo $rp->title; that gives me the correct page title, so the get seems to work.

Hi Wanze, I'm not sure what is going on actually, I was trying something very similar. $rp = $pages->get('id=4591'); $rp->of(false); $rp->form_expense_description = 'test'; $rp->save(); that gives me these errors: Notice: Trying to get property of non-object in /xxxx/wire/core/PageAccess.php on line 25 Notice: Trying to get property of non-object in /xxxx/wire/core/PageAccess.php on line 27 Fatal error: Call to a member function hasRole() on a non-object in /xxxx/wire/core/Page.php on line 1275 This error message was shown because site is in debug mode ($config->debug = true; in /site/config.php). Error has been logged.

Can repeater pages be edited directly? Seems like even if I know the ID of the page, I can't update it via the API.

USA, USA, USA! Oh wait, this isn't a futbol.

Is there a way other than the removeAll() method to update existing repeater fields? I have pages that have 10 repeaters—each page may get edited a dozen times or more. What happens with removeAll() is each time the page is saved, the repeaters are removed and recreated — assigning them a new page id. The page id numbers start to grow like crazy. For example: 1 page with 10 repeaters that gets edited 10 times = 100 new page ids. Not a huge deal. Except, there could be 20-30 pages that get that many edits. Now we are talking about 2000-3000 new page ids — every day. So I'm looking for another method to update the existing repeaters. There will always be the same 10. No more, no less. A gentle nudge in the right direction would be appreciated.

roelof, Look into $input->urlSegment (about 1/2 way down the page).

Absolutely. One thing to remember: there are lots of different ways to accomplish things with PW. You might take this as a starting point and end up going a completely different (better) route.

I think this method will work even if you expand it out. I changed a few things up, but hopefully it makes sense. Product pages use "template product", all other catalog pages use "template catalog". Catalogue -- Men ---- Shoes ------ Product 1 ------ Product 2 ---- Hats ------ Product 1 ------ Product 2 -- Women ---- Shoes ------ Product 1 ------ Product 2 ---- Hats ------ Product 1 ------ Product 2 Categories (these pages only a template with a title field) -- Brands ---- Brand 1 (title only template) ---- Brand 2 (title only template) -- Type ---- Type A (title only template) ---- Type B (title only template) -- Collections ---- Collection A (title only template) ---- Collection B (title only template) catalogue.php template & product.php template (same contents) <?php /* There might be a better way to accomplish this. The only reason to have 2 templates is to give find() a way * to only return the actual product pages, and not all the parent pages as well. * * update: You may want to look into using the alternative template method: * * * With this approach you would create a real file (product.php) for the product template, * catalogue template would have no file associated, but point to product.php under the advanced settings tab. */ include("./site/templates/head.inc"); include("./site/templates/product-view.inc"); include("./site/templates/foot.inc"); product-view.inc <?php $brand = ""; $type = ""; $collection = ""; if ($input->urlSegment1) $brand = ",brand.name=".$input->urlSegment1; if ($input->urlSegment2) $type = ",type.name=".$input->urlSegment2; if ($input->urlSegment3) $collection = ",collection.name=".$input->urlSegment3; if ($input->urlSegment4) { // if Segment 4, then we know what page to get $product = $pages->get("name=$input->urlSegment4"); echo $product->title; } else if ($input->urlSegment1){ // check if we are using URL segments if ($input->urlSegment1 == "all"){ $products = $pages->find("has_parent=$input->urlSegment2, template=product"); } else { $products = $pages->find("has_parent=$page->path, template=product, . $brand . $type . $collection"); } foreach ($products as $p){ echo $p->title; } } else { $products = $pages->find("has_parent=$page->path, template=product"); foreach ($products as $p){ echo $p->title; } } Looking at example URLS to see how the selector would get populated: /catalogue/brand1/ Brand1 is a url->segment1 so the elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1"); /catalogue/brand1/casual/ elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1, type.name=casual"); /catalogue/brand1/casual/trendy/ $products = $pages->find("parent=/catalogue/, template=product, brand.name=brand1, type.name=casual, collection.name=trendy"); /catalogue/men/ $products = $pages->find("has_parent=men, template=product"); /catalogue/all/shoes/ $products = $pages->find("has_parent=shoes, template=product"); /catalogue/all/hats/ $products = $pages->find("has_parent=hats, template=product"); /catalogue/men/shoes/ no URL segment here, so the if/elseif are false, so we get: $products = $pages->find("has_parent=/catalogue/men/shoes/, template=product"); /catalogue/men/shoes/brand1/ Brand1 is a url->segment1 so the elseif evaluates to true, and the selector gets populated to become: $products = $pages->find("parent=/catalogue/men/shoes/, template=product, brand.name=brand1"); you get the idea. Again, untested and coded in the browser — but hopefully thought out enough to get you started.

zyON, I'll have to get back to you on this—need to put my son to bed. But, what your asking is possible - the simplest method is to create a page for /catalogue (no children) and give it a new template that template can use different urlSegment logic to figure out what pages to display. It's possible to do it without an actual page for /catalogue - using the same product template. That method gets a little more complicated. I would need to revise my initial example some.

zyON, I think this will all make sense if you start putting together a prototype. Edit: sorry, posted at the same time as your question above. Answering now...

Hi zyON, That is almost what I meant. For your page tree: Shoes -- Men ---- Product 1 (product template) ---- Product 2 (product template) -- Women ---- Product 1 (product template) ---- Product 2 (product template) Categories (these pages only a template with a title field) -- Brands ---- Brand 1 (title only template) ---- Brand 2 (title only template) -- Type ---- Type A (title only template) ---- Type B (title only template) -- Collections ---- Collection A (title only template) ---- Collection B (title only template) You client will only ever look at /categories if they need add new items. They will interact with it completely from the pageField in the product template. If your client needs to see additional information about each product in the page list, that's where you could use the Page List Better Label module If they need even more detailed views, you might be able to make use of Diogo's Admin Custom Pages Module Product Template: include("./site/templates/head.inc"); $brand = ""; $type = ""; $collection = ""; if ($input->urlSegment1) $brand = ",brand.name=".$input->urlSegment1; if ($input->urlSegment2) $type = ",type.name=".$input->urlSegment2; if ($input->urlSegment3) $collection = ",collection.name=".$input->urlSegment3; if ($input->urlSegment4) { // if Segment 4, then we know what page to get $product = $pages->get("name=$input->urlSegment4"); echo $product->title; } } else if ($input->urlSegment1){ // check if we are using URL segments $products = $pages->find("parent=$page->path . $brand . $type . $collection"); foreach ($product as $p){ echo $p->title; } } else { // do something else for pages without URL segments } include("./site/templates/foot.inc");

Hi zyON, That is almost what I meant. For your page tree: Shoes -- Men ---- Product 1 (product template) ---- Product 2 (product template) -- Women ---- Product 1 (product template) ---- Product 2 (product template) Categories (these pages only a template with a title field) -- Brands ---- Brand 1 (title only template) ---- Brand 2 (title only template) -- Type ---- Type A (title only template) ---- Type B (title only template) -- Collections ---- Collection A (title only template) ---- Collection B (title only template) If your client needs to see additional information about each product in the page list, that's where you could use the Page List Better Label module If they need even more detailed views, you might be able to make use of Diogo's Admin Custom Pages Module Product Template: <?php include("./site/templates/head.inc); $brand = ""; $type = ""; $collection = ""; if ($input->urlSegment1) $brand = ",brand.name=".$input->urlSegment1; if ($input->urlSegment2) $type = ",type.name=".$input->urlSegment2; if ($input->urlSegment3) $collection = ",collection.name=".$input->urlSegment3; if ($input->urlSegment4) { // if Segment 4, then we know what page to get $product = $pages->get("name=$input->urlSegment4"); } } else if ($input->urlSegment1){ // check if we are using URL segments $products = $pages->find("parent=$page->path . $brand . $type . $collection"); } else { // do something else for pages without URL segments } include("./site/templates/foot.inc);

zyON, If your client needs to add additional brands, collections, types, then they will need access to those pages. To make it less confusing, you can set them up underneath a parent page. Categories -- Brands ---- Brand 1 ---- Brand 2 ---- Brand 3 -- Types ---- Type A ---- Type B ---- Type C -- Collections ---- Collection 1 ---- Collection 2 ---- Collection 3 If you set the parent page /categories to hidden, then it will show as a lighter color in the page tree, and searches won't return any of those pages. I tend to use something like /tools/ or /config/ to keep things like this all grouped in one nice location.

haha. I'm sure I have many on that wall as well.

diogo, I'm not following your example. (sorry). Wouldn't the parent always be either /shoes/men/ or /shoes/women/? The other parts of the selector are looking for pageField values — and there could be multiple. Maybe I'm being dense and just not getting it.

diogo, Nice. I was revising my example while you were doing this. See my updated version.

Hi zyON, I think $input->urlSegments would work here. Although, you may need to up the maximum allowed number of segments in your /site/config.php — I think the default is 4, so you might be OK. Anyhow, for a URL like: http://sitename.com/shoes/men/brand1/casual/collection1/product1 In this case you are already specifying the exact page you want, so you can do a simple: $pages->get("name=$input->urlSegment4"); Putting it all together: $brand = ""; $type = ""; $collection = ""; if ($input->urlSegment1) $brand = ",brand.name=".$input->urlSegment1; if ($input->urlSegment2) $type = ",type.name=".$input->urlSegment2; if ($input->urlSegment3) $collection = ",collection.name=".$input->urlSegment3; if ($input->urlSegment4) { // if Segment 4, then we know what page to get $product = $pages->get("name=$input->urlSegment4"); } else if ($input->urlSegment1){ // check if we are using URL segments $products = $pages->find("parent=$page->path . $brand . $type . $collection"); } else { // do something else for pages without URL segments } This is untested, and written in the browser (there may also be easier methods, this is just off the top of my head while on lunch break.) ...and of course, it may not work at all. Try it out and let me know.

lucas, Search via google (or you SE of choice), the forum search leaves something to be desired. Diogo has you covered though — categories are easy.

Deleted *was looking at the wrong thing*

I think changing the structure (like I suggested) would make it more efficient — even just from a product entry standpoint. Grouping by the largest set first (Men/Women) and then creating any references from there. You could setup the template to show brand / collection in the page list, or you could get all fancy with Page List Better Label

@nik, @diogo, Nice catch guys. "has_parent" is what I intended — I'll update the post.

zyON, Check into the Page Fieldtype Maybe something like this for organization: Shoes -- Men ---- Product A ---- Product B ---- Product C -- Women ---- Product A ---- Product B ---- Product C Brands (these are just the references, no products listed as children) -- Brand 1 -- Brand 2 -- Brand 3 Collections (these are just the references, no products listed as children) -- Collection A -- Collection B -- Collection C Create page fields for Brand and Collection, and add them to your "Product" template. Now you can associate brand and collection with each product. So to get the output you need: Shoes > Men (Any Brand) $pages->get("/shoes/men/") Shoes > Brand2 $pages->find("has_parent=/shoes/, brand.title=Brand 2") Shoes > Brand2 > CollectionB $pages->find("has_parent=/shoes/, brand.title=Brand 2, collection.title=Collection B") You could also pass $input values to the selector so this could be generated via use selections.

Soma! Soma! Soma! ^ That's how many of him there are.

I've used Textmate for ages. I've tried to switch to Sublime a few times, but end up back in Textmate — not sure why really (habit?).

Hi Ryan, This seems great! I'll give it a test tomorrow. For the project I'm working on I needed to mimicking some functionality from Basecamp where users can select people to notify of a new comment via checkboxes. In this case it's a list of 5-8 people who have a particular role. In order to make it work, I needed multiple custom messages based on $page->template — while leaving the default message in place for existing pages with comments. I also needed an additional field to store the list of email address that need notified of the comment. I happened across this thread and decided to give it a shot. It was pretty easy to add the additional field to the DB and update the module in a few places. I now have an additional field ($comment->notifications) that is output as a hidden field and populated with email addresses via JS. The security concerns are low since all users are trusted and authenticated. The whole thing is pretty specific to the needs of this project, but (as always) I was shocked at how easy it was to get working.