Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling
  • Location
    Rochdale, UK

Recent Profile Visitors

1,935 profile views

iank's Achievements

Full Member

Full Member (4/6)



  1. Hi @astock, No problem. You just need to check for the new page's parent in the selector, something like this: $wire->addHookBefore("ProcessPageEdit::buildForm", function (HookEvent $event) { $page = $event->object->getPage(); $myTemplate = "logbook"; //or whatever your template is called if ($page->template != $myTemplate) return; if ($page->startMileage) return; //not if the start Mileage is present $parent = $page->parent; //get the current page's parent //get the most recent logbook with an endMileage value for the current parent $prevPage = wire('pages')->get("template=$myTemplate,endMileage!=,parent=$parent,sort=-created"); if ($prevPage->id) { $page->startMileage = $prevPage->endMileage; } });
  2. Yes, I think a hook would be needed. Something like this should give you a start, added to site/ready.php: $wire->addHookBefore("ProcessPageEdit::buildForm", function (HookEvent $event) { $page = $event->object->getPage(); $myTemplate = "logbook"; //or whatever your template is called if ($page->template != $myTemplate) return; if ($page->startMileage) return; //not if the start Mileage is present $prevPage = wire('pages')->get("template=$myTemplate,endMileage!=,sort=-created"); //get the most recent logbook with an endMileage value if ($prevPage->id) { $page->startMileage = $prevPage->endMileage; } });
  3. The answer's almost in your question! $s = $location->getUnformatted('location_message_start');
  4. Hi, I'm not sure if anyone can help with this, but something odd is happening on one of my PW sites in the Admin=>Logs. When viewing an individual log's entries, the first page displays just fine, but as soon as I click Page 2 or beyond, the content doesn't refresh; the spinner icon stays visible, and the devtools console shows the 404 page is being returned, instead of JSON. I updated PW (from 3.0.94 to 3.0.165) yesterday, but that seems to be unrelated - I've tried reverting to v94, and the issue remains. I probably just haven't noticed it previously. There's nothing in the Tracy Logs or in debug mode that I can see. Lister page pagination is working OK, and pagination on the front-end is fine; it's just in the Log viewer in Admin. The same happens on localhost as well as the live site. Can anyone suggest where to look? It's not a big deal, just frustrating.
  5. I used PDFLayer (https://pdflayer.com/) recently in a project, and it did a good job of rendering some quite complex CSS. It's free to sign up for an api and you get 100 api calls/month with the free version. It could get expensive though if you have a lot of API calls to make (e.g. $9.99/month for 1000 api calls, $39.99 for 10,000). It was quite straightforward to use though, and you can set it to "test" mode for development, where it will overlay "Sample" on the PDF output, but not use any of your API requests.
  6. No, unfortunately not - I've had to disable the AutoSmush (or at least disable the optimize on upload option in the module). I guess it's a case of keeping an eye open to monitor when they'll fix their SSL. It's affecting non-PW users too: https://wordpress.org/support/topic/ssl-certificates-expired-on-resmush-it-servers/ Regards, Ian.
  7. Are you using the AutoSmush module by any chance, configured to use the reSmush.it service? I've encountered similar problems on a site with this installed, and there seems to be a problem with the SSL certificates on one or more of the reSmush.it servers since late December.
  8. Also, $sanitizer->pageName("raphaël", true) produces raphael. The second param being $beautify, which according to the docs: "Because page names are often generated from a UTF-8 title, UTF-8 to ASCII conversion will take place when $beautify is enabled."
  9. Scenario: I'm importing a whole number of pages via the API which will have titles such as "A Page Title | October 2018" and "Another Page Title | November 2018" and so on. However, there are some duplicates (the titles come from repeaters in another PW installation; these may well have the same title, but a different photo, for example). So, if I'm importing several pages with the same name, let's say: "A Page Title | October 2018" "A Page Title | October 2018" "A Page Title | October 2018" PW knows how to increment page names when they would be duplicated. I want these to create page names like the following: a-page-title-october-2018 a-page-title-october-2018-1 a-page-title-october-2018-2 but instead, the generated page names are: a-page-title-october-2018 a-page-title-october-2019 <= a-page-title-october-2020 <= not what I wanted!! The same behaviour occurs in the PW admin too. Does anybody have a suggestion how to override this situation? Thanks, Ian.
  10. @alexmercenary - Very strange! (as per the title of this thread!)
  11. Hmm, that is weird! It appears as though the first call to a subsequent page number other than the base (1) is overwriting the cached page for the base, though I don't understand how that can happen. I presume you're using ProCache? If so, maybe check the versions of the cached files themselves: When you clear the cache and call the base (first) page and it's rendered correctly, does it save the correct cached index.html in the appropriate ProCache folder in assets? What happens when you then visit one of the higher page numbers, say /page5? Does this 'root' index.html file immediately get overwritten? Is there an index.html in the page5 folder in ProCache assets? How do these two compare? You can also access the cached files directly in the browser since you'll know your own unique ProCache folder structure. This would eliminate any (unlikely) rewrite rule problems.
  12. Hi @alexmercenary, I don't think it's the same problem as I had - that was down to me not validating my UrlSegments. However I have had problems where the wrong "start" value is supplied to the selector, generally by being set by some other part of the code (some other selector with limit elsewhere in the code). I'm not sure that's your issue either, but it may be related. It seems that on your very first page of results, the "start" is somehow being set at a different value, and then this is being cached, generating the wrong set of results and corresponding pagination. If you bypass the cache (https://www.edmplus.co/uk-ltd/edm-consumables/?test=1) or explicitly specify the first page number (https://www.edmplus.co/uk-ltd/edm-consumables/Page1) then it works as expected. I'd look for something that could be inadvertently setting the start value or the $input->pageNum() when these aren't otherwise defined for the selector in question. Not sure if that helps, but maybe it's a start... Others more experienced may chip in!
  13. Hi @adrian - I've submitted an issue to the PW issues github. As you say, it doesn't quite feel like a bug, but at least it's officially on record now.
  14. Hi @adrian: Yes, I think that would work. At least then there is always something visible to the user for the key fields and button texts. I wonder if the cache thing may be an issue though, even if using template cache or WireCache. I'm not sure if there's an easy way around this. Sorry to keep adding problems Adrian..
  • Create New...