Robin S

Hi Daniel, welcome to the forums You could use the approach described here:

Also. these gists by @Soma are good demonstrations: https://gist.github.com/somatonic/5011926 https://gist.github.com/somatonic/5236008 https://gist.github.com/somatonic/5233338

I think this should work: $today = strtotime('today'); $date_end = strtotime('+7 days', $today); $pages->find("template=user, birthdate>=$today, birthdate<$date_end"); Ha, of course that won't work because you have the birth date, which could be from any year. New idea... I think in order to find birthdays in a $pages->find() selector you'll need to store the birthdate day of the year in a separate field in your user template. You could create an integer field "day_of_year" and then populate it from the birthdate field with a save hook: $this->pages->addHookBefore('saveReady', function($event) { $page = $event->arguments('page'); if($page->template != 'user') return; if($page->birthdate) { $page->day_of_year = date('z', $page->birthdate); } }); And to find birthdays: $day = date('z'); $day_end = date('z', strtotime('+7 days')); if($day_end < 7) { $results = $pages->find("template=user, (day_of_year>=$day), (day_of_year<$day_end)"); } else { $results = $pages->find("template=user, day_of_year>=$day, day_of_year<$day_end"); }

I tend to agree, and use include() over wireRenderFile() myself. I suppose one reason some prefer wireRenderFile() is the scope of variables is limited so you don't run the risk of overwriting a variable of the same name in your template file. As for using a view file separate to the the template file, it depends how strictly necessary you consider "separation of concerns" to be. Definitely good if you are part of a team and want to hand the view file on to a front-end person who shouldn't be dealing with business logic. Or if you have a lot of logic that you don't like cluttering up the view. As a solo designer-developer, I like to have my business logic in my template so I can see what is going into variables, but I guess a lot of people would frown on that.

