Leaderboard

Hi everyone, Introducing my first module https://github.com/christophengelmayer/StaticWire It's a simple way to convert your ProcessWire site to static HTML files via CLI or the admin interface. Useful in CI/CD scripts or to use ProcessWire as a simple static site generator.

ProcessWire 3.0.149 on the dev branch includes various improvements and a few minor fixes. Here are the most significant differences relative to 3.0.148 master: There have been several improvements to the $notices API variable as well as a significant refactoring of the code. Several new flags are now supported and can be specified by name rather than just by bit mask. While these updates won’t matter much for front-end site work, they are going to be helpful for the admin as well as potentially in other modules that work in the admin. Some of the updates are still a work in progress, so more will likely be added in the near future. (Commit) The Comments Fieldtype and related classes have received upgrades as well. (Commit) Several new API methods have been added for handling the parent/child relationships involved in threaded comments. The ProcessCommentsManager has also received major upgrades and it puts these new API functions to use by now allowing you to change which page a comment lives on (move a comment from one page to another), as well as change which comment another one replies to. Lots of refactoring was done in this module as well. (Commit) A minor but useful detail in AdminThemeUikit: if you click in the search box (top right corner) and don’t immediately start typing, it now suggests that you try typing “help” for options. Since this is an English word, the “help” term can also be translated in the AdminThemeUikit files (_search-form.php file). PW’s admin search engine can do quite a bit more than I think people realize at first, so I thought this was one way to help more people see what the options are with it, at least in AdminThemeUikit. (Commit) There were several other minor updates as well, but the above are the ones that I thought were the most interesting. Thanks for reading and have a great weekend!

No problem, as Andreas said, everything you requested is already implemented. If you have other features in mind, do not hesitate guys ? Also, with the next version, you will be able to backup the big site with Duplicator. I can make backup of a 1.6GO website without issue. It can be already tested - it's on the dev branch on Github.

Hi @ngrmm, You don't have to assign a boundary, that should be done automatically by the email module when an attachment is recognised. I was referring to troubleshooting by looking at the headers to see if there was a boundary id for an attachment. You shouldn't have any issues if you follow the WireMail api examples. Specifically, $m->attachment('/path/to/file.ext'); indicates your attachment should be the path to the file. You would therefore write out your ICS file and use the resulting filepath.

https://modules.processwire.com/modules/static-wire/

My apologies, this was user error on my part. I was using the full server paths, rather than the site path. /home/accountname/public_html/site/vendor/ rather than /site/vendor/ @Autofahrn thanks for your post.

@GhostRider, what's wrong with the 'Custom excluded files and paths' box? To exclude a path simply enter it without a file pattern like: /site/assets/pwpw/ /vendorOrAnyCustomDirectoryAtThisLevel/ To exclude the ProCache stuff using a regular expression should do: %/ProCache-[^/]+$% # Ignore ProCache directory To exclude image variants you may try this: %\.\d+x\d+\.[^/]+$% # Ignore variants created by PW

@Robin S Thanks. For now, I ended up with .... $this->wire()->addHookAfter('Pages::trashed(template=link-block|post|tag)', $this, 'customRedirectOnDelete'); public function hookRedirectOnLinkBlockDelete($event) { $event->wire()->addHookBefore('Session::redirect', function(HookEvent $event) { $url = $event->arguments(0); if($this->process == 'ProcessPageEdit') { $admin_url = $event->wire('config')->urls->admin; if(strpos($url, $admin_url . 'page/?open=') === 0) { $event->arguments(0, '../trash/'); } } }); }

You might want to also validate the date when the page is saved as @BitPoet suggests, but it is possible to limit the datepicker to only future dates with some custom admin JS. The relevant option is minDate. The core sets the datepicker options on focus, so to ensure the custom option doesn't get overwritten I've found that the most reliable way to apply it is by using a beforeShow function. For a Datetime field named "crondate": $(function() { $('#Inputfield_crondate').on('focus', function() { $(this).datepicker('option', 'beforeShow', function() { return { minDate: 0 }; }); }); }); Edit: just noticed you want a minimum time also. Try this: $(function() { $('#Inputfield_crondate').on('focus', function() { $(this).datepicker('option', 'beforeShow', function() { return { minDate: 0, minDateTime: new Date(new Date().getTime() + 30 * 60000) }; }); }); });

Where does filename come from? header("Content-Disposition: attachment; filename={$filename}.ics"); Why are you assigning an attachment that is not a file. $m->attachment($ical_data); Is the attatchment boundary defined ?

I cannot confirm this, no problem on my side with the "same" setup

Hi Flydev, I have been thinking about one feature request if you are taking any. I don't want to add more work, but perhaps something to think about. On the Duplicator settings page, I have used the "Files and folders excluded from" checkbox (very handy) and also the "Custom excluded files and paths'. I'm wondering if there is any way of excluding any custom file directories, rather than file extensions? Here are a few examples: 1. After adding the AWS library via composer, Duplicator is backing up the Composer directory called vendor (at the same level as wire, files etc...). This file has become quite large over time. 2. We also at times create directories at the same level for legacy files when building a new client sites, where the legacy files need to still be accessible. Our latest client had a very large media folder nearly 7GB. ie /media/ 3. When using ProCache, Proche adds two folders in the assets directory called ProCache-###### and pwpc. The ProCache-#### file is a collection of all the static versions of the pages on the site, which can also become quite large depending on the site. With most of these directories, we do have a good idea what file extensions are being used and can exclude them in the 'Custom excluded files and paths' section. However, with the Composer vendor directory, there are so many file extensions being used with a very deep nested group of folders. This makes for a very large list of possibilities to exclude. With a few of our sites, our backups went from ~90MB to over 700MB. It would be great to hear your thoughts on hiding directories/folders when you have time. Below is a list of some of the file paths we struggle with. /vendor or any custom directory at this level /site/assets/ProCache-### /site/assets/pwpw/* Thanks

