Leaderboard

I'm really in love with FormBuilder, but the one thing missing to match all my end users' expectations were repeatable field groups. Think repeaters, in ProcessWire terms. Our primary application of PW is our corporate intranet, so "lines" of fields are quite common in the forms I build. We have all kinds of request forms where the information for a varying number of colleagues needs to be entered (from meal order to flight booking request) and where it is simply impractical to send a form for each, and I don't want to clutter my forms with multiple instances of fields that may only get used ten percent of the time. That's why I started to build FormBuilderMultiplier (link to GitHub). What it does: Adds an option to make a regular Fieldgroup repeatable Lets you limit the number of instances of a Fieldgroup on the form Adds an "Add row" button the form that adds another instance of the Fieldgroup's fields Adds a counter suffix at the end of every affected field's label Stores the entered values just like regular fields Makes the entered values available in preview and email notifications Supports most text based fields, textareas and selects (really, I haven't had enough time to test all the available choices yet) What it doesn't do (yet): Support saving to ProcessWire pages (i.e. real Repeaters) I haven't tested all the validation stuff, Date/Time inputs etc. yet, but since I'm utterly swamped with other stuff at work, I didn't want to wait until I have it polished. Any feedback is welcome. There might also be some issues with different output frameworks that I haven't encountered yet. The forms I work with mostly use UIKit. Status: Still alpha, so test well before using it in the field. Known issues: When rows are added, the form's iframe needs to be resized, which isn't completely clean yet. How it works: The Fieldgroup settings are added through regular hooks, as is the logic that adds the necessary field copies for processing the form and displaying previews. "Multiplied" field instances are suffixed with _NUM, where NUM is an incremental integer starting from 1. So if you have add two fields named "surname" and "givenname" to a fieldgroup and check the "multiply" checkbox, the form will initially have "surname_1" and "givenname_1" field (I'm still considering changing that to make the risk to shoot oneself into the foot by having a regular "surname_1" field somewhere else in the form less likely). When a "row" is added, the first row is cloned through JS and the counter in the fields' IDs, names and "for" attributes as well as the counter in the label are incremented before appending the copies to the Fieldset container in the form. To keep backend and frontend in sync, a hidden field named [name of the fieldset]__multiplier_rows is added to the form. Both the backend and the frontend script use this to store and retrieve the number of "rows". ToDo: Naturally, add the option to store the data in real repeaters when saving to pages. Do a lot of testing (and likely fixing). Make a few things (like the "Add row" button label etc.) configurable in field(set) context. Add a smooth API to retrieve the multiplied values as WireArrays. The mandatory moving screenshot:

Hello all ? First I would like to say PW is a wonderful CMS and a very helpful and friendly community, which is rare these days. I was doing web dev as a hobby while I cared for elderly parents but now it's time to move forward and get serious ( it's getting cold here so I'll be trapped indoors lol ). A while back I created a full featured built in forum system for Evolution CMS which I could rewrite for PW if there is enough interest, although it would have to be a paid module. At the moment I only have a working version on my local wamp, I can put it online next week and send anyone interested a link via PM. What do ya'll think? I removed the old screenshots as they are not relevant any more ?

Nearly ten months later, FormBuilder is happily at work here and I am testing a home-brewed module that implements repeating fieldsets for FB forms [TM]. I have named it FormBuilderMultiplier and put it on GitHub in case anybody is interested.

i just use a function to output the code from realfavicongenerator function favicons($options = []) { $defaults = array( 'appleColor' => '#4d9db4', 'msColor' => '#da532c', 'themeColor' => '#ffffff', 'path' => null ); $options = array_merge($defaults, $options); $folder = 'site/templates/favicons/'; if($options['path']) $folder = $options['path']; $folderUrl = wire('config')->urls->root . $folder; $filePath = wire('config')->paths->root . $folder; if(!is_dir($filePath)) return; $out = <<<OUT <link rel="apple-touch-icon" sizes="180x180" href="{$folderUrl}apple-touch-icon.png"> <link rel="icon" type="image/png" href="{$folderUrl}favicon-32x32.png" sizes="32x32"> <link rel="icon" type="image/png" href="{$folderUrl}favicon-16x16.png" sizes="16x16"> <link rel="mask-icon" href="{$folderUrl}safari-pinned-tab.svg" color="{$options['appleColor']}"> <link rel="shortcut icon" href="{$folderUrl}favicon.ico"> <link rel="manifest" href="{$folderUrl}site.webmanifest"> <meta name="msapplication-config" content="{$folderUrl}browserconfig.xml"> <meta name="theme-color" content="{$options['themeColor']}"> OUT; return $out; }

@jmartsch Here's the thing – sadly, I haven't done anything with ProcessWire in a long time. I would like to, but switching from being self-employed and building sites for clients to being employed at an agency and focussing on frontend has kind of pulled my out of the loop here. Of course, just maintaining the lang pack is not a big thing, it's basically just merging pull requests on my end. However, I feel like this should rather be maintained by someone who is more actively involved with the community. How about I hand over the ownership of the lang pack repository to you and you become the new maintainer? (Yes, I'm serious.) :-)

