BitPoet

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 ?

It's a dependency of php-saml. I haven't looked to deeply into the why and where there, but it's on my radar. The php-saml docs are still a bit of a mix of old and new from versions 2, 3 and 4, so I'll have to dig into the code to see if it's really still needed.

Sooner or later, everybody gets hit by the dreaded "can't we integrate this with [Azure|Google|Facebook|whatever|...]?" question. Lately, those have more or less assaulted me, and I've been looking for a clean-cut solution to link my PW instances up to a big Identity Provider. There is already the SamlAuth module in the module repository, but it has not been updated in a while and it's not as "graphical" as I'd like it to be - I want to be able to take long holidays away from cellphone reception while our IdP's certificate might expire. So I started wiring things up from scratch (as much as "building a PW UI and endpoints around php-saml) can be called "from scratch". So I've been starting to build: PoetSaml2 A SAML2 Service Provider for the ProcessWire CMS/CMF The module is still very alpha, rough around the edges and lacking a bunch of features I consider essential for long-term production use. Still, I decided to get the word out there early, maybe find even find some daring early adopters willing to restore a backup or two of their PW instance in case things go wrong, and also perhaps get some feedback about use cases and requirements I am not aware of. My SAML2 experience so far is limited to an enterprise environment with only Azure / Entra Id and SamlTest.id. It uses OneLogin's php-saml library for the hard work. The necessary SSO endpoints are realized with ProcessWire's URL hooks. Requirements ProcessWire >= 3.0.218 FieldtypeOptions FieldtypeRepeater PHP-OpenSSL Compatibility Basic compatibility has been verified with both Entra Id and SamlTest, meaning I could initiate successful logins into ProcessWire both from PW itself and from the Identity Provider. Screenshots SAML2 login button on the admin login form: PoetSaml2 comes with an admin page that lists all configured profiles and gives you quick links for adding and deleting profiles, lets you download your metadata file so you can upload it to your Identity Provider and even lets you backup profiles to a file. Uses ProcessPagesExportImport to import backup files. The profile configuration is a regular page edit screen. There are sections for the local endpoint (SP Configuration) and for the Identity Provider (IdP Configuration). You can set a redirect URL or even role specific URLs so PW knows where to take you if you initiate a login on the IdP side. Fine grained login permission, redirect URL discovery and even user creation based on SAML Claims can be realized through hooks. A checkbox lets you create a self-signed SP certificate. You can import your IdP's metadata.xml from a file or URL instead of having to copy & paste the URLs and certificate (thanks to php-saml's metadata parser). A lot of it is already documented to some extent in the README file on GitHub.

Ah, should have mentioned that. wireRenderFile returns the rendered content, so you need to echo it or use <?= wireRenderFile(...) ?>.

Give wireRenderFile a try instead of wireIncludeFile.

HannaCodeDialogTiny is now in the module directory.

Thank you! The current use case is pretty technical, though I can't go too much into details. You could call it a visual data mapping helper. I'm filling the options dynamically through a hook, with the options depending on other settings in the pages. But I'm open for more ideas how to use it.

FieldtypeListLinks If somehow found myself needing a means to associate items between two lists, and pages this time weren't the answer. So I started to develop this little Fieldtype/Inputfield. It lets you define two lists (let's call them "left" and "right") and declare a mapping between those. 1. Create your field and add options for the "left" and "right" select: 2. Set your labels and how many items it should show: 3. Edit your page and assign items: The module is still very much experimental and the API subject to change. However, I wanted to share what I have and maybe get some ideas and feedback before things get wired too tightly. The module and a little more documentation can be found in its GitHub repo.

As most times when it comes to ProcessWire, there's about a million ways to do it. I'm curious why Textarea / Textformatter didn't work. Did you have HTML entity encoder enabled on the fields? A very handy tool for embedding code which you normally wouldn't want editors to enter directly is Hanna Codes. You'd define and insert a tag like [[jobs]] (or [[job number="I002-1350-6"]] if you need to pass on variable parameters) into your field (could be Textarea, CKEditor or TinyMCE) and activate TextformatterHannaCode in the field's configuration. (This would also give you the chance to try out my module Hanna Code Dialog for TinyMCE). You could, of course, also create an individual template with the JS code, or extend your existing template with a checkbox (plus any text field for parameters to the JS) and have your PHP template conditionally render the script tags. It's possible to allow the direct insertion of script tags in CKEditor and TinyMCE, but I consider that a door better left closed for security reasons.

I just saw that there's already an open issue from June for that problem. Maybe you can chime in there.

Maybe a namespacing / file compiler issue? Is site/assets/cache/FileCompiler writable? Are there any stale files in there?

I'm assuming that PageMjmlToHml is a template, right? In that case, you can try the latest dev release 0.0.11. It has an option to exclude certain templates from script tag injection in the module settings.