Leaderboard

Wrapping up the fieldset trilogy comes part 3: Fieldset Group, which is now released. In the post we take a closer look at it and compare it to the other fieldset types. Then we wrap up with some hints about more coming up in the weeks ahead. https://processwire.com/blog/posts/fieldsetgroup-module-released/

You don't need to include PW multiple times, just construct a new ProcessWire object with the path and URL of each site, then access PW's globals through the relevant site's object, i.e. $site->pages instead of $pages, etc. See https://processwire.com/blog/posts/multi-instance-pw3/ for details.

The modules manager module hasn't been tagged as PW 3 compatible. I honestly don't really think it is necessary these days - we have such an easy way of installing modules directly in PW by their class name.

I am not sure why you disabled the file compiler. If you leave that turned on you shouldn't even need to add the namespace to the top of the module files. Was there a reason you chose to disable it?

Try changing <?php to <?php namespace ProcessWire; on the first line of ServicePages.module file

First of all thank you @ryan. This is why I love ProcessWire: The community requests a feature and instead of just realizing it, you come up with multiple solutions to this request. I have tried the new FieldsetGroup and it comes in really handy. I had only two issues: The bug @abdus mentioned earlier in line 475. I have commented it out in the module for now, to get the module working, but hopefully it wasn't anything necessary and will be fixed. Is it correct, that the fields inside the FieldsetGroup only get added to the template, if you use the actions tab inside the field configuration? I tried adding it in the template configuration, but it only added the fieldset, not the fields inside the fieldset. Maybe it is a bug, but I would have expected it to add all the fields. Regards, Andreas

Docs & Download: rockettpw/seo/markup-sitemap Modules Directory: MarkupSitemap Composer: rockett/sitemap ⚠️ NEW MAINTAINER NEEDED: Sitemap is in need of developer to take over the project. There are a few minor issues with it, but for the most part, most scenarios, it works, and it works well. However, I'm unable to commit to further development, and would appreciate it if someone could take it over. If you're interested, please send me a private message and we can take it from there. MarkupSitemap is essentially an upgrade to MarkupSitemapXML by Pete. It adds multi-language support using the built-in LanguageSupportPageNames. Where multi-language pages are available, they are added to the sitemap by means of an alternate link in that page's <url>. Support for listing images in the sitemap on a page-by-page basis and using a sitemap stylesheet are also added. Example when using the built-in multi-language profile: <url> <loc>http://domain.local/about/</loc> <lastmod>2017-08-27T16:16:32+02:00</lastmod> <xhtml:link rel="alternate" hreflang="en" href="http://domain.local/en/about/"/> <xhtml:link rel="alternate" hreflang="de" href="http://domain.local/de/uber/"/> <xhtml:link rel="alternate" hreflang="fi" href="http://domain.local/fi/tietoja/"/> </url> It also uses a locally maintained fork of a sitemap package by Matthew Davies that assists in automating the process. The doesn't use the same sitemap_ignore field available in MarkupSitemapXML. Rather, it renders sitemap options fields in a Page's Settings tab. One of the fields is for excluding a Page from the sitemap, and another is for excluding its children. You can assign which templates get these config fields in the module's configuration (much like you would with MarkupSEO). Note that the two exclusion options are mutually exclusive at this point as there may be cases where you don't want to show a parent page, but only its children. Whilst unorthodox, I'm leaving the flexibility there. (The home page cannot be excluded from the sitemap, so the applicable exclusion fields won't be available there.) As of December 2017, you can also exclude templates from sitemap access altogether, whilst retaining their settings if previously configured. Sitemap also allows you to include images for each page at the template level, and you can disable image output at the page level. The module allows you to set the priority on a per-page basis (it's optional and will not be included if not set). Lastly, a stylesheet option has also been added. You can use the default one (enabled by default), or set your own. Note that if the module is uninstalled, any saved data on a per-page basis is removed. The same thing happens for a specific page when it is deleted after having been trashed.

