BitPoet

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.

Yes, Mr. BitPoet is around ? Glad to hear you like my module. As a quick & dirty workaround, you could insert a short check for your PageMjmlToHtml template/page in the addScripts function in FormBuilderMultiplier.module after $page is assigned: // If you want to prevent inclusion of the script for all pages with a certain template if($page->template->name === "PageMjmlToHmtl") return; // Or for a certain page id if($page->id === 19389) return; It makes sense to avoid including the script in every page that is rendered. I'm going to add a more selective mechanism there.

This also might be a red herring. The known fact is that either the $page parameter passed to isDeleteable() or the return of $this->wire()->page is null, and it might be the latter. From a gut feeling, this seems like an awful lot of action for a constructor, and it might make sense that the PageAccountPage is not fully wired with all variables before the constructor has finished. So I'd try moving the API logic out of the constructor and perhaps put it into ___loaded.

Not out of the box, but the commercial ProDrafts module provides just that.

My understanding is that the toolbar defaults are just the settings that get pulled in when you create a field. Once you edit a field's settings, it saves the toolbar config to the database and pulls it from there from then on. If you however prefix your settings with "replace_", "add_" or "remove_", it will still influence the field's behavior. So you should be able to e.g. put { "add_toolbar": "removeformat" } into the " Default setting overrides JSON text" field in the module settings or into your site/modules defaults.php, and the removeformat button gets added to all fields.

Maybw reverse the order, add a URL hook for /preview/(queryparameter)/.* and rewrite/redirect from there?

Hey there, born out of a personal need I've implement a lightweight version of @Robin S' Hanna Code Dialog module for TinyMCE. In a bout of creativity, I've named it HannaCodeDialogTiny This module is still in alpha state and needs some extensive testing. If you encounter any problems, please open an issue on GitHub. It has no select options, descriptions or cheat sheets (yet), and it doesn't cope well with nested Hanna Codes. What it does have is the Insert Hanna Code dropdown in the TinyMCE menu bar with dialog-based insertion, non-editable Hanna Codes in the editor, double click on existing codes for editing in a dialog. Hanna Codes are also highlighted, and you can drag and drop them around. The dropdown: Double click on any highlighted Hanna Code: Fill in your values: The Hanna Code has been changed: Have fun!

Not sure if that's easily possible without duplicating a lot of functionality from FormBuilderProcessor. As far as I can see, most methods involved in sending the emails are protected. Maybe the question should be asked in the FormBuilder support forum.

$form->children should give you the (structured) fields. If you want the returned list flattened, you can call $form->getChildrenFlat().

If you expand the page tree in the parent select, you should be able to click "unselect" next to the "works" page.

Sorry for that, seems the last commit was incomplete. Version 0.0.4 is on GitHub now and was tested with 3.0.229.

Do you have autojoin enabled for all/many fields on that template?

@Boost: Not out of the box, but you might be able to accomplish that with Dynamic Options and Select Images. I haven't tried it myself, though. @kongondo's commercial Media Manager module comes with its own Fieldtype+Inputfield for that purpose, so it may be worth a look.

No problem, $config->userAuthSalt is created when you install PW and stays unchanged. So it only needs to be copied along with the database the first time you import it.

Most of the contents in site/assets are created on the fly like caches, compiled template files and log files, and therefore don't need to be transferred. The exception are page files (file and image fields), which live under site/assets/files, so you need to copy that directory too. The things that need to be copied to move a complete site to another server are site/templates site/modules site/assets/files [*] site/classes (if the site uses custom page classes) site/init.php (if used) site/ready.php (if used) site/finished.php (if used) Then any settings in site/config.php need to be adapted in the target site (including $config->userAuthSalt, which needs to match the database contents) sites/assets/cache should be emptied [*] If you've only done a visual overhaul to an existing site without changing any contents, you don't need to copy the files directory. If you don't have any content on the target site you need to preserve, you can of course also copy the whole site directory, empty the site/assets/cache directory and adapt the settings in site/config.php. In that case, you just need to pay attention that directory permissions under site/assets are correct so the webserver user has write permissions. That last point is often overlooked when uploading stuff using (s)ftp or zip files.