BitPoet

Did you activate page numbers for your template?

To create a new field, you need to select a Fieldtype, not an Inputfield. Fieldtypes often have a matching Inputfield, but some support different Inputfields to faciliate the input. The Fieldtype is the part that takes care of storing and loading the data for the field, while the Inputfield provides the UI for entering that data. In the case of InputfieldTextTags, it doesn't have a matching FieldtypeTextTags, but rather complements the existing Fieldtypes FieldtypeText, FieldtypePage and FieldtypeOptions. So you need to create one of those and then, when you configure the field, choose "Text Tags" as the Inputfield of choice. Once you save it, you will see the configuration options specific to InputfieldTextTags.

Does that happen with the regular backend login or some frontend login mechanism? In the later case, is the login done with LoginRegister?

Sometimes, you want to search a text field by the length of its content. FieldtypeText doesn't provide this functionality (yet). It's possible to add the necessary SQL to a query by hooking into PageFinder::getQuery like @bernhard pointed out here, but that's of course not really straight forward. There's also an open feature request for FieldtypeText in processwire-requests. FieldtypeTextWithLength is an extension of FieldtypeText, so you can switch your field's type between the two without loosing any information. After switching your field to "Text with .length Selector", you can search by the (character, not bytes!) length of the content: $pagesWithShortHeadlines = $pages->find('headline.length<10'); You will also find a new "Length" subfield when using Pages -> Find in the PW backend:

I brushed up my snippet with a ___getSelectorInfo method, so Lister & Co. can offer Length as a numeric subfield and put the module on GitHub.

Thanks! Appreciated! ? about it, in times of utf8(mb4) one might want to use CHAR_LENGTH instead of LENGTH. The first one counts the code points, i.e. visible characters, while the latter returns the bytes. LENGTH('?') is 4.

A short&quick&dirty module that adds .length (switching back and forth between regular Text fields and "Text with .length Selector" should not cause any troubles): <?php namespace ProcessWire; class FieldtypeTextWithLength extends FieldtypeText { public static function getModuleInfo() { return [ 'title' => __('Text with .length Selector', __FILE__), 'summary' => __('Like FieldtypeText, but with a subfield selector .length for string length comparison', __FILE__), 'version' => '0.0.1' ]; } public function getMatchQuery($query, $table, $subfield, $operator, $value) { $database = $this->wire("database"); if($subfield === 'length') { $table = $database->escapeTable($table); $value = $database->escapeStr($value); $query->where("LENGTH({$table}.data){$operator}$value"); } else { parent::getMatchQuery($query, $table, $subfield, $operator, $value); } return $query; } }

The problem I have is that the focus event isn't triggered for inline datepickers, which are especially handy if one wants to avoid invalid manual input. I've nevertheless thrown together a small POC module I've called DatePickerExclusions that works with focus and button click options. It still needs an option for time windows.

PageImage::removeVariations takes an associative array of options as its argument, which in turn is passed on to PageImageVariations::remove and PageImageVariations::find. The docs for the latter say (irrelevant parts snipped): /** * @param array $options Optional, one or more options in an associative array of the following: * - `width` (int): only variations with given width will be returned * - `height` (int): only variations with given height will be returned * - `width>=` (int): only variations with width greater than or equal to given will be returned * - `height>=` (int): only variations with height greater than or equal to given will be returned * - `width<=` (int): only variations with width less than or equal to given will be returned * - `height<=` (int): only variations with height less than or equal to given will be returned * - `suffix` (string): only variations having the given suffix will be returned * - `suffixes` (array): only variations having one of the given suffixes will be returned * - `noSuffix` (string): exclude variations having this suffix * - `noSuffixes` (array): exclude variations having any of these suffixes * - `name` (string): only variations containing this text in filename will be returned (case insensitive) * - `noName` (string): only variations NOT containing this text in filename will be returned (case insensitive) * - `regexName` (string): only variations that match this PCRE regex will be returned */ So ["width" => "201"] should work (untested though).

It does if you pass a filter function to the beforeShowDay option, though I haven't found a way to set that without modifying InputfieldDatetime.js.

This is great! Just a tiny nitpick: I'd swap around the logic for "Don't allow selection in both directions" and get rid of the "Don't", or maybe change it to "Disallow". It's a very cultural and regional thing whether questions with a negation get answered with a yes or no to confirm then, and it's bitten me in the backside myself when I rolled out an app with such a toggle to our international employees.

Glad to hear, thanks for the feedback! I have pushed the change to the main branch.

