kongondo

Actually I suspected that but forgot to mention it. Since you are in a foreach loop, it means that this code does not always get a page, i.e. some of the pages don't exist. $product_pages = wire("pages")->get("productid=$id_product"); //get the correct page so the images are placed in the correct product page Change that to: // get the correct page so the images are placed in the correct product page $product_pages = $this->wire("pages")->get("productid=$id_product"); if(!$product_pages) continue; I assume you've previously sanitised the values of $id_product. Are they integers or strings? What type of field is productid?

So, my question still remains. Maybe confirm with some simple debugging of what this returns: $imgfield = $product_pages->images_product; echo gettype($imgfield); Since you are getting the 'non-object' error, I'm pretty sure that will echo NULL.

Too early to give up maybe . What is ranking in this case? What I meant specifically is are you sure $imgfield is an Image object? Is ranking an Image object or some other field on the page? @note: I edited my post above about output formatting; don't know if you saw that.

Nothing jumps out at me. Things to confirm: $imgfield = $product_pages->images_product; Are you sure that returns an Object and not Null? Some other comments, by the ways... Is this by your design or by necessity (i.e. Prestashop demands that). Normally, especially in cases where several products can share one or more categories, you want to have categories separated from the products (i..e not as their children). // ensure output formatting is off $product_pages->of(false); This is not necessary here. Output formatting is always off in a module context. if (!$parent->hasChildren()) { } That may not be very foolproof (could children have been manually deleted?). You can check using the module version instead, i.e. if version is less than x, do this, else do that. I can't find the exact syntax for it now but will edit this post later if I do. Edit: grep version_compare under /wire/modules/ for more examples. Here's an example from a third-party module, changelog. Edit 2: Arrgh. Scrap that. That's not it really; Hopefully someone will chime in. You should be able to compare versions of your modules programmatically though; I'm sure of it.

Could you explain a use case for this? Other than that, not sure if you know that there's a module that can auto-publish/unpublish at specified dates. There's also a published date property for pages. I don't know if those cover your needs, but good to know.

@Sérgio. Excellent! Thanks for sharing!

