Robin S

Sounds like the Multisite module could be a contender: https://github.com/somatonic/Multisite/ And you'll want to read the support thread to get an idea of the current status of the module:

Thanks for for the write-up of how you got this working. I've tried many different AMP stacks for Windows over the years and Laragon is the best. Among the useful features is a built-in mail sender: I recommend it to any Windows user - you'll be sending email from your local dev environment within minutes rather than days. ?

The hook code definitely needs to be in /site/ready.php or /site/init.php. It won't work in your template-prepended _init.php file - the page is already rendering by the time that code executes.

To see all the places where a particular method is called by the core you would need to search the core code. In the case of Fieldtype::getInputfield the most significant places are in Field::getInputfield, which returns the inputfield according to the fieldtype of that field, which in turn is called by Fieldgroup::getPageInputfields, which loops through all the fields that belong to a fieldgroup (you can think of a fieldgroup as being sort of the same as the template) to get and populate their inputfields so they can be displayed in Page Edit (for instance). But you probably don't need to spend time working through all of that in order to successfully create a Fieldtype module. An important thing to understand if you don't already is that your Fieldtype module extends the Fieldtype class. This is called Object Inheritance: http://php.net/manual/en/language.oop5.inheritance.php So all the methods in the Fieldtype class also belong to your module, and the code for those methods is what you see in Fieldtype.php unless you override the method by including it in your module. To illustrate with an example, we can see that Fieldtype::getBlankValue returns an empty string: https://github.com/processwire/processwire/blob/cbfe97de207e3166451f16865429c02c081791e8/wire/core/Fieldtype.php#L494 If we look at FieldtypeText we see that it doesn't include a getBlankValue() method - it doesn't need to because the getBlankValue() method of Fieldtype already returns the right value for a blank text field. But if we look at FieldtypeCheckbox we see it does include a getBlankValue() method - that's because an empty string isn't the right type of value for a blank (unchecked) checkbox, so it implements its own method to return 0.

The naming of the OR-groups is not correct. You only name OR-groups if there is more than one set of OR-groups and one group in each named set must match. Your selector here is saying that both (date<$start,date_end='') and (date<$start,date_end>=$start) must match which is impossible because these contradict each other. Wrong use of OR-group syntax with only one OR condition. Wrong use of pipe character. The pipe character can only go between field names in a selector clause... field_a|field_b~=foo ...or between values in a selector clause... field_a%=foo|bar

@Elchin, try: $results = $page->children("date<today, (date_end>today), (date_end=''), sort=-date, limit=12"); You can use "today" in place of your timestamp.

Should this have been $this->sanitizer->int() ? It would be awesome to be also able to pass a selector string to the method (e.g. "some_field%=value") but I guess it would get quite involved to translate that into SQL.

Here are links for a few different approaches to the general question: https://github.com/LostKobrakai/Paginator https://gist.github.com/somatonic/5420536 https://processwire.com/talk/topic/5558-adding-pagination-after-merging-two-pagearrays/?do=findComment&amp;comment=54122 And my own suggestion: // Find all the matches, but only find the IDs to reduce memory overhead $matchest = $pages->findIDs("title~=$q, template=BN-article|BN-infopage"); $matchest_str = implode('|', $matchest); $matchesb = $pages->findIDs("body~=$q, template=BN-article|BN-infopage, id!=$matchest_str"); $match_ids = array_merge($matchest, $matchesb); // Define some pagination settings $items_per_page = 10; $start = ($input->pageNum - 1) * $items_per_page; $total = count($match_ids); // Get the IDs for this page of the pagination $item_ids = array_slice($match_ids, $start, $items_per_page); // Get the pages using the IDs $items = $pages->getById($item_ids); // Apply the pagination settings to the pager $items->setTotal($total); $items->setLimit($items_per_page); $items->setStart($start); // Output the items as needed foreach($items as $item) { echo "{$item->title}<br>"; } // Output the pager echo $items->renderPager();

The key thing is to make sure $matchesb does not contain any of the pages in $matchest - otherwise the order will not be what you expect when you join the PageArrays together. So you could use removeItems() as per my reply in the thread @szabesz linked to, or you could exclude the $matchest items in the selector for $matchesb: $matchest = $pages->find("title~=$q, template=BN-article|BN-infopage"); $matchesb = $pages->find("body~=$q, template=BN-article|BN-infopage, id!=$matchest"); $entries = $matchest->and($matchesb);