Well, best practice would be to make sure that your api request times out before your PHP script does (WireHttp::setTimeout / curl_setopt(CURLOPT_TIMEOUT, xx) / curl_setopt(CURLOPT_CONNECTTIMEOUT, yy) vs. max_execution_time & site_time_limit). You can of course set the header through .htaccess instead of PHP (mod_headers must be enabled of course): Header always set Access-Control-Allow-Origin: "*" The keyword "always" also sends the header with redirects.

It's hard to say where this comes from. The reason for the message is that there is a MATCH sql query somewhere that tries to match one or more columns while there isn't a fulltext index that contains the exact same set of columns. I'd try to find out which query or selector causes it with the help of TracyDebugger. It has tabs for PDO Queries and Selector Queries. That should give you an idea which table and column(s) the error is about.

Yes, that's right. The replacement happens only for defaults.json, any additional settings from JSON text or file are merged afterwards.

These are read from the module configuration of ProcessPageEditImageSelect ("Page Edit Image" in Modules -> Configure) in InputfieldTinyMCESettings:getAlignClasses() and applied in InputfieldTinyMCESettings::getDefaults().

getRandom() by default returns a single item (Repeater item in your case). So the foreach tries to iterate over that single Repeater item's properties instead of an array of items. There are three solutions: Drop the foreach and just do "$item = $page->repeater_headline_movie_text->getRandom();" (Might error out if the repeater is empty) Set the $alwaysArray argument for getRandom: "foreach ($page->repeater_headline_movie_text->getRandom(1, true) as $item)" Or use "$page->repeater_headline_movie_text->findRandom(1)" instead, which always returns a RepeaterPageArray

Another update: 0.0.35 is on GitHub supports (still experimental) updating of user profile fields with data supplied by the IdP. User updating can be enabled per profile, and the claims/fields can be mapped individually. The update method is also hookable, so you can leave the mapping empty and perform the deed in your hook to PoetSaml2::updateUserData. This introduces a dependency on my new FieldtypeListLinks module, which got a few test runs that way ?

page-template controls whether you can change a page's template. What you're looking for is probably page-move.

v0.0.32 is out with the following additions: "Configurations" have been renamed to "Profiles" You can now fine tune your settings with all the advanced options php-saml supports (besides contact information in the metadata), e.g. encryption and signing settings, algorithms, required fields / attributes or ADFS compatiblity The import of backup files is now possible "Log in with ..." Buttons on the admin login form can be switched on and off for each SP Profile Error messages can be customized in PoetSaml2 module settings I also added a bunch of hookable methods: canLogin( $user ) Hook for extra checks whether a user is allowed to log in getLocalUser( $nameId ) Hookable user lookup method. Gets the IdP-supplied nameId and looks up the user with that email address. You can implement your own lookup logic by hooking this function and returning either a User object or boolean FALSE. getLoginRedirectFor( $profile, $user ) Hookable method that determines the login success redirect URL for the logged in user. processSamlUserdata( $userdata, $friendlyUserdata ) Hookable method for actions based on the SAML2 claims returned by the IdP. You could hook into this method to create users on the fly.

It should be enough to hook "ProcessPageListRender::getPageLabel", no secondary hook necessary. $wire->addHookAfter('ProcessPageListRender::getPageLabel', function(HookEvent $event) { $page = $event->arguments(0); if($page->template == 'event') { $suffix = $page->datum; $event->return .= ", {$suffix}"; } });

Good call! Its existence had completely slipped my mind.

Thanks for the feedback! I tested things with 4.1 and just committed the change to GitHub. If you don't mind me asking: which IdPs have you had success with, and did you have to dabble with advanced settings to get things up and running? (If you don't want to or can't answer that, I'll understand).

As @bernhardwrote, it is pretty doable. In addition to the markup field, I'd also add two hidden fields to the template to: store the parsed data (textarea) indicate we need to make a choice (checkbox) In a Pages::saveReady hook, I'd check if the file field has changed. If yes, parse the contents, and either: a) assign the page fields if there is only one race present; b) or fill the textarea with the parsed data (probably json encoded) and set needsChoice to 1. If the file field hasn't changed, needsChoice is 1 and a choice was sent, wake up the data from the textarea, pick the chosen race and fill your fields. Then set needsChoice to 0. In a ProcessPageEdit::buildForm hook, I'd check if needsSelection is set, and if yes, I'd fill the markup field with the race selection radio input. (Instead of the markup field, one could even use a regular InputfieldRadios and insert that into the form). It also has the charm that you can put "needsChoice!=1" in your selectors to see all unfinished multi-race pages. Two hooks, three fields, done.

So, after jumping through the code, I found that v4 includes xmlseclibs through composer (2 and 3 ship an integrated, outdated version). The code in the xmlseclibs GitHub repo doesn't have any references to mcrypt left. So it seems I can hard wire v4 (only dropping backwards compatibility with eol PHP releases) and be done with mcrypt ?