BitPoet

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.

That probably included site/config.php, where the database credentials are stored. Your server will likely have different credentials than your local dev machine.

It should be $config->paths->assets, not $urls->assets, since you're passing a storage path on the server as the destination path, not a web link. Your code doesn't inspect $img1->getErrors(), even though the comment mentions it before checking $imgs.

Not sure if there's a way to include it directly, but FEEL creates links that open the page editor in a lightbox and reloads the page after saving. You can invoke it with mode = "page-add" to create new pages. If you have the FormBuilder pro module, you can create forms that are saved directly to pages and use most of the input fields available in the backend.

You could create a template and page to output the settings page image and specify that URL in the theme setting. Simplification: if your settings page doesn't have a PHP template yet, you could use that one, or you could extend the existing one. With url segments, you could even pull different stuff from it (logo image, icons, disclaimer, ...). Code for settings template: <?php namespace ProcessWire; if($input->urlSegment(1) === 'logo') { wireSendFile($page->logoimage->filename, [ 'exit' => true ]); } Then just put /path/to/settings/page/logo/ into the logo image file field.

The question is: is $event->return already null when your hook is entered? If yes, the problem happens earlier.

The quickest way would be to hook $page->editable($field). An raw example for site/ready.php, you'd have to extend it to match your role/templates/fields: wire()->addHookAfter("Page::editable", function(HookEvent $event) { if(!$event->return) return; $fieldName = $event->arguments(0); if(!$fieldName) return; $page = $event->object; if(! $event->user->hasRole('your-limited-editor-role')) return; if($page->template->name !== 'your-editable-template') $event->return = false; if($fieldName !== 'your-editable-field') $event->return = false; });