All Activity

This stream auto-updates     

  1. Past hour
  2. I replaced Inputfield::render with InputfieldRepeater::render but it doesn't work.
  3. I know, and I can't reproduce any problem, so more of a step by step guide to reproducing the issue on a clean PW installation would be helpful.
  4. You replied to it. For Github - I have elaborated on the steps to reproduce as suggested. I did however, include a video and example code in the bug report. I also in bold, isolated the exact issue.
  5. $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { $field = $event->object; if($this->process != 'ProcessPageEdit') return; $page = $this->process->getPage(); //... BTW, it would be better to hook a more specific inputfield render rather than just Inputfield::render. So something like InputfieldPageTable::render or whatever inputfield type you are targeting.
  6. Now I cannot access Setup > Templates. I'm getting this error: ProcessWire: ProcessTemplate: Method ProcessTemplate::getPage does not exist or is not callable in this context.
  7. Yesterday
  8. Here is the solution: $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { $field = $event->object; $page = $this->process->getPage(); if($field->hasField == 'myfield' && $page->template->name == "mytemplate") { $field->entityEncodeText = false; $field->notes = 'My new notes!'; } }); Thanks for your tips.
  9. @Tom., members of the PW community might be able to help with your issue if you can isolate the conditions that cause it and list steps for reproducing the issue. In the GitHub issue under "Steps to reproduce the issue" you just say... ...which really does not make for a useful bug report.
  10. It is a public method of the FieldtypePage class. See the description of the arguments in the DocBlock. Not sure. It works for me. But if you're not going to be changing the conditions for selectable pages often then you can just check the template and date in the foreach instead. There is no performance reason to not use a foreach. It's not like a $pages->find() selector where the database is involved. When you do anything with the value of a Page Reference field the entire PageArray (aka WireArray) is loaded (more about that here) and methods like find() or filter() are just foreaching the WireArray internally anyway.
  11. Changelog styles now improved. Here's a changelog from the update screen - no breaking changes detected... ... and here it is with breaking changes ... Raw markdown also get's labelled...
  12. Thanks for the great update @ryan, any chance you could have a look at github? https://github.com/processwire/processwire-issues/issues/434 This bug is preventing me hitting a deadline. I'm worried I may have to swap to dare I say, WordPress until it's fixed. Its for an eCommerce system I'm building for a client which I will be releasing Open Source once completed. This guy seems to be having the same issue - https://github.com/processwire/processwire-issues/issues/430 just in a different context. Basically using save() in the hook Pages::save causes repeaters or page references not to save. Edit: Do you have a paid service in which you can pay to push bugs to the top of the list when it's deadline critical?
  13. I can check each item in the loop... just always strive to resolve everything in the query but maybe not possible in this case.
  14. Thanks for your reply, Robin. This makes a lot of sense and I like your breakdown of this a lot. I don't know too much about the isValidPage() method... can't find too much on the docs about it. Your code snippet line if($modules->FieldtypePage->isValidPage($item, $field, $page)) { What is this doing? isValidPage might be what I'm after but slightly confused by the arguments... Edit: Ah I see (I missed the $field declaration) but unfortunately this is still returning the event that has passed (even though it's now hidden from the PageField).
  15. As a general issue... It's a tricky one, how pages that are already selected in a Page Reference field should be handled if they no longer meet the requirements for selectable pages for that field. When getting the value of the Page Reference field via the API, I think the value should be validated through the isValidPage() method when it is "woken up" from the database. Currently the field value is validated on sleep but not on wakeup. Validating on wakeup would solve the situation where the value of the field when accessed from the API is different to the apparent value when viewing the field in Page Edit. But wouldn't solve the fact that the database value still includes an invalid page and so could give unwanted matches in $pages->find() for example. Or if that is not desirable for some reason then I think there should be some improvement to how invalid items are handled in the inputfield. Currently they are hidden in the inputfield, but that means that if you just view the page in Page Edit but do not save then you get a false impression of what the value of the field is. Maybe if invalid items were shown in the inputfield but highlighted in a warning colour, and then those items removed when the page is saved. Would be good to hear what others think about how invalid selected pages should be handled. For your specific issue... If you are foreaching the pages in your template, you could check the template and date of each item to determine if it should be output or not. Edit: you could actually use FieldtypePage::isValidPage() to validate each page in the Page Reference field value in your template, e.g. /* @var FieldtypePage $field */ $field = $fields->home_whatson; foreach($page->home_whatson as $item) { if($modules->FieldtypePage->isValidPage($item, $field, $page)) { // output $item } }
  16. Thanks for the updates! Seeing as the profile editor is getting some improvements, could you look at adding FieldsetTab support? Related topics: https://processwire.com/talk/topic/16125-tabs-on-profile-edit-page/ https://processwire.com/talk/topic/16253-user-profile-tabs-markup-regions-the-lack-of-tuts/
  17. Some discussion on this and using listable() https://github.com/ryancramerdesign/ProcessWire/issues/302
  18. To hide pages from ProcessPageList for non-superusers (doesn't apply for superusers) you can hook Page::listable(). $page->listable() bool Returns true if the page is listable by the current user, false if not. Can also be used as property: $page->listable So to hide pages that the user cannot edit you can add this to /site/ready.php: $wire->addHookAfter('Page::listable', function(HookEvent $event) { $page = $event->object; if(!$page->editable) $event->return = false; });
  19. This takes me back to my newbie days PS - hope that didn't come across as though I was suggesting that is a newbie question @jploch - I would probably have referred to that old if I had the need once again.
  20. If you can control the naming of the images then that is an easy solution. Otherwise you need to do natural sorting of the files array. Something like: $files_array = $item->sequenz_files->getArray(); natsort($files_array); // Now foreach $files_array // And if you need the files as a Pagefiles object for some reason $pagefiles = new Pagefiles($item); $pagefiles->import($files_array); // Now foreach $pagefiles
  21. Easiest way that works for inputfields both inside and outside of repeaters is to match the name of the field associated with the inputfield: $wire->addHookBefore('Inputfield::render', function(HookEvent $event) { $inputfield = $event->object; if($inputfield->hasField == 'YOUR_FIELD_NAME') { //...
  22. JFYI — That loading screen won’t disappear on my iPad (iOS 11) Backend looks like a hell lot of work. 👍
  23. Hi folks, I have a PageReference field which is selecting events (that are in date by a date field) and articles with a specific template. My hook in order to allow those pages is as follows: $wire->addHookAfter('InputfieldPage::getSelectablePages', function($event) { if ($event->object->hasField == 'home_whatson') { // Get in date events $events = new PageArray(); foreach ($event->pages->find("template=events-detail, events_detail_dates.events_detail_dates_start_date>=today, sort=events_detail_dates.events_detail_dates_start_date, sort=name") as $e) { $events->add($e); } // Get Our Picks articles $articles = new PageArray(); foreach ($event->pages->find("template=our-picks-detail, sort=sort") as $article) { $articles->add($article); } // Push events into the pages we allowed $events->import($articles); $event->return = $events; } } This works well but if an event has passed (before it is removed from the PageReference field), obviously it doesn't 'remove' it from the list it simply hides it (even though it's still technically 'selected'). I then need to do a check on the front end for this as well so it isn't returning the items that have passed. I thought this would work: $today = strtotime("now"); $articles = $page->home_whatson->filter("events_detail_dates.events_detail_dates_start_date>$today"); But it's obviously now ignoring the articles with the specific template as the filter is removing it from the list (as this should only be applied to events). Is there a way round this? Should I put removing it from the original query (using ->remove()) or is there some other way? Any help is appreciated.
  24. Have you tried this gist: https://gist.github.com/adrianbj/e391e2e343c5620d0720 With this PW permission: I haven't tested, but I think that combination should work as is, or with a little tweaking. Might avoid you needing to reinvent things.
  25. This week we've got a newly updated ProcessWire installer, some nice upgrades to our user profile editor, along with more updates to the new Uikit admin theme that was recently added to the core. https://processwire.com/blog/posts/processwire-3.0.84-core-updates/
  26. You need to install the PDO driver: https://stackoverflow.com/a/6735730/1524576
  27. Hi, I'm having this problem: [06-Nov-2017 16:05:56 America/Santiago] PHP Fatal error: Uncaught Error: Undefined class constant 'MYSQL_ATTR_INIT_COMMAND' in /home/maiposalud/devel.maiposalud.cl/wire/core/WireDatabasePDO.php:137 Stack trace: #0 /home/maiposalud/devel.maiposalud.cl/wire/core/ProcessWire.php(371): ProcessWire\WireDatabasePDO::getInstance(Object(ProcessWire\Config)) #1 /home/maiposalud/devel.maiposalud.cl/wire/core/ProcessWire.php(209): ProcessWire\ProcessWire->load(Object(ProcessWire\Config)) #2 /home/maiposalud/devel.maiposalud.cl/index.php(52): ProcessWire\ProcessWire->__construct(Object(ProcessWire\Config)) #3 {main} thrown in /home/maiposalud/devel.maiposalud.cl/wire/core/WireDatabasePDO.php on line 137 Any ideas?
  1. Load more activity