I can confirm that 1.1.4 fixed the issue we were having. Thank you for getting back so quickly. ?

@sodesign Ok, I think I found the problem. I was able to get the same error as yours and patched the module to fix it, just now. Try the latest version and let me know if the issue is resolved for you. New Release 1.1.4 - Fix FieldtypePage bug when FieldtypePage:derefAsPageOrNullPage option is enabled.

Cool! Looking forward to trying this. Thanks gebeer

Sorry - copy and paste error*. I am using a ConfiguratorQuoteCreateInput field when I get the error. *(I tried using update as well in case the page reference needed a parent page to exist first)

The GDPR doesn't actually handle cookies specifically. GDPR is about processing personal data. A cookie is processed by a webserver when a user accesses your website, so GDPR is applicable IF there is personal data involved in regards to the cookie. Even a simple session cookie is personal data, because it identifies a certain browser session, which in turn likely identifies a person. There are a few things GDPR demands you to provide to users in such a case, like what the data is used for (Art. 13/14) and it needs to have a legitimate reason (Art. 6) for you to be allowed to do so. This is even more complex if it's not a cookie set by your website, but by a third party. There it's the shared responsibility between your and the third party that everything is handled correctly. This is usually done with DPA (data processing agreement) which is a binding contract where both parties essentially guarantee each other GDPR compliance. The GDPR gives users the right to deny consent wherever you cannot use Art. 6 1.f) as legitimate reason. Therefore cookie-banners with the option to not have certain cookies set. The GDPR also says you may not auto opt people into giving consent, therefore the default for optional cookies should be unset. Besides the GDPR there's afaik a law in Germany for cookies specifically, which has been the kinda predecessor for the long overdue EU wide ePrivacy directive. I'm not as well versed with this one. It was essentially the law, which started all the cookie banner stuff.

You can add your own validation with a small hook in site/ready.php. wire()->addHookAfter("InputfieldDatetime::processInput", null, "validateFuture"); function validateFuture(HookEvent $event) { $field = $event->object; // Make sure to enter the correct name of your field here: if($field->name == "crondate") { // Compare field with current time plus 30s * 1000ms: if($field->value < time() + 30000) { $field->error("Date is not in the future!"); } } } Adapting the datetimepicker isn't easy if possible at all.

Hi @dadish, I'm upgrading a site to use the latest version of this module. I'm having trouble with a page reference field when creating a new page with a mutation. Before, I was using a mutation with variables like this: mutation ($page: ConfiguratorQuoteUpdateInput!) { createConfiguratorQuote(page: $page) { id } } variables: { "page": { "name": "test-quote", "title": "Tets Quote", "parent": "22905", "colour": [10392] // this is the page reference field } } I noticed the field now uses the type InputfieldPage rather than [ID] and there are add and remove fields inside this InputfieldPage field. I have tried formatting the variables in a couple of ways and I see this error in graphqil: // "debugMessage": "Method NullPage::add does not exist or is not callable in this context", // When using either of these variables: { "page": { "name": "test-quote", "title": "Test Quote", "parent": "22905", "colour": { "add": 10392 } } } variables: { "page": { "name": "test-quote", "title": "Test Quote", "parent": "22905", "colour": { "add": [10392] } } } Can you advise how I should be adding page reference fields? I have checked the page template and fields are legal, they return without issue in queries for existing pages. Many thanks, Tom

Hey @elabx I did find this module from @kongondo and have no doubt that it would do the job perfectly. The reason not yet to purchase it is because I am just trying to weight every option and see which one fits the best. Quite honestly, I would love to purchase all the premium modules from the PW-guru-gang as this would be just a tiny payout for the flawless and completely free support we've all received throughout the years, but presently I am on a bit tight budget so that would have to wait. I am definitely purchasing the FormBuilder and Dynamic Select as I see them fit in almost every project...

Have you seen: https://modules.processwire.com/modules/process-dynamic-selects/ ? Modules from @kongondo are as pro as it gets :)

I have pushed a small fix regarding the new "multiple product templates" feature. Please redownload at GitHub.

I created an issue on github for this https://github.com/processwire/processwire-issues/issues/1058

I am thinking of something like this: language name: predefined by ISO 3166 language title: user can chooose language url: user can choose, fallback to ISO 3166

Yes, you guys are right. But the "best way" would be if PW natively had support for this, regardless of what the user has chosen as the language title. The language name should be the defined value from the ISO 3166 standard, although one should be able to change the URL of the language, so instead of "de" the URL "deutsch" could be used. EDIT: This would enable us module devs to deliver language files with our modules, regardless of the users language setup.

actually this is in the core, all you need to do is add these to your toolbar (you don't need to add any plugins): so where your first line would look like this out of the box: Format, Bold, Italic, -, RemoveFormat you can change it to be like this: Format, Bold, Italic, Underline, -, RemoveFormat, -, TextColor, BGColor