Leaderboard

ProcessWire 3.0.142 has a lot of updates but the biggest is the addition of custom fields support for file and image fields. In this post, we take a closer look and also outline all of the new features in the just-released FormBuilder v40— https://processwire.com/blog/posts/pw-3.0.142/

Last week I worked primarily on GitHub issues, and did some of that this week as well. Likely I'll be doing a lot of this in October. Thank you for all of your reports. While there's already a lot of commits on the dev branch, I'm going to wait till next week to bump the version, as I've got some stuff in progress that I want to get committed first (more on that below). Next week I'm releasing version 40 of FormBuilder that supports paginated forms, as well as forms within forms (not to mention some other minor additions). Basically, all the stuff that was covered in this video from a few weeks ago, plus a little more. I actually think it's ready right now, but as is often the case, I started writing instructions for using the new features today and thought of a couple minor tweaks that would be helpful along the way. So I'm going to apply those early next week, finish the instructions, test it all out again, and then release it... likely mid-week next week. For the ProcessWire core, one feature people have been asking for for quite awhile is the ability to specify custom fields with file and image fields. I've been working on that here quite a bit this week, and have the initial test cases working quite nicely! Unlike the Description and Tags fields that come as built-in options with file and image fields, the new option instead uses a subset of ProcessWire's Fieldtype and Inputfield modules to support this (note: it does not use pages like repeaters do). This gives you more flexibility in defining what you want and how you want it to look. Though there are some limitations of what kinds of fields you can use here, but I think you will like what it offers and how it works. For those that just need a description and/or tags, then of course those features will remain as they are. But for those that need something more for file/image fields, you are going to have a whole lot of new options in 3.0.142. Unless I run into any roadblocks in finishing development of this part, I'll have it ready by this time next week along with a blog post that outlines it in more detail.

In my version of this module I have changed so many things that it is almost unrecognizable, but I do see that I added: if($user) to the beginning on line 394 which should fix what you are seeing.

Behind the scenes, repeater entries are individual pages, so when you iterate over an entry (your second loop), you iterate over all the properties of the repeater page. You can see that if you change your code to: foreach ($child->Portrait_Repeater as $data) { $i = 1; foreach($data as $prop => $person_data){ $content .= $i.": $prop => ".$person_data."<br />"; $i++; } } The solution is to remove the inner loop and address the properties by name instead, like $person_data->email, $person_data->position etc.

Probably with setting the right flag. If I check both access toggle checkboxes and analyze it in Tracy, I see this: flags => "access access-api access-editor system-override (32992)" Here are all possible flags: https://github.com/processwire/processwire/blob/master/wire/core/Field.php#L52

Thank you all! I waited a few hours before pronouncing the verdict ^^ The problem was indeed the change of IP. I added this line in: /site/config.php $config->sessionFingerprint = 1; /* 1 or true: Fingerprint on default / recommended setting (currently 10). */ by $config->sessionFingerprint = 8; /* 8: Fingerprint only the useragent */ I was able to test this solution on all the sites I created. It works. Thx you to everyone !!!

To be honest... don't do it on a remote machine. Install Laragon, MAMP or something similar on your local machine and play around with ProcessWire. I personally prefer the blank profile but in your case the beginner profile shoud be perfect. Combined with the ProcessWire tutorials you will have a solid foundation for a perfect start in the world of ProcessWire. Depending on your skillset and experience with PHP and maybe other CMSs you could be ready to build your very first site in/with ProcessWire on Monday next week.

These threads discuss similar issues: While developing you might want to disable fingerprinting from within config.php - it's explained and discussed in the threads above. Another thing you can and might want to doublecheck: CDNs can be sometimes an issue as well; saw this with Cloudflare CDN a few times some browser extensions (privacy and adblock-related ones) can cause those issues as well Pi-Hole can be an issue too Operas built-in-VPN causes these conflicts/problems (especially in tools like Asana and Slack - and PW) And those things are just the few I remembered from similar situations I had to deal with on my own.

Update August 2022: There finally now is a native way of opening the correct file, if tracy throws an error. You have to use Jetbrains Toolbox for this to work. Go to tracy's 'Editor links' setting and in the input write this, and replace projectname with the PHPStorms project name: jetbrains://php-storm/navigate/reference?project={projectname}&path=%file:%line Also if you are using a folder structure, where the PW installation lies not in the root, then you want to modify the "Local root path" setting in Tracy. Here is an example of my settings: Original post from 2019 Tracy Debugger offers an Editor protocol handler link so you can jump directly to a file from a Tracy Debugger dump message. Unfortunately this does not work on Windows, as the URI protocol handler isn't implemented in the Windows version (see link). However, all IDEA products (IntelliJ, PHPStorm, etc.) provide a REST API from which you can open files. The syntax is http://localhost:63342/api/file//absolute/path/to/file.kt for absolute pathnames (please note the double backslash behind "file") and http://localhost:63342/api/file/relative/to/module/root/path/to/file.kt for relative filenames. To use this, you have to set up Tracy with the following parameter: http://localhost:63342/api/file/%file:%line:0 If you click on a link now in Tracy, PHPStorm will focus and ask for permission to open the file. ATTENTION: PHPStorm has to be opened and also your project has to be opened (so PHPStorm knows the root for relative path). This is a little bit cumbersome, but better than nothing. Ping @adrian to bring this to your attention.