sounds familiar; I switched some sites over to a KnownHost VPS and so far it has been good. I can definitely say that their support is great, any support ticket is answered very rapidly, and this applies to both VPS and for their shared hosting plans.

Thx for the hint! This calls for being built into a pw module ?

Minimal Fieldset Adds a config option to Fieldset/FieldsetGroup/FieldsetPage to render the fieldset without label or padding in Page Edit. When a neighbouring field in the same row is taller than the fieldset the extra height is distributed evenly among rows within the fieldset. Requires ProcessWire v3 and AdminThemeUikit. Why? This module allows you to create layouts in Page Edit that would not be possible without it. It's useful when you want a layout that has two or more fields as rows that are themselves within a row in Page Edit. It's also useful when you have some fields that you want to add to a template as a group (i.e. via FieldsetGroup or FieldsetPage) but having a heading and visible wrapper for the fieldset in Page Edit would be redundant. Example: Installation Install the Minimal Fieldset module. Usage In the field settings for any Fieldset/FieldsetGroup/FieldsetPage, tick the "Remove label and padding for this fieldset" checkbox. https://github.com/Toutouwai/MinimalFieldset https://modules.processwire.com/modules/minimal-fieldset/

Hello @breezer, welcome to the PW forums, If you do a quick google search like this: https://www.google.hu/search?ei=JOnpW_G4LIG0kwWxyo7gDQ&amp;q=forum+module+site%3Aprocesswire.com%2Ftalk then you can see that there is interest in a forum module for ProcessWire, for sure. Whether you can earn "enough" by making it commercial is a different matter. Keep in mind that PW has a relatively low user base, at least compared to other more popular systems out there. Still, paying for a complex module instead of implementing it can be a great timesaver if the given module comes with proper support.

Hi, Are you on ProcessWire 3 ? If yes then write at the top of the check_code.php the following code : <?php namespace ProcessWire; What's the error(s) ? - Assuming the problem is calling this file, modify your call(s) to this file like that : <!-- example for form action --> <form method="post" action="<?= $config->urls->templates; ?>download/check_code.php"> [...] </form> <!-- example for redirect --> <?php $session->redirect($config->urls->templates . 'download/check_code.php');

If there is no hook you can copy the file to the site directory and in the setting of the module you can select which version you want to use. I usually store them in /site/wire/ so I know which modules I've overwritten. I have to say I haven't used this much lately.

I would rather check if there's a hookable method, or if you can do something with an admin.js/.css instead.

and what does it say? Most probably, you just have to adjust a path/URL. Or maybe you have to create a dummy PW template + page for check_code.php file as well.

Ok @MarcoPLY , I think I got your question completely wrong ? I leave my reply anyway if someone needs it one day... Have you tried to var_dump the subscriber? What do you get there? Is the $ before country_title intentional?

I think this is a question for @ryan (?)

Hi horst, thanks for the reply! I'll use that check to make sure no pages are linked that shouldn't be visible. However, I would still like to filter out pages with statuses that will never be viewable. I'm querying the database directly to get a list of pages for performance reasons. Since I'm performing one costly regex per title, I would like to only get the pages that are actually published & viewable, so I still need to understand all status IDs to determine whether they're relevant for the bitmask ... I looked into what checks $page->viewable perfoms, but haven't been able to find a reference to the IDs for "draft" and "versions", so maybe they are not relevant after all?

public function matches($selector) { // This method implements the WireMatchable interface return $this->comparison()->matches($this, $selector); } @bernhard I think $this->comparison()->matches($this, $selector) is PageComparison->matches(Page $page, $s) which doesn't accept an array, it only checks for a string or int and a selector, else returns false.

Done - let me know how it goes for you. I also fixed some other PHP7 issues with the Option 2 approach.