Leaderboard

@yellowled Hey, thanks for the quick reply. Yeah, I would like to take over. My username on github is jmartsch. You can transfer the ownership to me and I try to do my best to update the language pack (with a little help of the community).

I am proud to anounce, that I am the new maintainer of the github repo now. I will add my translations for the dev version very soon. Thanks to @yellowled for handing it over to me.

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:

The language pack is available at https://modules.processwire.com/modules/german/ or in the github repository https://github.com/jmartsch/pw-lang-de/releases/tag/latest The master branch will (try to) be up to date with the most recent stable version of ProcessWire. The dev branch will (try to) be up to date with the most recent dev version of ProcessWire. If you find any missing translations or errors, please create a PR or submit a bug/improvement. I hope we as a community can work together, to update translatations as soon as a new dev branch is pushed. Please let me know if you want to translate a new dev version, so we are not both doing the same task. If you want to help, you can clone my ProcessWire environment for language packs which provides an easy way for translating a language pack. You simply clone it, make changes to the language in ProcessWire and commit the changes back to your (or the german) language pack repository. This is a boilerplate which could work with any language, but right now it is tailored to the german language pack. Then I am able to quickly release an updated stable language pack when a new ProcessWire stable version is released. Big thanks to @Nico Knoll and @yellowled for their initial work on the translations.

Just for reference, I think the easiest way to do aggregations at the moment is creating a regular finder and taking the resulting SQL as subquery and modifying it to your needs: And if you need it in your code (not in the RockFinder Tester) you need to set the SQL via $finder->sql:

@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.) :-)

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; }

Firefox 65 will support WebP. Will be out in January 2019.

Ok this is the issue. Your problem is a known bug in SOAP extension and you should update the version running on your server to at least PHP 7.1.14 (known to me where the bug was fixed and its working). So just to be clear, PHP 7.0 branch contain the bug. To fix it, update the server PHP version. And FYI, a good habit is to develop with the same environment to avoid those head scratching moment ? - https://bugs.php.net/bug.php?id=70469 Submitted: 2015-09-10 13:50 UTC Modified: 2017-11-22 22:14 UTC https://github.com/php/php-src/pull/2899

@jmartsch Great! However, you'll have to rename your forked version – since you can't have two repos of the same name, I can not transfer the original. I'll get in touch via email so we can also give you access to the module directory entry.

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.

Most of what I've been working on this week is related to the new PW website. That's includes primarily continued copy writing and site development (about 50/50), and it's coming along very well, though a lot of work. I'm hoping to have it ready to post publicly for collaboration by the end of the year. I'll have screenshots to share well before that though. The content of the site (particularly documentation section) is so much improved from the current site that I'd like to get it online as soon as possible, even if design details and some features are still being worked on. In addition to continued work in the documentation section, this week I also worked on the sites directory. I'm going to keep working on that today rather than writing a longer blog post, so that's why I'm posting this update here in the forum instead. Next week I'll also have ProcessWire 3.0.119 ready. Though you can grab the current dev branch already to benefit from a couple of features that are already in it. These include two items from the processwire-requests GitHub repository, among some other minor updates. Here's a preview from next week's blog post about a couple of new features in 3.0.119: • Robin S. (@Toutouwai) suggested that collapsed file/image and CKEditor fields automatically open when a file is dragged into them. Toutouwai also wrote the code to make it happen. This addition is super convenient, and it works great. • @BitPoet suggested that our ajax file upload capture and write the uploaded file in ~8 megabyte chunks. This is preferable to loading all the file data into memory and then writing it, enabling it to support larger file uploads that might not have been possible before (depending on server memory). Presumably this also can help to reduce server load. Thanks to BitPoet for writing the code to make it happen. Also on the dev branch this week is a new WireArray::slices() method and support for created/modified page dates in pages export/import functions (I needed this to import the PW sites directory entries). I'll have more details on all of these updates and more, next week.

Great - thanks for testing. I just committed another minor update that renames and reorders some of the settings and divides them into "required" and "optional" to make things a little more logical and quicker to complete.

Correct, try to compare your hook-code and the one on the documentation: https://processwire.com/api/ref/pages/saved/ hints: function, HookEvent, $pages, $event, object; ? besthintever: tracy

Thanks @adrian, couldn't find the blog post. If a hook is present it is always more preferrable I would say.

Looks like this could be the thing. Thank you very much! Will get back shortly.

Thanks for these updates - working perfectly now.

Is this what you are looking for? https://processwire.com/blog/posts/processwire-core-updates-2.5.14/#multiple-copies-of-the-same-module This is what @arjen is referring to above. That said, I still think a hook approach is better if you can.

Here's a little snippet for site/ready.php that lets you store your modified copy of the js file in question under site/modules/FieldtypeRepeater/ and replaces the URL in a renderReadyHook on InputfieldRepeater: <?php namespace ProcessWire; wire()->addHookAfter("InputfieldRepeater::renderReadyHook", null, "useRepeaterSiteJS"); function useRepeaterSiteJS(HookEvent $event) { $config = $event->object->config; $modules = $event->object->modules; foreach($config->scripts as $script) { if(strpos($script, $config->urls->InputfieldRepeater . "InputfieldRepeater") !== false) { $altName = "InputfieldRepeater.js"; $altPath = $config->paths->siteModules . "FieldtypeRepeater" . DIRECTORY_SEPARATOR . $altName; if(file_exists($altPath)) { $altUrl = $config->urls->siteModules . "FieldtypeRepeater/" . $altName; $info = $modules->getModuleInfo("InputfieldRepeater", array('verbose' => false)); $version = $info["version"] ?: 0; $modified = filemtime($altPath); $config->scripts->remove($script); $config->scripts->add($altUrl . "?v=$version-$modified"); break; } } } } Edit: amended the text to make it clear that this approach is only about the js file in question, differing from other suggestions that duplicate the complete module. Of course, incorporating changes in the original js file on every update has to be done anyway.

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.

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.

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.

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

Hi @Robin S - I have fixed the bug regarding child page creation - I think it was a change to "empty" in PHP 7 that was the cause. I'm in transit now, but I can take a look at the new option for being able to set the parent page title in the next few days.

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

@mke, there is a property and helper method in InputfieldFile that allows a maximum files size to be set but there is no config field for it in admin and you would need to set the max file size in a hook in /site/ready.php: $wire->addHookBefore('InputfieldFile::render', function(HookEvent $event) { /* @var InputfieldFile $inputfield */ $inputfield = $event->object; if($inputfield->hasField == 'YOUR_FIELD_NAME') { $inputfield->setMaxFilesize('2m'); // Set the max file size in bytes or use string like "30m", "2g" "500k" } }); Also, for some reason max file size settings of less than 2MB are not enforced - see here.

Once again heads up, everyone, I just now updated the “stable” German language pack for 3.0.34, which – as usual by now – means a lot of work, mostly by Manfred, (translating all the things) followed by a little work by me (merging). As usual, thanks to all the contributors, especially Manfred for his tireless efforts and Robert, who took the time to iron out a looooooot of small mistakes. Everyone, enjoy and please report anything you may find wrong or worth improving, ideally in a pull request at https://github.com/yellowled/pw-lang-de, please.