This is the thread for the old version of RockMigrations wich is deprecated now and has been renamed to RockMigrations1 Here is the latest version of RockMigrations: -- Old post from 2019 -- https://github.com/baumrock/RockMigrations1 Quickstart First make sure you have backups of your database!! Install RockMigrations Create this ready.php <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => ['type' => 'text'], ], 'templates' => [ 'mytemplate' => [], ], ]); Open your PW Backend and you'll see the new field and new template! Now add the new field to the template: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => ['type' => 'text'], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title', 'myfield', ], ], ], ]); Reload your backend and inspect the template: Now let's add a label for our new field and make title+myfield 50% width: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); That's all the magic! You can easily lookup all necessary properties in Tracy Debugger: Let us add a Textformatter as an example! Add the textformatter via the PW backend (not via RM), save the field and inspect via Tracy: Now add this data to your migration: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', 'textformatters' => [ 'TextformatterEntities', ], ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); Ok maybe you noticed that migrations are now running on every request which may slow down your site a lot! RM2 will have a feature to automatically detect changes and fire migrations automatically. RM1 does not have this feature, but I've used a technique in all my projects that fires migrations on every modules refresh. Simply wrap the migration in a fireOnRefresh method call: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->fireOnRefresh(function() use($rm) { $rm->migrate([ 'fields' => [ 'myfield' => [ 'type' => 'text', 'label' => 'My Field Label', 'textformatters' => [ 'TextformatterEntities', ], ], ], 'templates' => [ 'mytemplate' => [ 'fields' => [ 'title' => ['columnWidth' => 50], 'myfield' => ['columnWidth' => 50], ], ], ], ]); }); How to remove things you created before you may ask? Use the declarative syntax: <?php /** @var RockMigrations1 $rm */ $rm = $this->wire('modules')->get('RockMigrations1'); $rm->fireOnRefresh(function() use($rm) { $rm->deleteField('myfield'); $rm->deleteTemplate('mytemplate'); }); Refresh your backend and everything is as it was before! PS: Make sure you have proper Intellisense support in your IDE to get instant help:

Yo Ryan and everyone, I don't use ProcessWire anymore for new stuff — the size and scope of the projects makes using a database nonsense — but there is one half internal system that happily chugs along, for 7 years now (I think? Maybe 8 years?) Latest page ID created was 38047 ? So, thank you for everything — mostly for keeping my job while "new system" isn't happening ?

Super so yeah now it works! So thank you all, For your great help! This is really nice for building one scroll pages. Then you could use diffrent template to create diffrent variations, when scrolling down. Here is the working code for those finding this in the future! $children = $pages->find('template=onecolumn|twocolumn, sort=sort'); foreach($children as $child) { echo $child->render();

THE SOLUTION IN THIS POST TURNS OUT NOT TO BE CORRECT - SEE THE NEXT POST I finally found a solution. I realised that, after a very long wait, apparently frozen browser windows were, at least sometimes, returning internal server errors. So I looked at the suggestions for error 500 in the PW readme and in the .htaccess file. The one that fixed it is in item 1 of .htaccess: uncomment Options +SymLinksifOwnerMatch and comment Options +FollowSymLinks. There are various things I'm not clear about, such as why this issue seemed to caused problems with database connections on log in, why it hasn't affected two other PW sites on the same cloud server (presumably there is some difference, such as this site being the Apache default), and so on, but the solution might be useful to others.

is that the exact code you're using? render is a function, so it should be render()

@Atlasfreeman Do you actually have template files for those templates? How complex are those pages? Maybe you can just as well output the fields of those pages instead of using render(). Some more infos and options: https://processwire.com/talk/topic/13958-help-understanding-render-and-rendervalue/ https://processwire.com/talk/topic/12228-render-options-documentation/

Moderators Note: Form Builder has a specialized VIP Support Forum where you are more likely to get help and support for your issues with Form Builder. If you don't have access to this area, please send a PM to @ryan (the module's creator and maintainer).

Do you develop on your local machine or on a remote server? Maybe your problem is similar to this one - if you are working on a remote server: And you have to disable - for the time you update and develop - some security features aka fingerprinting.

I agree. Could you open an issue on GitHub? Should be easy to integrate this in the next release. @tires Not in the current version. Technically there is a way, but it feels hacky. You'd need hook after SeoMaestro::___renderSeoDataValue() and then entity decode and encode the value again. See: https://github.com/wanze/SeoMaestro#___renderseodatavalue Cheers

I can confirm that I’ve also reached exactly the same conclusion this morning. Using only the useragent seems to keep the constant disconnections away.