Never say die, where there's a will, there's a way! public function renderPageTable(HookEvent $event){ $page_id = $this->input->get('id'); $page = $this->pages->get($page_id); // use $page... }

Can the "HP" field value be less than zero? I'm not sure what this field holds in your case, but perhaps you just want to stop when the field is empty? $streak = $lastEvent->nextUntil("task.HP=''")->count(); Incidentally, I don't think there's anything wrong with a simple foreach() over 10 page objects or less - no cause for concern over performance there. Several ways you can skin the cat, but one alternative is to use "break" to end the loop when your condition is not met. foreach($lastEvents as $e) { if($e->task->HP >= 0) { $streak++; } else { break; } }

A good way would be to use a checkbox in conjunction with the normal form submit button. Then look for my_checkbox=1 in the post data. Have a look at how the PageimageRemoveVariations module by @horst does it.

Welcome to the forums @mciccone I haven't purchased ProDrafts so I can't give a definitive answer on whether the module has a schedule feature, but it wouldn't be too difficult to code your own solution using the API method for publishing draft pages: $page->publishDraft(); You would take a similar approach to the Schedule Pages module. That is, add a "publish_from" date field to your page template, and use a Lazy Cron hook to find unpublished draft pages with a publish_from date < now and publish them.

Hmmm, works properly for me. You should get a warning message after changing the sort order by drag.

@choppingblock, this does seem to be a bug. I opened a GitHub issue for it. You can successfully sort a page array according to the sort order of an Options field... $my_page_array->sort("my_options_field.sort"); ...but that perhaps won't help you as I see you want to apply a limit/pagination and maybe don't want to load all the pages into memory. Maybe you could switch from an Options field to a Page field?

If you don't want the "optional" HTML tags removed there is a setting in ProCache to disable this behaviour.

Definitely a useful module, thanks @Rudy! A couple of things... When using a single SCSS file I get a PHP warning notice: And it would be good if the module only recompiled the CSS if one of the source SCSS files changes rather than recompiling on every page load. A while ago I wrote a simple function for compiling SCSS to CSS using ScssPhp, only when needed. Perhaps you might find something useful in there: require_once TEMPLATES . '/stylesheets/scssphp/scss.inc.php'; use Leafo\ScssPhp\Compiler; function compileCSS(){ // get timestamp of most recently modified SCSS file $files = glob( TEMPLATES . 'stylesheets/scss/*.scss' ); $times = array_map('filemtime', $files); arsort($times); $scss_time = current($times); // get timestamp of CSS file $css_file = TEMPLATES . 'stylesheets/site.css'; if (file_exists($css_file)) { $css_time = filemtime($css_file); } // if no CSS file or SCSS newer than CSS file... if( !isset($css_time) || $scss_time > $css_time ) { // ...compile a new CSS file... $scss = new Compiler(); $scss->setFormatter('Leafo\ScssPhp\Formatter\Compressed'); $scss->addImportPath( TEMPLATES . '/stylesheets/scss/' ); $scssIn = file_get_contents( TEMPLATES . '/stylesheets/scss/site.scss' ); $cssOut = $scss->compile($scssIn); file_put_contents( TEMPLATES . '/stylesheets/site.css', $cssOut ); // ...and return the path with the SCSS timestamp... return '/site/templates/stylesheets/site.' . $scss_time . '.css'; } else { // ...else return the path with the existing CSS timestamp return '/site/templates/stylesheets/site.' . $css_time . '.css'; } } FYI... "TEMPLATES" is a constant I defined elsewhere that holds the path to the PW templates folder. I use a single SCSS file "site.scss" that imports the other SCSS files. The compiled file is saved as "site.css", but for cachebusting purposes I include the modified time as part of the file basename in the returned URL, then use a rewrite rule in htaccess to resolve the URL to the actual filename. An alternative would be to append a query string with the file modified time, e.g. "site.css?1472438137"

Bumping this because it is really frustrating trying to follow older forum links. @Pete, is there anything that can be done about this? Thanks.

I think there might be still better places to ask. Table is a Pro field with it's own dedicated support sub-forum. And the feature you are describing is not a feature of Hanna Code but rather a feature of the Hanna Code Helper module.

Strange that it isn't working for you. Line breaks work fine in CKEditor for me, even with ACF and HTML Purifier on and without having to add "br" to Extra Allowed Content. Can you test on another PW installation to see if line breaks are working there? Also, are you entering line breaks in CKEditor using Shift+Enter or are you pasting in source code?

Hi there fellow kiwi Check out the Page List Show Page Id module - it's very simple so it's easy to modify to include whatever information you want in the page label. You can add some custom CSS to hide/style the added info: public function init() { if($this->user->isSuperuser()){ $this->addHookAfter('ProcessPageListRender::getPageLabel', $this, 'addPageIdLabel'); // add stylesheet $this->config->styles->add($this->config->urls->PageListShowPageId . "PageListShowPageId.css"); } }

@kixe The name of the repeater page doesn't come into the code I posted. This line... $pid = filter_var($this->name, FILTER_SANITIZE_NUMBER_INT); // get repeater page id from inputfield name ...gets the ID of the repeater page from the inputfield name - in the context of "Custom PHP code to find selectable pages " $this is the Page inputfield. The inputfield name includes the repeater page ID due to this: https://github.com/ryancramerdesign/ProcessWire/blob/devns/wire/modules/Fieldtype/FieldtypeRepeater/InputfieldRepeater.module#L219 But thinking some more, the base inputfield name itself could include integers so this would be better: $pid = filter_var(strrchr($this->name, "_"), FILTER_SANITIZE_NUMBER_INT); // get repeater page id from inputfield name The whole idea is pretty hacky, but just trying to work around what is available in "Custom PHP code to find selectable pages".

ProcessPageSearch is mentioned in the stack trace. Maybe take a look at the module config settings and see if anything is out of the ordinary. Screenshot of what I believe are the defaults:

I had a crack at this and it seems the answer is "yes". Here is example code you could use in the ""Custom PHP code to find selectable pages" for Page field 2: $pid = filter_var($this->name, FILTER_SANITIZE_NUMBER_INT); // get repeater page id from inputfield name $p = $pages->get($pid); // get repeater page if($p->id) { $parent = $p->page_field_1; // get value of first page field if($parent->id) { return $parent->children(); // return children of selected page } } But the bad news is that dependent Page fields only auto-refresh when using "Custom selector to find selectable pages" and not when using "Custom PHP code to find selectable pages". So you would need to save the page after selecting a value in Page field 1, which kinda sucks.

Off topic: @Pete, can you please check your private messages. Thanks.

While we're imagining how this group field might work, my two cents is that I don't think a limited repeater is the way to go. One likely use case for a group field is for SEO fields that would be added to nearly every template, so using a repeater-based group field would effectively double the number of pages in your site. I know that pages are designed to scale up nearly indefinitely but adding all these extra pages just seems unnecessary when there will only be one group field per page. The way I would like to see it is that the individual fields within the group are added directly to the template like normal fields are, but they would have a property that identifies them as belonging to a group. Having such a property would allow: The group field to appear in the template field list as a single item, so it's easy to move the grouped fields as one. Likewise it could be added to / removed from a template like a single field via the API. The group field settings would allow adding/removing/sorting fields to the group "pseudo-template" - as per a Repeater field, but a normal PW template would not be involved. This would require core changes of course, so would only happen if @ryan can see the value in having a group field in PW.

The minimum requirements feature was introduced in 3.0.22 and is configurable for the field: https://processwire.com/blog/posts/upgrades-optimizations-pw-3.0.22/#major-enhancements-to-our-password-field

Maybe your new password does not meet the minimum security requirements for the field? Not sure if that could cause a timeout - you'd think there would be some error notice.

That kind of syntax works fine for me. Try the same selector outside of Paginator to isolate where the problem lies.