Played a bit more with this. The following works for me. I am not sure if it is foolproof and/or if there are better approaches. Please note: From what I can tell, when saving a page, inputs (fields) will be sent in the order they appear in a template. date1 refers to the first date and date2 to the last date. We need to temporarily store the value of date1 in order to later compare it to date2. I stored the value in a session. You could do it differently, e.g. cache it. The code doesn't prevent a save of the 2 date fields. You can do that if you wish. This code is necessarily verbose in places; just to make things clear. public function init() { $this->pages->addHookAfter("InputfieldDatetime::processInput", $this, "hookAfter"); } public function hookAfter(HookEvent $event) { $field = $event->object; if($field->name == 'date1' || $field->name == 'date2') { // @note: from what I can tell, inputs are sent in the order of the fields in the page // ...so, date1 will be hooked into before date2 $date1 = '';// first date $date2 = '';// last date $session = $this->wire('session'); // save date1 to session; we'll retrieve it to compare against date2 if($field->name == 'date1') { $date1 = $field->value; $session->set('date1', $date1); } elseif($field->name == 'date2') { $date2 = $field->value; $date1 = $session->get('date1'); // compare the first and last dates if($date1 >= $date2) $field->error("Last date must be greater than the first date"); //else $this->message("Those dates are fine matey!");// @note: for testing only // delete the temporary session date1 $session->remove('date1'); } } }

Try Hooking into the inputfield instead like so. Note, example is from module context. See also notes below: public function init() { $this->pages->addHookAfter("InputfieldDatetime::processInput", $this, "hookAfter"); } public function hookAfter(HookEvent $event) { $field = $event->object; if($field->name == 'recurringdateend'){// @note: just a quick example; you might want to hook into 'date_end' as well $page = $this->wire('modules')->ProcessPageEdit->getPage(); #$this->message($field->name);// @note: testing only #$this->message($page->id);// @note: testing only /* // @note: testing only + FOR INFO $oldDate = $page->get($field->name);// existing DB value $newDate = $field->value;// incoming/NEW data $this->message("old date is: $oldDate");// returns timestamp $this->message("new date is: $newDate");// returns timestamp */ // @note: quick example, not useful to you but a good to know 'how-to' // @note: what you really want I suppose is to compare incoming values (from input) // @see above for that ($oldDate and $newDate) $firstdate = $page->get("date_end");//date field 1 $lastdate = $page->get("recurringdateend");// date field 2 if($firstdate >= $lastdate){ //check if the date of field 1 is higher than the value of field 2 // error here; @note $lastdate is not a field! // error example: $field->error('Some Error'); } } } @Note that in my example we are comparing existing DB values (not very useful). In your case, you want to compare incoming values, right? See the $oldDate and $newDate example. However, you would need to Hook into both 'date_end' and 'recurringdateend' in that case (i.e. run your Hook code if either is the field name). Edit2: See complete answer in next post.

What version of ProcessWire is that? That function is not in any of ProcessWire's files. In addition, FYI, ProcessWire's /wire/core/Database.php extends PHP's mysqli class. Edit: Beaten by lostkobrai. I should have noticed there is no such file in ProcessWire

...mystery solved . Edit: Your OP stated that you needed the Hook to run when a new page is added. Why not Hook into that instead? i.e. 'Pages::added'

Looking at your module code again, I notice this: // @kongondo note: here you are deleting the cache, meaning... $cache->delete("cacheName:" . $page->id); // @kongondo note:...that here we don't have that cache and one will be created afresh $cache->get("cacheName:" . $page->id, $cache::expireNever, function() use($page){ // code you want to cache $content = $page->title . "<br>"; $content .= $page->body; return $content; }); The code inside the Hook is executed because by that point, you have no cache; you have deleted it. So $cache->get() doesn't get the cache and one is created afresh. It seems to me that a Pages::saveReady is happening when you load your pages and that is triggering the cache to be deleted and recreated? But it doesn't make sense since when you reload, your page is reloaded from the cache. Are you sure about that? Have you checked the timestamps? Maybe confirm your workflow. Are pages being created via the API when you visit some page in the frontend?

I assume you are talking about the frontend hence using the latter code in your example. According to the docs (see this example as well) on $cache->get(), it doesn't say whether a WireCache::expire* constant can be used in that combined get and save of cache, unlike in $cache->save() docs where it is explicit that those constants are allowed. Just guessing here, maybe try it like in the $cache->get() docs? i.e. passing null instead of a constant: $cache->get("cacheName:".$page->id, null, function() use($page){ // code should be the same as the one that preloads the cache $content = $page->title . "<br>"; $content .= $page->body; return $content; }); Edit: You can also see the differences in the code here (get) and here (save). save() accepts constants whereas get() doesn't seem to. Edit 2: I am also wondering whether in the template file you needed an explicit WireCache:expireNever rather than $cache::expireNever?

I am not sure whether this is relevant in your case and it is from a while back but just thought to post to see if it helps:

What @Klenkes said. You might want to add a limit=n in that selector though.

Did you see this post in your other thread ? If podcast_shows is a multi-page field, it doesn't matter whether you have one or more pages selected in it; it will return a PageArray.

Welcome to ProcessWire and the forums @swampmusic, You have two options. Media Library is a free module and Media Manager a commercial module (easily handles all sorts of media assets using a centralised approach; full disclaimer; I am the author of this module ). Oh, I think you meant Ryan, not Rory .

OK. It seems you are using an older version of ProcessWire, pre-dating the change in using custom code in page fields (can't remember in what version of ProcessWire 3.x this was introduced). Anyway, then the below is the FORMAT of the code that you need to enter in the custom code textarea. Adapt it to your needs; e.g. a suggestion was made for $page->parent->podcast_show but I see you are using children instead. Also note that I don't know what podcast_show is, so don't know if that code will return anything. This is just a pointer return $page->children->podcast_show;

Show us the code in your /site/ready,php as per Robin's suggestion...Maybe you have a typo there.

OK....then go with what works .

You should only have one set of files. That could have been the source of the problem. If you install (or upgrade) Blog via ProcessWire itself (i.e. as opposed to uploading the module yourself), the folder should be ProcessBlog (I think - not sure since being its developer, I don't install in that manner since I have the files locally). Whatever the case, you should only ever have one set of files, irrespective of whether they live in different folders. So, yes, delete one set and rename the Blog folder to what it should be (my guess is ProcessBlog; if not that, Blog, but definitely not MarkupBlog; I shouldn't think so). Hope this makes sense . Regarding _footer.php, is that a template file or a file you are including within some other template file? Btw, looking at the code in footer.php, I notice you are getting a number of pages by their IDs. Whilst that is the most foolproof way to do it, down the line, especially if there's several such calls in different template files, you will start to get confused what page 1040 was , especially if the code is not documented. In this regard, some people prefer to get by page: $pages->get('/path/to/page/'); Of course, if a page's path changed....you'll have a different problem to deal with. Just my 2p.

No worries. You are just trying to help . @MaryMatlow, what @adrian said. I've been testing against 3.0.42 and Blog seems to work fine. If upgrading doesn't fix the issue, we'll focus on autoload modules.

Actually not a good idea to do that . I made a decision not to namespace my modules (am the author of the Blog module) to instead let the compiler do its work. If @MaryMatlow did that, any changes will be overwritten by the next Blog update. There's something going on with this install which I'd like to get to the bottom of. @MaryMatlow, could you please confirm the ProcessWire version that you are running? (down to the 3.x.x please). The only difference between that module (in the Blog suite of modules) and the others is that BlogPublishDate is an autoload module. I haven't received any other similar reports from other Blog users, which makes me even more curious.

Oops. Pure coincidence; I'm not on your case or anything, ha! .

What @gebeer said. I'd be surprised if that solved your problem though since this line: <?php $deals_item = $pages->get("deals_show_on_endorse=$page->id");?> fetches one page, meaning the foreach in the next line makes no sense.

I see. My point was that the compiler is supposed to take care of cases where a 'namespace' has not been declared (and it does so beautifully). It seems in this case something is tripping it. Although namespacing, in this case, might get around the problem, it will not solve the original issue. It would be helpful to get to the bottom of that since not everyone is able/willing to namespace (especially in existing sites) their template files. I'm wondering whether it is the '.inc.' that is throwing it off or the use of double quotes. Just guessing TBH.