Well... to be honest... your screenshot doesn't make sense. On the left is your user's home folder. Which isn't meant to be a home for a website at all. Therefore all .php files in there are totally wrong there, while .xsession and similar files are needed there there. On the right is probably your hosting/server. But there is everything mixed up. Again. If that that folder is your domains document_root than there are some folders missing and some files at totally wrong places. That's how a ProcessWire folder in the document_root of a domain should look like. At least these are the files I would assume there.

@Chris B there are a couple of ways. 1. The most secure... use a hook to add the value to the FB after submit (or whatever hook works for you best). See https://processwire.com/store/form-builder/hooks/ 2. In your template, use the options array to populate the page id into a hidden field that's rendered but not displayed, eg: $forms->embed ('my-form', array('postulate_job' => $page->id));

@bee8bit The are ways to call it from the API https://processwire.com/api/ref/tfa/ I have no idea how your custom login form works but I assume your going to need to do some modifications. it will need to check that TFA is active, build the form and process the TFA request. Or if its something another user has created maybe just pester them a lot to update their module to support the TFA class that has been out for like a year already

Next Feedback ? After hit the button Delete library i get this error: Error Call to undefined function _(), did you mean processwire\_n()? fix it► search► File: .../ProcessMediaLibraries.module:133 123: $frm->append($hidden); 124: 125: $hidden = $this->modules->get("InputfieldHidden"); 126: $hidden->attr('name', 'modal'); 127: $hidden->attr('value', 1); 128: $frm->append($hidden); 129: 130: $f = $this->modules->get("InputfieldMarkup"); 131: $f->attr('id+name', 'trash_msg'); 132: $f->label = $this->_("Procceed?"); 133: $f->attr('value', sprintf(_("Really move library <strong>%s / %s</strong> into the trash bin?"), implode(' / ', $page->parents->explode('title')), $title)); 134: $f->description = sprintf(_("Library contains %d images and %d files"), $page->media_images, $page->media_files); 135: $f->notes = $this->_("Any files/images contained in this library will be deleted."); 136: $frm->append($f);

@teppo Quick follow-up on your merge request, unless you'd like me to take care of it? ?

Just stumbled across this older post and need to make an addition to @ryans post: You need to add: ... // make this to give MarkupPagerNav what it needs $a = new PageArray(); $a->setDuplicateChecking(false); // <-- add this line! ... just below the PageArray creation - otherwise this won't work, as you will always having only 1 item in the final PageArray.

Hi @Christophe Badoux It sound like a permission or maybe a server cache issue, but we need more information about your hosting. Things to check : browser cache disk space available value of session.save_path and permission of this value permission of site/assets server caching (depending on the server setup, could be NGINX, Squid, Varnish, Memcached, etc..) I bet on the last one. Oh and Welcome to the forum ?

Place the ready.php into /site/ and it should work. /site/ready.php

@gmclelland Must've been something wrong with the export of the db from my local. I renamed MarkupSEO and then it threw the same error for FormBuilder. Renamed it too and then the admin page came up but using the default theme and it was reporting that modules had been downgraded to earlier versions. Ran another export/import and it's all fine now. ?

@Wanze Hm, I wouldn't like to see german umlauts encoded and it shouldn't be necessary, if we use UTF-8. In many cases it should be sufficient to use htmlspecialchars with ENT_QUOTES here. If you see a need to use htmlentities instead, you could flag with ENT_XML1, to avoid encoding äöüß.

echo $page->render; Just take into account that this will render the header and footer if you have included them on the child pages templates.

Are all your modules up to date and compatible with ProcessWire 3.x? You can clear the compiled files cache - can be found at the bottom of your module page - and try again.

Added support for renaming templates (and related fieldgroups): https://github.com/BernhardBaumrock/RockMigrations/commit/fd465dc27e4f2e3982ed6669da0478df8addfd90 $newTemplate = $rm->renameTemplate('oldtemplate', 'newtemplate');

Just added support for Fieldsets. They work a little differently than normal fields, because they need a corresponding _END field. Now if you create fieldsets in your migration those fields will automatically be created and automatically be added to a template: Upgrade: // create tab and add it to invoice template $f = $rm->createField('dunningtab', 'FieldtypeFieldsetTabOpen', [ 'label' => 'Mahnwesen', ]); $rm->addFieldToTemplate($f, 'invoice'); // create sample field and add it to this tab $f = $rm->createField('invoiceinfo', 'FieldtypeRockMarkup2', [ 'label' => 'Info zur Rechnung', ]); // add it after the field "dunningtab", before the field "dunningtab_END" $rm->addFieldToTemplate($f, 'invoice', 'dunningtab'); Downgrade: $rm->deleteField('dunningtab'); $rm->deleteField('invoiceinfo'); This will remove your field from all templates where it is used and also remove the corresponding closing field ?

@CarloC try { echo $modules->get('LoginRegister')->execute(); } catch (WireException $e) { echo "Too many failed login attempts.<br>" . $e->getMessage(); }

I think there is still an outstanding bug (https://github.com/ryancramerdesign/ProcessWire/issues/1803) with images on user pages - it seems like outputformatting is always off which results in the need for first(), even when maxFiles is set to 1. Try this: $user_image->first()->url