Try in incognito mode to make sure your browser is not caching old redirects. You could also use the "What other URLs redirect to this page?" section (introduced in PW 3.0.118) and/or the modules below to look for any circular redirects (if such a thing is possible with Page Path History). This second module needs the PagePaths module installed and also needs a variable name fixed as per a reply in the support topic.

Sure, I will keep an eye on the core and merge your PR as soon as Ryan adds support for it. It's actually not that much more comprehensive. ? The only additions are the macronised vowels (āēīōū), which is something I wanted for my New Zealand context because they are used in Maori. The difference is that the list includes uppercase versions of the characters. I simply took the character list from InputfieldPageName, added the macronised vowels, and ran it through mb_strtoupper(). Adding uppercase characters to InputfieldPageName wouldn't make sense because page names are forced to lowercase. I had in mind that this sanitizer could be used for broader purposes besides converting characters to ASCII. Using the character replacements from InputfieldPageName seemed like a good starting point (particularly given the question that gave rise to the module) but a person could configure all kinds of replacements to suit their needs. There could well be cases where these substitutions would not be wanted in InputfieldPageName.

These settings probably wouldn't be ideal for the purpose because they only account for lowercase replacements (page names must be lowercase). But it seemed like a good candidate for a new sanitizer method so I made a module where you can define character replacements in the config:

A community member raised a question and I thought a new sanitizer method for the purpose would be useful, hence... Sanitizer Transliterate Adds a transliterate method to $sanitizer that performs character replacements as defined in the module config. The default character replacements are based on the defaults from InputfieldPageName, but with uppercase characters included too. Usage Install the Sanitizer Transliterate module. Customise the character replacements in the module config as needed. Use the sanitizer on strings like so: $transliterated_string = $sanitizer->transliterate($string); https://github.com/Toutouwai/SanitizerTransliterate https://modules.processwire.com/modules/sanitizer-transliterate/

Another way this could be done is via the following "Selector string" for "Selectable pages" for the Categories field: template=category, has_parent=page.rootParent

I was able to see a difference with defaultGamma set to 0.5 versus 4. 0.5 4 But only for ImageSizerEngineGD (the PW default sizer engine). I don't see defaultGamma used anywhere inside ImageSizerEngineImagick. Maybe @horst can confirm if defaultGamma applies to ImageSizerEngineImagick or not.

@BitPoet, in case it helps, it seems that the relevant difference between a standard DateTime field and DateTimeAdvanced is that the standard field passes this test in Fieldtype.php for new pages... // if the value is the same as the default, then remove the field from the database because it's redundant if($value === $this->getBlankValue($page, $field)) return $this->deletePageField($page, $field); ...but DateTimeAdvanced does not, resulting in an empty datetime value being stored in the DB.

@BitPoet, thanks for the update, but sorry to report the issue with "default to today" remains for me with new pages. I tested with the dev branch of the module. Edit: I've just noticed that it doesn't make a difference if "default to today" is selected for the field - the issue occurs regardless. Not sure if this was always the case and I just failed to check this when I originally reported it. Database:

Related?

Awesome, I think that's a great plan. ?

Hi Margaret, Maybe you could attach or link to one of the original images that is exhibiting the problem to see if anyone else can reproduce the issue?

If you have a large number of images in the gallery it would be better not to load all the pages into memory only to display a portion of them with slice(). Better to use start and limit in your selector to get only the pages you will display. You could adapt the example given here:

Works for me too, but would depend on what $config->urls->root is (e.g. if developing in a subfolder?) If it's just MSN you are concerned about the simplest thing is to use the features built into MSN for just this purpose. Either then "xitem_tpl" option or a "getItemString" hook: // MSN hook for external_link template $nav->addHookAfter('getItemString', function($event) { $child = $event->arguments('page'); if($child->template == 'external_link') { $event->return = "<a href='{$child->link_url}' target='_blank'>$child->title</a>"; } });

Did you copy the .htaccess file? Does your server support mod_rewrite? It's a good idea when considering moving to new environment to first run the PW installer as this will check to see if the environment is compatible. If all good you can delete the installation and copy over your existing files and DB. Also see this: https://processwire.com/docs/start/install/troubleshooting/#the-homepage-works-but-nothing-else-does

The relative dates will come via WireDateTime::relativeTimeStr().

I can reproduce. Seems like a bug. Issue here: https://github.com/processwire/processwire-issues/issues/826