While I was reading Smashing Magazine, I discovered this handy tool called XRespond that lets you load webpages in iframes that are designed to simulate different devices, (similar to how browsers' mobile simulators work). I think it's quite useful for local development. In fact it works for any website as long as it doesnt have `X-Frame-Options` headers set to `sameorigin`. I highly recommend using it with browser-sync with live loading as well. I use this settings when using it with PHPStorm to live reload my dev site on pw.dev. // remember set cwd to /site/templates/ or call it from templates directory path/to/browser-sync.cmd start --proxy pw.dev --port 8080 --files "**/*.php" --files "assets/**/*.css" --files "assets/**/*.css" What other tools/utilities do you use for testing your responsive designs?

Some points: You can get inputs in an array if you name them as profession[] instead of profession_1, profession_2 ... etc. $input->post->profession will give you an array directly Using this method for the input field outside foreach() block (one with count + 1) will achieve what you want without using indices. Also you can clone that field indefinitely to let user create as many jobs as he/she wants Is there a reason why you're outputting professions on the frontend, only to replace with $page's on form submit? Thrashing and creating a lot of pages at once will probably slow the page down to a crawl. I simplified the code a bit <?php namespace ProcessWire; /** @var $input WireInput */ /** @var $page Page */ if ($input->post->submit) { // check if there are any professions if ($input->post->professions && count($input->post->professions)) { $page->of(false); $newItems = []; foreach ($input->post->professions as $val) { // always sanitize user input /** @var $sanitizer Sanitizer */ $val = $sanitizer->entities1($val); $val = $sanitizer->text($val); if (!$val) continue; $item = $page->professions->getNewItem(); $item->profession = $val; $item->save(); $newItems[] = $item; } if (count($newItems)) { $page->professions->removeAll($newItems); $page->professions->add($newItems); $page->save('professions'); } } } ?> <form method="post"> <?php foreach ($page->professions as $i => $prof): ?> <input type="text" name="professions[]" value="<?= $prof->profession ?>"/> <?php endforeach; ?> <!-- I guess for a new profession? --> <input type="text" name="professions[]" value=""/> <input type="submit" name="submit" value="submit"/> </form> Frankly, I can't say I fully understand what this form really does, so it'd be better if you explain your requirements a bit more

Let me introduce you to Field - Template Contexts https://processwire.com/videos/field-template-context/ As for the multiple/single image fields, I usually have a single image field that is set to return an array, and use only what I need by getting the first image or filtering with tags. I rarely, if ever need to create a second images or files field. With template contexts, change the description and notes to guide the editor and use it in the templates however you want. You might add some checks with hooks and throw error if someone added more than one image to a template. wire()->addHookBefore('Pages::saveReady', function (HookEvent $e) { $limitedTemplates = ['post', 'event']; // limit to only one image /** @var Page $page */ $page = $e->arguments('page'); if(!in_array($page->template->name, $limitedTemplates)) return; if ($page->images->count > 1) throw new WireException('Only one image is allowed'); });

So cool ! I can't believe it was so... simple... I added this line on my templates files, but didn't think it was needed in modules as well. Now, I'll try and face the other issues by myself, but it went a little further. That's cool ! Thanks a lot for your help !

Before you buy you can see all options for the module on the skyscrapers demo website. http://demo.processwire.com/admin/

Hello @suntrop, Yes, you can check or uncheck which templates should be cached. I don't quite understand, what you mean by that. But as long as it is a page, it can be cached. No, you don't need to change anything inside your templates. Pages with user input shouldn't be cached. Here is a quote by @ryan about this question: In my opinion ProCache is a awesome module and well worth the money. It helped me optimize many websites in just a few clicks. I can fully recommend it. Regards, Andreas

Also, while adding fields to the fieldset, unless I am missing something, the field's _END counterpart shouldn't show up: Inside FieldgroupConfig.php, I tried removing closing field, but the solution I found isn't really pretty. $f instanceof FieldtypeFieldsetClose always return false for all FieldsetClose (fieldset, tabs, fieldsetfieldgroups etc) fields public function getConfigInputfields(Field $field, InputfieldWrapper $inputfields) { // ... foreach ($this->wire('fields') as $f) { if ($f->id == $field->id) continue; if ($template && $template->fieldgroup->has($f)) continue; if ($f->name == $field->name) continue; // WORKING skip its own closing field if ($f->name === "{$field->name}_END") continue; // NOT WORKING // $f instanceof FieldtypeFieldsetClose is never true for _END fields if($f instanceof FieldtypeFieldsetClose && strpos($f->name, $field->name) === 0) continue; // ... $select->addOption($f->id, $name, $attrs); } // ... }

Hey @ryan, thanks for the update as always. I may have found a bug. Or it might be specific to my system too. I'm not sure. When I create a FieldsetGroup, I can't edit it, and I get this error: (I'm on v3.0.74) Putting a breakpoint inside the method, I see: $this->wire('modules')->get('InputfieldFieldsetOpen') returns null. I've searched the core for that module. It appears inside FieldtypeFieldsetOpen.module like this: class InputfieldFieldsetOpen extends InputfieldWrapper { } // empty definition class FieldtypeFieldsetOpen extends Fieldtype { /* ... */ } When I try to get the module manually using $modules->InputfieldFieldsetOpen, it doesnt work either. I tried refreshing module cache, but it didnt help. Then I refactored InputfieldFieldsetOpen into its own module file under /wire/modules/Inputfields/InputfieldFieldsetOpen.module (without removing it from FieldtypeFieldsetOpen.module), and refreshed module cache (and remove the definition from FieldtypeFieldsetOpen.module), PW recognizes the module and I can edit the field now.

datatable connected to the pagefield updating the pageautocomplete field seemed a little tricky in the beginning but the final approach was quite easy: // handle buttonclicks $('#addcompetences').click(function(e) { e.preventDefault(); var table = $table.DataTable(); // datatable instance var $field = $('#wrap_Inputfield_competences'); // asm select field var $template = $field.find('li.itemTemplate'); // selected page template var $ol = $template.closest('ol'); // get selected competences from table var selectedtable = $.map( table.rows({selected:true}).data(), function(val, i) { return [[ val.id.sort, val.title + ' (' + val.cluster.filter + ')' ]]; } ); // update ASM // clone template and populate values $.each(selectedtable, function(i,val) { // check double if($ol.find('.itemValue:contains("' + val[0] + '")').length) return; // add clone var $new = $template.clone().appendTo($template.parent()); $new.find('.itemValue').text(val[0]); $new.find('.itemLabel').text(val[1]); $new.removeClass('itemTemplate'); }); // add state changed class $field.addClass('InputfieldStateChanged'); // update original input InputfieldPageAutocomplete.rebuildInput($ol); return false; });

I've made a few CSS changes, now preview buttons look the same in all 3 image grid modes and I've fixed some other glitches too. The CSS file was a bit overcomplicated, I could eliminate large blocks so I hope I haven't broken anything I also checked the preview images with more than one crop setting (multiple buttons) and it's working fine here. All is in the PR.

@noelboss - have you tried using TracyDebugger yet? You could get that going and then troubleshoot the contents of the $page in the profile editor; you may also be able to see warnings and errors when using Tracy. Using it is pretty much required if you are doing any serious dev work in the backend.

Here it is in a hook. Use it with $pages->get(1234)->setPublished($timestamp), where you can get timestamp using strtotime or edit hook to build a date formatted as Y-m-d h:i:s wire()->addHookMethod('Page::setPublished', function (HookEvent $e) { $page = $e->object; $timestamp = $e->arguments(0); if (!$page->id) return false; if (!$timestamp) return false; $date = date('Y-m-d h:i:s', $timestamp); $query = $e->database->prepare("UPDATE pages SET published=:pub_date WHERE id=:page_id"); $e->return = $query->execute([ ':pub_date' => $date, ':page_id' => $page->id ]); });

CKEditor's inputfield settings -> Details tab -> Markup/HTML (Content type) -> Update image alt attributes: Replace blank alt attributes with image description And this is why hiding the Image inputfield might not be the best idea. If you hide it, how can the editor provide the alt text? Similar to yours but sometimes little things make a big difference: Body -> Body Images Notice the description too. BTW, I could not reproduce your tiny image + caption issue on ProcessWire ProcessWire 3.0.73. My "Select image" modal looks different, see my screenshot in my post above. I have an Upload Image button in the bottom-right corner too, next to cancel. Don't you have those as well? Also, I do not have "Choose File". My "not hacked" upload modal looks like Peter's (+ the buttons in the bottom as well):

You can hook before ProcessLogin::executeLogout and set the desired url. <?php wire()->addHookBefore("ProcessLogin::executeLogout", null, "setRedirect"); function setRedirect(HookEvent $event) { $event->object->setLogoutURL($pages->get('/')->httpUrl); }

I started a new topic here: https://processwire.com/talk/topic/7542-development-fieldtypefloat-fieldtypedecimal/