Search the Community

EDIT: ************* Note that this OP relates to the original version of the module. Version 0.0.19 is now published to the modules library at https://processwire.com/modules/fieldtype-measurement/. As well as many bug fixes and small enhancements, it now also includes an 'in-field' interactive conversion feature and dependent-select in the config. See the readme on the module page for up-to-date details and see this post for a bit of a demo. ************* This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API. The API consists of a number of predefined functions, some of which include... render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m. A simple length field using Fieldtype Measurement and Inputfield Measurement. Combination units (e.g. feet and inches) are also supported. Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly. See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.

Mystique Module for ProcessWire CMS/CMF Github repo : https://github.com/trk/Mystique Mystique module allow you to create dynamic fields and store dynamic fields data on database by using a config file. Requirements ProcessWire 3.0 or newer PHP 7.0 or newer FieldtypeMystique InputfieldMystique Installation Install the module from the modules directory: Via Composer: composer require trk/mystique Via git clone: cd your-processwire-project-folder/ cd site/modules/ git clone https://github.com/trk/Mystique.git Module in live reaction with your Mystique config file This mean if you remove a field from your config file, field will be removed from edit screen. As you see on youtube video. Using Mystique with your module or use different configs path, autoload need to be true for modules Default configs path is site/templates/configs/, and your config file name need to start with Mystique. and need to end with .php extension. Adding custom path not supporting anymore ! // Add your custom path inside your module class`init` function, didn't tested outside public function init() { $path = __DIR__ . DIRECTORY_SEPARATOR . 'configs' . DIRECTORY_SEPARATOR; Mystique::add($path); } Mystique module will search site/modules/**/configs/Mystique.*.php and site/templates/Mystique.*.php paths for Mystique config files. All config files need to return a PHP ARRAY like examples. Usage almost same with ProcessWire Inputfield Api, only difference is set and showIf usage like on example. <?php namespace ProcessWire; /** * Resource : testing-mystique */ return [ 'title' => __('Testing Mystique'), 'fields' => [ 'text_field' => [ 'label' => __('You can use short named types'), 'description' => __('In file showIf working like example'), 'notes' => __('Also you can use $input->set() method'), 'type' => 'text', 'showIf' => [ 'another_text' => "=''" ], 'set' => [ 'showCount' => InputfieldText::showCountChars, 'maxlength' => 255 ], 'attr' => [ 'attr-foo' => 'bar', 'attr-bar' => 'foo' ] ], 'another_text' => [ 'label' => __('Another text field (default type is text)') ] ] ]; Example: site/templates/configs/Mystique.seo-fields.php <?php namespace ProcessWire; /** * Resource : seo-fields */ return [ 'title' => __('Seo fields'), 'fields' => [ 'window_title' => [ 'label' => __('Window title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'attr' => [ 'placeholder' => __('Enter a window title') ] ], 'navigation_title' => [ 'label' => __('Navigation title'), 'type' => Mystique::TEXT, // or InputfieldText 'useLanguages' => true, 'showIf' => [ 'window_title' => "!=''" ], 'attr' => [ 'placeholder' => __('Enter a navigation title') ] ], 'description' => [ 'label' => __('Description for search engines'), 'type' => Mystique::TEXTAREA, 'useLanguages' => true ], 'page_tpye' => [ 'label' => __('Type'), 'type' => Mystique::SELECT, 'options' => [ 'basic' => __('Basic page'), 'gallery' => __('Gallery'), 'blog' => __('Blog') ] ], 'show_on_nav' => [ 'label' => __('Display this page on navigation'), 'type' => Mystique::CHECKBOX ] ] ]; Searching data on Mystique field is limited. Because, Mystique saving data to database in json format. When you make search for Mystique field, operator not important. Operator will be changed with %= operator. Search example $navigationPages = pages()->find('my_mystique_field.show_on_nav=1'); $navigationPages = pages()->find('my_mystique_field.page_tpye=gallery');

Introducing ProcessDiagnostics and it's helper module suite. (Is this ProcessWire's first community-created module suite?) Description This suite adds a page under the setup menu that displays information about your installation. Each section's data is provided by a specialist diagnostic helper module but it is all collected and displayed by ProcessDiagnostics. The ProcessDiagnostics module itself does not encode any knowledge about what makes up a good or bad setting in PW - (that's done by the helper modules) - but it does the following... Gather the diagnosics (thanks to PW's hook system) Display the collected diagnostics Provide helper functions for describing some common things Dispatch actions to diagnostic provider modules (again thanks to PW's hook system) And eventually it will: Allow control of the verbosity of the output Allow the output to be emailed to a sysop Store the results between visits to the page Detect differences between results at set times Send a notification on detection of changes Although I am curating the collection, anyone is welcome to fork the repo, make changes in a topic branch, and submit pull requests. I've already had submissions from horst and Nico. Diagnostic Providers The current diagnostic providers include... DiagnosePhp - Simple diagnostics about the PHP envirnoment on the server DiagnoseModules - An ajax based module version checker by @Nico DiagnoseImagehandler - Lets you know about GD + Imagick capabilities by @horst DiagnoseDatabase - Checks each DB table and lets you know what engine and charset are in use DiagnoseWebserver - Checks the webserver setup DiagnoseFilesystem - Looks at how your directory and files are configured and warns of permission issues (currently incomplete) There is also a bare bones demonstration diagnostic module... DiagnoseExample - minimal example to get module authors started. Translations English & German (thank you @Manfred62!) Help translating this suite to other languages is always welcome. On The Net Check out Nico's blog post about this suite on supercode.co!

This is a simple module to prevent guest users and search engines from accessing to your site. Primarily it is designed for use during site development. Modules directory: http://modules.processwire.com/modules/protected-mode/ Github: https://github.com/adrianbj/ProtectedMode Install and check the "Protected Mode" checkbox Create a user with only the guest role and give the login details to your clients/testers. Of course existing admin users can use their personal logins still. There are some similarities with Pete's excellent Maintenance Mode module, but the reason I built this, rather than using Maintenance Mode is: I didn't want the "Maintenance Mode" badge showing up on the site since this is for development before a site has ever been live and I didn't want the client seeing that badge. I didn't want users redirected to the PW login page because I didn't want visitors to see the PW login page. I know the module has the option to redirect to a custom page, which you could use to make a front-end login form, but that seemed more complex than I needed (and I think other PW devs might also need). Because of the way this module replaces Page::render with the login form, visitors can be sent to any page on the site, and once they login that page will reload with its full content - no messing around finding the page again, and no need for sending page ids through the login process to redirect back. This module also lets you configure the message that is displayed along with the login form, and also apply some css to style the login form. Hope you guys find it useful.

This module enables you to automatically create pages based on a ProcessWire page template, eg Calender detail page, that has calendar event recurrences. Download from GitHub: https://github.com/clipmagic/ProcessRecurringEvents

I'm working on a one-page, vanilla javascript and php (PW API) shopping checkout module that integrates PayPal server side. Here's version 1.0 https://github.com/dtjngl/kiosk Looking forward to your feedback! DISCLAIMER this is a BETA version at best, it's my first "real" module I'm writing for ProcessWire (and first module I'm writing at all) so please don't eat me alive. I'm aware that it needs a lot of work, but at this point, but it's functional. I'm also aware that it is not very customisable at this point (it's mostly customised for one specific use case), but I promise I will work on that. My main objective is to get more seasoned developers' mentoring, feedback, advice, warnings – and and of course, if you want to look into or help develop it further – pull requests. Please point out any potential dangers you see or anything that raises a red flag for you. I'm learning so much from that. Though the module is held in german, you can translate almost all strings that are in the php files via PW's translate functionality. I cannot help with the strings in the javascript yet, but will do so soon (using a json file that lives on the file system probably). I started working on this module because many checkout systems out there are either overkill and too complicated, didn't fulfil my needs or come with a premium fee that is not worth it. Also, austrian law (and other countries' jurisdiction) demand a different flow than what PayPal's Express checkout offers. So this version makes calls to PayPal on the server. WHAT IT CONTAINS - OnePage checkout system with 4 steps: cart, address(es) form, payment method (paypal and deferred), order overview - "minicart" (the cart-summary in the page's header) - buy button (to add items to the cart) - a dashboard (with admin template) for an overview of all placed orders uses server session storage and browser localstorage REQUIRED WireMail SMTP UIKIT (for best behaviour, will be optional soon) vanilla Javascript (no jQuery required) PHP (DUHDOY!) ProcessWire Version (not sure, but works with version 3.0.200) if you want it in english you need a multi-language installation PayPal Business Account (Live or Sandbox to test with) HOW TO INSTALL 1. Put the folder "Kiosk" in your ProcessWire site's modules folder 2. Install the module Kiosk, this will… - create fields for the order template - create a template for the orders placed - create a template for the orders' parent page - create a parent page "Custom Orders" for all orders under /admin/page/ (you can rename the page, not the template) - create a template "kiosk_checkout" for the checkout page - create a page "Checkout" for the checkout, child to "Home" (you can move the page, you can rename the page, not the template) - install module ProcessKiosk along with it - ProcessKiosk create a page under /admin/ (visible in the module upon creation). Here you will see a table with all the orders placed. 3. check the Kiosk module's settings page (navigate via the module's overview page) and enter details to your best knowledge. Some are not "required" but they actually are. 4. Put the below code (in essence) on "kiosk_checkout.php": if ($config->ajax) { $kiosk->handleAJAX($input); return $this->halt(); } else { $kiosk->handleStaticContent($input); echo $kiosk->renderCheckoutSteps(); } 5. put this line on a page that loads everywhere, preferably on init.php: $kiosk = $modules->get('Kiosk') 6. put this line where you want the "minicart" and toggling cart preview (provided the site runs UIKIT) to be, probably in a header that renders on each page: echo $kiosk->renderMiniCart(); 7. put this line just above you closing tag: echo $kiosk->addScripts(); HOW DOES THIS THE ORDERING WORK? 1. Add items to the cart or update quantity when viewing the cart, continue with "weiter". 2. Enter your address, if your billing address differs, uncheck the "gleiche Rechnungsadresse" and enter the billing address, checked or unchecked, both forms will be sent to the server but handled accordingly, continue with "weiter" 3. Select a payment method, continue with "weiter" 4. formdata object (containing cart items, address(es), payment method) will be sent via AJAX to the server and stored in the server session variable 5.1. if payment method is deferred - AJAX response contains the order summary markup that will render in step4 - don't forget to check " ich habe die Datenschutzerklärung sowie die AGB zur Kenntnis genommen und akzeptiere diese." (privacy policy and terms and conditions) - click on "Zahlungspflichtig bestellen" will send another AJAX request to the server thus submitting the order (continue to WHAT HAPPENS WHEN AN ORDER IS PLACED?) 5.2. if it's paypal, a bit more is happening - server sends a cURL request to paypal containing client ID and secret - response will send a token - server sends that token along with the purchase unit (created from our placed order) in another cURL request to paypal - response will send an "approve"-URL - AJAX response contains that URL - user is redirected to paypal to approve the order - user is redirected to the "checkout" page along with a token and PayerID as GET parameters - token (not needed actually) and PayerID are stored in the server session - with the PayerID in the session variable and the "status" of the paypal approved order in the localstorage the checkout process will head on to step 4: order summary - don't forget to check " ich habe die Datenschutzerklärung sowie die AGB zur Kenntnis genommen und akzeptiere diese." (privacy policy and terms and conditions) - clicking on "Zahlungspflichtig bestellen" will send another AJAX request to the server - second AJAX request will send PayPalAccessToken, PayPalPayerId and PayPalRequestId in another cURL to PayPal which will trigger the payment - response will… continue to WHAT HAPPENS WHEN AN ORDER IS PLACED? WHAT HAPPENS WHEN AN ORDER IS PLACED? an order-page with all the order's details (plus order number from the kiosk's number circle) is created under /admin/page/custom_orders/ (you can find it in the Kiosk Dashboard) number circle is iterated email markup is created using the module's default email template, you can add a path to a custom template in the module's settings email is sent to the site master and the user (check the module's settings for email addresses etc.) order in server session is reset to an empty array paypal session in server session is reset to an empty array localstorage of the browser is deleted user is redirected to a custom url (defined in the module's settings) HOW ARE PRICES HANDLED? prices allow for a stack price functionality. This means that prices and shipping depend on the quantity of items purchased. You can enter different prices and shipping costs for different quantities. If a user's amount of a selected item reaches the specified stack price, the item price and the shipping costs change. HOW ARE PRODUCTS ADDED TO THE CART? a product should be a page object to keep things simple. That page needs an "images" array field (that very name). Below you can see what a product would need. These values are added to the button's data attributes. // This is how you make a product… $product = new WireArray(); $product->id = $page->id; $product->title = $page->title; $product->source = $page->parent->name; $product->url = $page->url; $product->images = $page->images; $product->product_width = 150 // for proportional item image calculation in the cart $product->taxrate = 10 // or what ever the tax rate $product->stack_prices = array( array( "qu" => 1, "sp" => 19.99, "sh" => 5 ), array( "qu" => 10, "sp" => 14.99, "sh" => 0 ), ); $product->stack_prices = htmlspecialchars(json_encode($product->stack_prices)); // then render the "add to cart" button $kiosk->renderBuyButton($product); UPDATE version 1.1: installing kiosk.module will also create a repeater field "kiosk_product_stack_prices" (including 3 subfields as described above) that handles the stack_prices array of arrays (as described above) so you can use the GUI. create a field "kiosk_product_tax_rate" create a field "kiosk_product_width " create a field "images" if there is none in your system. create a template "kiosk_product" with all these mentioned fields use this template for your products (or the fields thereon at least and add to your template of choice) and you should be good to go. CAUTION! If you uninstall kiosk.module it will delete all pages with template "kiosk_product", that's because I'm still figuring out how to detach the fields and fieldgroups without deleting the template. Also, if you're coming from version 1.0 and want to upgrade, please uninstall it in 1.0 first and only then get the new repo (v1.1) to install again. Class kiosk now provides the following hookable methods: ___renderBuyButton(Page $product, (string) 'add to cart') pass a product (preferably with template kiosk_product) and it returns a buybutton with the price for 1 item. This method now accepts the button's label (string) as a second argument. Method is hookable. ___getSpecificStackPrice(Page $product, (int) 5) // 5 is just an example pass a product (preferably with template kiosk_product) and an amount, it returns the price for that amount of items. Method is hookable. ___getSinglePrice(Page $product) pass a product (preferably with template kiosk_product) and it returns the price for 1 item. Method is hookable. So, use template "kiosk_product" for your products, edit the product page to add details, and then do echo $kiosk->renderBuyButton($product, (string) 'add to cart'); to render an "add to cart" button.

Markup CKEditor (for Form Builder) An inputfield for displaying markup editable via CKEditor. The module is intended for use with the Form Builder module. Allows blocks of static text to be included within a form, which can be edited in the form settings using CKEditor. Screenshots Usage Install the Markup CKEditor module. In the Form Builder module settings, add "MarkupCKEditor" to "Inputfield types to use with FormBuilder". In your form settings, add a new field of type "Markup CKEditor". Enter the text you want to show in this field using "Markup Text" on the "Details" tab. Configuration In the module config you can set items for the CKEditor toolbar that will apply to all Markup CKEditor fields. If you want to insert images in your markup field then add "Image" to the toolbar items to enable the standard CKEditor image plugin. The ProcessWire image plugin is not usable because in a FormBuilder form there is no page to store images in. Advanced There is a InputfieldMarkupCKEditor::ckeReady hookable method for users who want to do advanced customisation of the CKEditor inputfield. It receives three arguments: The InputfieldCKEditor object The form as a FormBuilderForm object The field as a FormBuilderField object Example $wire->addHookAfter('InputfieldMarkupCKEditor::ckeReady', function(HookEvent $event) { /** @var InputfieldCKEditor $cke */ $cke = $event->arguments(0); /** @var FormBuilderForm */ $form = $event->arguments(1); /** @var FormBuilderField $field */ $field = $event->arguments(2); if($form->name === 'test_form' && $field->name === 'my_cke_markup_field') { $cke->contentsCss = '/site/templates/MarkupCKEditor/contents.css'; $cke->stylesSet = 'ckstyles:/site/templates/MarkupCKEditor/ckstyles.js'; } }); http://modules.processwire.com/modules/inputfield-markup-ckeditor/ https://github.com/Toutouwai/InputfieldMarkupCKEditor

Hi everyone! With Batcher you can batch-edit and create Pages in the Pw Admin. If you install this module, you get a new Page "Batcher" under Setup. Modules page: http://modules.processwire.com/modules/process-batcher/ Github: https://github.com/wanze/ProcessBatcher Editing How does it work? Search your pages with a selector. You can check if you want to include also hidden/unpublished pages with the filters. Select the pages you want to execute an action (the action only gets executed on "checked" pages). Select the action and if necessary, additional data like the new parent or the new template. Execute. Supported actions: Publish/Unpublish Pages Hide/Unhide Pages Lock/Unlock Pages Trash Pages Delete Pages Change Parent Change Template Batcher does the following permission checkings for the current user: Don't display pages that are not editable Remove Actions if the user doesn't have the permissions (page-delete, page-move, page-template, page-lock) Important notes: When changing a template, data in fields of the old template which are not assigned to the new template gets deleted. When changing the parent, the template of the new parent must accept the pages template as children. This is a setting in the template under "family". Creating How does it work? Select a parent where your new pages will be added as children Add as many pages as you want by clicking "add Page" Click "Create Pages" You must enter a title and choose a template. The name is optional: If left empty, Pw will generate this for you. Includes permission checking and Family template restrictions. This means in detail: The selected parent must accept children and their template The pages template must accept the parents template User needs the permission to add children to the selected parents template User needs the permission to create Pages for the chosen Template Batch-creating tips The chosen template and the statuses are always cloned from the last row. So if you need to add 30 pages with the same template, define it first and the click "add Page" - it'll make your life easier ;-) You can drag & drop the table rows should you want to change the order. The dragging looks ugly but it works. For the lazy dogs and keybord hackers among us, you can add a new row by pressing "ctrl+n". This works (at least in firefox) only if no input has focus. After adding a new row, the title input gets the focus. By pressing 3 times tab you arrive at the published-checkbox, here the short-cut works. Restrict Batcher for a user to only allow editing or creating Create permissions "batcher-edit" and/or "batcher-add". As soon those exists, the module checks if the current user has the permissions. If you only need batch creating, check out the following module by Soma: http://processwire.com/talk/topic/2138-process-tools-create-pages-wip/ Cheers

Find Merge Adds a Pages::findMerge() method that allows multiple PageFinder selectors to be merged into an efficient paginated set of results. This can be useful when you need more sophisticated sorting of results than what would be possible using only the sort value in a single $pages->find(). Details $results = $pages->findMerge($selectors, $options); $selectors is required and must be an array of selectors. Each selector can be in string format or array format. The findMerge() method will loop over the selectors in the order supplied, adding matching pages to the final results. $options is an optional associative array of options. limit (int) Limit for pagination. start (int) Manually override the start value rather than have it be automatically calculated from the current page number. excludeExisting (bool) Whether or not to exclude pages in each selector that have already been matched by a previous selector. Default is true. keepFirst (bool) When excludeExisting is false then a page might match more than one selector in the supplied array. But each page can only appear once in the results and if keepFirst is true then the page will appear in its earliest position in the results, whereas if keepFirst is false it will appear in its latest position in the results. Default is true. As a shortcut you can supply an integer as the second argument and it will be treated as the limit for pagination. Basic usage For most use cases only a limit will be needed for the $options argument. $selectors = [ 'title%=yellow', // title contains "yellow" 'title^=z', // title starts with "z" 'title=elephant', // title equals "elephant" 'template=colour, sort=-title, limit=3', // 3 colours in reverse alphabetical order 'template=country, sort=title, limit=40', // 40 countries in alphabetical order ]; $results = $pages->findMerge($selectors, 10); if($results->count) { echo "<p>Showing results {$results->getPaginationString()}</p>"; echo "<ul>"; foreach($results as $result) { echo "<li><a href='$result->url'>$result->title</a></li>"; } echo "</ul>"; echo $results->renderPager(); } Advanced usage The following notes are only relevant to rare cases and most users can safely skip this section. In the demo example the colour page Yellow will potentially match both the 1st selector and the 4th selector. Because of this the excludeExisting and keepFirst options will have an effect on the results. excludeExisting option false Note that the 4th selector asks for 3 colour pages (limit=3). By default excludeExisting is true, which means that when the 4th selector is processed it is interpreted as saying "find 3 colour pages in reverse alphabetical order that have not already been matched in an earlier selector". We can see that there are 3 pages in the results from that selector: Violet, Red, Orange. But if excludeExisting is set to false then the results are different. The matches of the 1st selector (Yellow, Yellow Warbler) are not excluded from consideration by the 4th selector (the 4th selector matches will be Yellow, Violet, Red), and because each page can only appear once in the results this means that the 4th selector ends up only adding 2 more pages to the results. $selectors = [ 'title%=yellow', // title contains "yellow" 'title^=z', // title starts with "z" 'title=elephant', // title equals "elephant" 'template=colour, sort=-title, limit=3', // 3 colours in reverse alphabetical order 'template=country, sort=title, limit=40', // 40 countries in alphabetical order ]; $options = [ 'limit' => 10, 'excludeExisting' => false, ]; $results = $pages->findMerge($selectors, $options); keepFirst option false As described above, the Yellow page potentially matches both the 1st and 4th selector. By default Yellow will appear in its earliest position within the results, i.e. the position resulting from it being matched by the 1st selector. But if keepFirst is set to false (and excludeExisting is false) then it will appear in its latest position within the results, i.e. the position resulting from it being matched by the 4th selector. $selectors = [ 'title%=yellow', // title contains "yellow" 'title^=z', // title starts with "z" 'title=elephant', // title equals "elephant" 'template=colour, sort=-title, limit=3', // 3 colours in reverse alphabetical order 'template=country, sort=title, limit=40', // 40 countries in alphabetical order ]; $options = [ 'limit' => 10, 'excludeExisting' => false, 'keepFirst' => false, ]; $results = $pages->findMerge($selectors, $options); keepFirst has no effect when excludeExisting is true. https://github.com/Toutouwai/FindMerge https://processwire.com/modules/find-merge/

I've been using Fathom Analytics for a while now and on a growing number of sites, so thought it was about time there was a PW module for it. WayFathomAnalytics WayFathomAnalytics is a group of modules which will allow you to view your Fathom Analytics dashboard in the PW admin panel and (optionally) automatically add and configure the tracking code on front-end pages. Links GitHub Readme & documentation Download Zip Modules directory Module settings screenshot What is Fathom Analytics? Fathom Analytics is a simple, privacy-focused website analytics tool for bloggers and businesses. Stop scrolling through pages of reports and collecting gobs of personal data about your visitors, both of which you probably don't need. Fathom is a simple and private website analytics platform that lets you focus on what's important: your business. Privacy focused Fast-loading dashboards, all data is on a single screen Easy to get what you need, no training required Unlimited email reports Private or public dashboard sharing Cookie notices not required (it doesn't use cookies or collect personal data) Displays: top content, top referrers, top goals and more

This is a very beta version of the separate functions I use to generate srcset/bgset markups. There's some similar functions floating around in the forum but this one is a bit different because you can set "named image sets" which you can use easily site-wide. It's definitely work-in-progress so use it at your own risk. MarkupSrcSet Generate srcset and bgset markup for lazysizes. Features generate srcset/bgset markup for lazysizes set image sizes in JSON array add required JavaScripts automatically (optional) fallback to smallest image size if JavaScript is not available Usage Image sets JSON (in module settings): { "hero": [ [640, 210], [1080, null], [1920, null] ], "featured-image": [ [360, 240], 1.333, 2.667 ], "gallery-thumb": [ [240, 120], [480, 300], [800, 576] ] } Image methods $image->srcset(): <img <?php echo $page->featured_image->srcset('featured-image'); ?>> $image->bgset(): <div <?php echo $page->images->first()->bgset('hero'); ?>>Lorem ipsum</div> https://github.com/rolandtoth/MarkupSrcSet

Pages Export This module is for specifically exporting ProcessWire 2.x sites for later importing into ProcessWire 3.x. Github: Project Page Modules Directory: https://modules.processwire.com/modules/process-pages-export/ Credits: Ryan Cramer Background As I make my modules ProcessWire 3.x-compatible only, I've had the need to re-create/mirror their ProcessWire 2.x test sites in respective ProcessWire 3.x sites. These ProcessWire 3.x sites (one for each module) were already in place and I didn't feel like re-doing them by exporting/importing site profiles. I also like working with JSON rather than other export formats. So, I decided to write a custom pages export/import script for moving the ProcessWire 2.x sites to their respective ProcessWire 3.x counterpart sites. I'd just finished the export side of things when I came across a post in the forums that reminded me that ProcessWire 3.x already boasts a pages export/import feature, although some of it is still in development. Great! I like its API (PagesExportImport.php) and GUI (ProcessPagesExportImport.module) so no need to re-invent the wheel. I still had the small problem of making sure my JSON export would be compatible with the JSON input that the ProcessWire 3.x import expects. No need to re-invent the wheel, again! I ditched my custom script and instead ported the export functionalities of ProcessWire 3.x Pages Export/Import for use in ProcessWire 2.2 - 2.7, specifically to help migrate older sites to ProcessWire 3.x. Compatibility The module and class have been tested and work in ProcessWire 2.2, 2.3, 2.4, 2,5, 2.6 and 2.7. The module is currently tagged as 'in development' until Pages Import feature of ProcessWire 3.x is released as stable. Nonetheless, I have not encountered any issues so far in either the export or the ProcessWire 3.x import. I think Ryan is waiting until he can support more complex field types before tagging the ProcessWire 3.x Pages Export/Import as production-ready. This is not a ProcessWire 3.x module and will never be. It has no such need . Just in case you forget and try to install it in a ProcessWire 3.x site, the module will throw a WireException(). I will also not be porting the ProcessWire 3.x import functionality for use in ProcessWire 2.x. That will defeat the purpose here; to move sites to ProcessWire 3.x and not the other way round. Supported Fields All non-complex fields such as integer, text, textarea, etc Page fields Repeaters File and Image fields I think these cover most needs. Note: not yet tested with Multilingual fields. Technical To ensure exports will be compatible with ProcessWire 3.x Pages Import, where necessary, the module borrows (and amends as needed) methods from ProcessWire 3.x for use in ProcessWire 2.x. For instance, ProcessWire 3.x Pages Export/Import uses the new(-ish) $file functions found in WireFileTools. Rather than copy and include such files, the module only borrowed and amended needed methods. These are listed below. PagesExport.php From /wire/core/Functions.php: wireInstanceOf(), wireClassName() and wireClassParents() From /wire/core/Fieldtype.php: getImportValueOptions() and getDatabaseSchema() From /wire/core/WireFileTools.php: zip(), chmod() and mkdir() From /wire/core/WireHttp.php: sendFile From /wire/modules/Fieldtype/FieldtypeFile.module: exportValue() and exportDescription() From /wire/modules/Fieldtype/FieldtypeImage.module: exportValue() From /wire/modules/Fieldtype/FieldtypePage.module: exportValue() and exportValuePage() From /wire/modules/Fieldtype/FieldtypeRepeater.module: exportValue() From /wire/core/Fieldtype/WireTempDir.php: create(), createName() and getTempDir() All the export methods from the /wire/core/PagesExportImport.php class ProcessPagesExport.module All the export methods from /wire/modules/process/ProcessPagesExportImport/ProcessPagesExportImport.module Newer methods such as $this->wire() will gracefully degrade to the older wire() function, ensuring smooth and uniform operation in ProcessWire 2.2 - 2.7. Use This module and class is for supersusers only and has only 1 aim; to export ProcessWire 2.x sites ready for importing into ProcessWire 3.x sites. You can either install (like any other module) and use the process module (ProcessPagesExport.module) or skip the install and just include and use the class (PagesExport.php) to export your sites. Both the module (Export GUI) and API require that you are logged in as a supersuser before you can use them. The PagesExport class has a gateway method and option not found in the original class (PagesExportImport). The method export() allows access to the three export methods in the original class, i.e. pagesToArray(), exportJSON() and exportZip(). See example usage below. GUI/Process Module On install, the module will create a new admin page Export Pages. Please note that unlike the original code, this page is created directly under /admin/ and not /admin/pages/. Click on Export Pages to start. Nothing much has changed from the original ProcessPagesExportImport. In older ProcessWire versions where InputfieldSelector was not available, the module will instead present you with a text input to specify a valid (for that version of ProcessWire!) selector for finding pages. The other two methods for adding pages (add pages manually or add by parent) are still available. Custom JS ensures older installs without showIf functionality still get the inputfield dependency treatment. API export($items, $options) PageArray $items: The PageArray to export. Array $options: In addition to the options in the original class that you can pass to pagesToArray(), there are two more options here. mode to specify the export type (array or json or zip) and fieldNamesExclude, to specify fields to exclude from the export. Note that the original class option fieldNames still works. It's for specifying the fields to include in the export. // API USAGE // get and include PagesExport class /* @note: you'll need to include the path differently if you are using the class directly without installing the Process module */ $path = $config->paths->ProcessPagesExport . 'PagesExport.php'; require_once($path); // create new instance of the class $siteExport = new PagesExport(); // find items to export /* a. export whole site! (minus admin and children) careful! in some cases, better to export in batches */ //$items = $pages->get('/')->find('has_parent!=2'); // export a batch of pages $items = $pages->find('template=basic-page|computer'); /* you could also use these methods directly #$data = $siteExport->pagesToArray($items); #$data = $siteExport->exportJSON($items); #$data = $siteExport->exportZIP($items); */ $options = array( // @kongondo addition: export to screen as 'array' or 'json' OR export to zip // zip will be saved in /site/assets/backups/PagesExport/ 'mode' => 'array',// array or json or ZIP // export only these field names, when specified 'fieldNames' => array('images', 'files', 'multi_pages'), // @kongondo addition: exclude fields from export. Here we exclude 'body' field 'fieldNamesExclude' => array('body'), ); // get the export $data = $siteExport->export($items, $options); if(is_array($data)) { echo '<pre> EXPORTED SITE USING pagesToArray '; print_r($data); echo '</pre>'; } // JSON export else echo $data; Screenshots See also the links to Ryan's blog posts above. ProcessWire 2.2 ProcessWire 2.4 ProcessWire 2.5 ProcessWire 2.7 Video Demo (Sorry, long and boring) Demo shows various exports from ProcessWire 2.x and their importing into ProcessWire 3.x. Remember the old Skyscrapers site profile? See how a whole Skyscrapers site gets exported from a ProcessWire 2.7.3 site and imported into a ProcessWire 3.x starting from here.

Module allow you to load events from event files. Visit Github page or module directory for usage

The Twig renderer for Wireframe has been around a while already, it just didn't have a support forum thread of its own, so here we go. This optional add-on module lets one author layouts, views, partials, and component views using Twig instead of PHP. By design you can have view files that are either Twig or PHP — with this module enabled Wireframe will initially look for a .twig file, but if that doesn't exist, it'll fall back to a regular .php file instead. GitHub repository: https://github.com/wireframe-framework/WireframeRendererTwig Composer installation: composer require wireframe-framework/wireframe-twig-renderer Here's a small sample of what Twig looks like: {% if page.numChildren(true) %} <ul class="menu"> {% for child in page.children %} <li> <a href="{{ child.url }}"> {{ child.title }} </a> </li> {% endfor %} </ul> {% endif %} You can read more about Twig from https://twig.symfony.com/doc/. Twig syntax in specific is covered in Twig for Template Designers. For more details about Wireframe renderers and how they are enabled and used, check out https://wireframe-framework.com/docs/view/renderers/.

This module for ProcessWire sends a notification email for each failed login attempt. Similar modules exists already in the module directory of ProcessWire. However, this module is designed to notify, even if specified user doesn't exist. Settings The settings for this module are located in the menu Modules=>Configure=>LoginFailNotifier. Notification email Specifies the email address to which the notification emails should be sent. Email subject Specifies the subject line for the notification email. Post variables Specifies the $_POST variables to be included in the notification email. Each variable must be separated by a comma. For example: login_name,login_pass Server variables Specifies the $_SERVER variables to be included in the notification email. Each variable must be separated by a comma. For example: REMOTE_ADDR,HTTP_USER_AGENT Link to ProcessWire module directory: https://processwire.com/modules/login-fail-notifier/ Link to github.com: https://github.com/techcnet/LoginFailNotifier

Page Field Edit Links GitHub: https://github.com/thetuningspoon/AdminPageFieldEditLinks Direct Download: https://github.com/thetuningspoon/AdminPageFieldEditLinks/archive/master.zip This module is based on--and is the successor to--Macrura's AdminPageSelectEditLinks (https://processwire.com/talk/topic/8477-adminpageselecteditlinks-module-for-enabling-edit-links-on-multipage-selects/) Page Field Edit Links adds modal editing capability to ProcessWire's Page fields in the admin editor, allowing editors to easily view and edit the content of any page(s) that have been selected, as well as create new pages without leaving the current screen. Edit links are updated in real time when new pages are added to the field. Compatible with all available types of Inputfields including Select, SelectMultiple, Checkboxes, Radios, AsmSelect, PageListSelect, PageListSelectMultiple, and PageAutocomplete.

Now in the module directory: https://processwire.com/modules/process-indie-auth/ IndieAuth lets you sign in to applications using your domain name and grant access to read/write to your site. This module adds IndieAuth support to your ProcessWire site, enabling two main things: Authentication: When you visit a site like indielogin.com and enter your domain name, you will be taken to your ProcessWire admin area to sign in and approve the request. If you approve the request, you will be returned to the site and logged in as your domain name. Authorization: When you visit an application like Quill, it needs to also get your permission to post to your site. You will be taken to your ProcessWire admin area to sign in and approve the request/scopes that the app is requesting (create, update, delete, etc.). If you approve the request, you will be returned to the app, logged in as your domain name, and the app will have an access token for your site. Features Browse the applications you have granted access tokens to. See when each one was granted, last used, and will expire. Revoke any application’s access tokens Set the default expiration period for new access tokens. The initial default is 14 days. Automatically remove expired tokens During authorization, confirm and change the scopes granted to the application. For example, an app may request “create” and “delete” scopes, but you can grant only “create.” During authorization, you can also choose to grant an access token with no expiration Installation Navigate to Modules > New. In the Module Class Name field, enter ProcessIndieAuth Copy the template files from the module’s directory /extras/templates into your site’s /site/templates directory. Verify that the plugin installed pages: IndieAuth Metadata Endpoint Authorization Endpoint Token Endpoint Token Revocation Endpoint IndieAuth page under the admin’s Access menu Look up the user(s) that you want to allow to use IndieAuth and assign them the “indieauth” role Update your home page template to add the link elements inside the <head> element: <?=$modules->get('ProcessIndieAuth')->getLinkElements();?> This should result in three <link> elements in the source HTML: <head> <link rel="indieauth-metadata" href="/indieauth-metadata-endpoint/"> <link rel="authorization_endpoint" href="/authorization-endpoint/"> <link rel="token_endpoint" href="/token-endpoint/"> </head> Sign In To test signing in with IndieAuth, visit indielogin.com and enter your domain name. Follow the prompts to authenticate and you should end up back on indielogin.com with a success message. Sign In and Authorize To authorize an application with IndieAuth, your site will first need a module that uses access tokens. I have a Micropub for ProcessWire module in development that does that. Micropub is a standard that lets you publish to your site using third-party clients. If you’d like to try it out, follow the instructions on GitHub to install it. After installing, visit Quill and enter your domain name. Follow the prompts and note the additional fields for “scope” and “expiration,” since you are authorizing an application to interact with your site. After successfully authorizing, try to post a short note from Quill. Quill should redirect you to the new post if it was successful. For a list of other Micropub clients you can try, see https://indieweb.org/Micropub/Clients. Admin and Options In the admin, you can see which applications you have granted access tokens to. You can see when each token was issued, last accessed, and its expiration. You can also manually revoke a token at any time. Navigate to: Access > IndieAuth. There are a couple options in the admin at: Modules > Configure > ProcessIndieAuth: Default access token lifetime (in seconds): This defaults to 14 days and is what appears in the authorization screenshot above. Automatically remove access tokens after expiration (enabled by default): When enabled, the site checks approximately every six hours and removes expired access tokens. Regardless of whether this option is enabled, the module will reject any application attempting to use an expired access token. Since access tokens cannot (currently) have their expiration extended, I recommend keeping this option enabled so the admin list stays tidy and current. Finally, this module writes some admin logs. Access those at: Setup > Logs > indieauth More About IndieAuth If you’re interested in more details about IndieAuth, I recommend the article “OAuth for the Open Web” by Aaron Parecki (or the video presentation). If you are interested in implementing IndieAuth in your project, see the IndieAuth specification. Originally published at: https://gregorlove.com/2022/07/indieauth-for-processwire-released/ Previously: 2021-10-07: This post was originally about alpha testing the plugin before I submitted it to the modules directory.

Wondering how to get that A+ rating on Mozilla Observatory? Now you can with ⭐⭐⭐MarkupContentSecurityPolicy⭐⭐⭐ Of course, MarkupContentSecurityPolicy does not guarantee an A+ rating, but it does help you implement a Content Security Policy for your ProcessWire website. Markup Content Security Policy Configure and implement a Content Security Policy for all front-end HTML pages. This module should only be used in production once it has been fully tested in development. Implementing a Content Security Policy on a site without testing will almost certainly break something! Overview Website Security Auditing Tools such as Mozilla Observatory will only return a high score if a Content Security Policy is implemented. It is therefore desirable to implement one. A common way of adding the Content-Security-Policy header would be to add it to the .htaccess file in the site's root directory. However, this means the policy would also cover the ProcessWire admin, and this limits the level of security policy you can add. The solution is to use the <meta> element to configure a policy, for example: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">. MarkupContentSecurityPolicy places this element with your configured policy at the beginning of the <head> element on each HTML page of your site. There are some limitations to using the <meta> element: Not all directives are allowed. These include frame-ancestors, report-uri, and sandbox. The Content-Security-Policy-Report-Only header is not supported, so is not available for use by this module. Configuration To configure this module, go to Modules > Configure > MarkupContentSecurityPolicy. Directives The most commonly used directives are listed, with a field for each. The placeholder values given are examples, not suggestions, but they may provide a useful starting point. You will almost certainly need to use 'unsafe-inline' in the style-src directive as this is required by some modules (e.g. TextformatterVideoEmbed) or frameworks such as UIkit. Should you wish to add any other directives not listed, you can do so by adding them in Any other directives. Please refer to these links for more information on how to configure your policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://scotthelme.co.uk/content-security-policy-an-introduction/ https://developers.google.com/web/fundamentals/security/csp/ Violation Reporting Because the report-uri directive is not available, when Violation Reporting is enabled a script is added to the <head>which listens for a SecurityPolicyViolationEvent. This script is based on https://developer.mozilla.org/en-US/docs/Web/API/SecurityPolicyViolationEvent and POSTs the generated report to ?csp-violations=1. The module then logs the violation report to csp-violations. Unfortunately, most of the violations that are reported are false positives, and not actual attempts to violate the policy. These are most likely from browser extensions and are not easy to determine and filter. For this reason, there is no option for the report to be emailed when a policy is violated. Instead, you can specify an endpoint for the report to be sent to. This allows you to handle additional reporting in a way that meets your needs. For example, you may want to log all reports in a central location and send out an email once a day to an administrator notifying them of all sites with violations since the last email. Retrieving the Report To retrieve the report at your endpoint, the following can be used: $report = file_get_contents("php://input"); if(!empty($report)) { $report = json_decode($report, 1); if(isset($report) && is_array($report) && isset($report["documentURI"])) { // Do something } } Debug Mode When this is enabled, a range of information is logged to markup-content-security-policy. This is probably most useful when debugging a reporting endpoint. Additional .htaccess Rules To get an A+ score on Mozilla Observatory, besides using HTTPS and enabling the HSTS header, you can also place the following prior to ProcessWire's htaccess directives: Header set Content-Security-Policy "frame-ancestors 'self'" Header set Referrer-Policy "no-referrer-when-downgrade" Installation Download the zip file at Github or clone the repo into your site/modules directory. If you downloaded the zip file, extract it in your sites/modules directory. In your admin, go to Modules > Refresh, then Modules > New, then click on the Install button for this module. ProcessWire >= 3.0.123 is required to use this module.

This module enables Selectize (which is bundled with the PW core) on all Select and AsmSelect inputfields in the PW admin. As described below in the readme, Selectize is initialised/destroyed as the revelant select is focused/blurred in order to support select options that change after the page is loaded. Therefore Selectize is styled to match the AdminThemeUikit select as closely as possible to minimise the visual change as the select is focused and blurred. I'm developing on Windows so I'm not sure how the module will render on other operating systems. It doesn't help that the PW admin uses different fonts depending on the OS - I wish PW would bundle its own webfont for a standardised appearance everywhere. Incidentally, I was a bit disappointed with the state of the Selectize project. I had to fix or work around a number of bugs and shortcomings, including things you would think would just work out of the box such as disabled options, matching the width of the replaced select, or the standard select behaviour where a selection is required when there is no empty option. The Selectize issues repo is full of arbitrarily closed bug reports and pull requests and there are no updates for the last 6 years. I've tried to catch everything that would affect this module but I wouldn't be surprised if there are still some bugs. Selectize All Enables Selectize on all InputfieldSelect and InputfieldAsmSelect fields in the ProcessWire admin. The module activates Selectize on the <select> element when it is focused, and destroys Selectize when the element is blurred. This allows Selectize to work on selects where the options are changed dynamically after page load depending on other field values, e.g. the "Select File" field in the CKEditor link modal or a dependent select in Page Edit. Only AdminThemeUikit is tested and supported. Usage In the module config you can choose if Selectize should be used with InputfieldSelect, InputfieldAsmSelect, or both. If you want to disable the module for a specific Select or AsmSelect inputfield you can hook SelectizeAll::allowSelectize. This method receives the Inputfield object as the first argument. Example: $wire->addHookAfter('SelectizeAll::allowSelectize', function(HookEvent $event) { $inputfield = $event->arguments(0); // You can also get any associated Page and Field objects via $inputfield->hasPage and $inputfield->hasField // Disable the module for the inputfield named "template" if($inputfield->name === 'template') $event->return = false; }); https://github.com/Toutouwai/SelectizeAll https://processwire.com/modules/selectize-all/

Modules directory: https://processwire.com/modules/page-render-find-replace/ GitHub: https://github.com/teppokoivula/PageRenderFindReplace This module applies replacement patterns defined via TextformatterFindReplace globally to page rendering. All the heavy lifting is done by TextformatterFindReplace (thanks, Ryan!) so this module is just a wrapper around said module plus a bunch of config settings — a few options for selecting matching pages, an option to log replacements as they happen, etc. Long story short, on recent projects I've been running into issues with temporary (development) domain creeping into URLs here and there. While not a major issue, this is annoying and takes some time to correct. Originally I was thinking of building a module that would handle text replacements and log them so that they can be manually fixed later, but TextformatterFindReplace already handles the replacement part quite nicely, so I figured I'd just make use of it, apply replacements to rendered page content instead of individual fields (works better for my use cases, where content is often rather dynamic), and add some logging. Hope someone will find this useful. Please note, though, that this module is not well tested yet so there may be bugs etc. ?

Here's a small new module that started as a spinoff of a memcache proof-of-concept. Cache your strings and partials in-memory using Redis as a backend. CacheRedis All you need is a running Redis database. The module supports connection through regular TCP, over TLS and via unix domain sockets. Host and port are configurable, and authentication is supported too. Here's a screenshot of the module configuration options: I'll not go into too many details about the usage, you can see everything explained in the README on GitHub, and just highlight the most important points. When the module is active, you'll have a wired $redis variable, which means you can reach the module as $redis, wire("redis") or within Wire classes / modules as $this->redis. CacheRedis is strongly influenced by WireCache, and its usage is (hopefully) straight forward. // Store an entry in the cache under the given key name with the given value: $redis->store("cached_value_number_one", $expire, $value); // Retrieve a value from the cache $value = $redis->fetch($key); // Delete a cache entry $redis->delete("my_other_cached_value"); // Clear the whole cache $redis->flush(); // Retrieve a value from the cache, and if not found, create it through the given function // and store it with a lifetime of 5 minutes (300 seconds) $value = $redis->fetch($key, 300, function() use($page) { return "Page last changed on " . strftime('%m/%d/%Y %H:%M', $page->modified | $page->created); }); // Render a file using wireRenderFile and store it in the cache. // We'll pass a selector as the expiry value so this cache gets // emptied every time a page matching the selector is saved. $news = $redis->renderFile("partials/news.php", 'template=blog-post', ["page" => $page]); The module is still very crude work in progress, but I hope some of you feel daring, try it out and let me know in case anything breaks. Have fun!

The Module Blog for ProcessWire replicates and extends the popular Blog Profile. Blog is now in version 2. Please read the README in the Github link below in its entirety before using this module As of 20 December 2017 ProcessWire versions earlier than 3.x are not supported Blog Documentation is here (Work in Progress!) See this post for new features in version 2 or the readme in GitHub. To upgrade from version 1, see these instructions. ################################################## Most of the text below refers to Blog version 1 (left here for posterity). Blog version 1 consists of two modules: ProcessBlog: Manage Blog in the backend/Admin. MarkupBlog: Display Blog in the frontend. Being a module, Blog can be installed in both fresh and existing sites. Note, however, that presently, ProcessBlog is not compatible with existing installs of the Blog Profile. This is because of various structural and naming differences in respect of Fields, Templates, Template Files and Pages. If there is demand for such compatibility, I will code a separate version for managing Blog Profile installs. In order to use the 'Recent Tweets Widget', you will need to separately install and setup the module 'MarkupTwitterFeed'. Please read the README in the Github link below in its entirety before using this module (especially the bit about the Pages, etc. created by the module). I'll appreciate Beta testers, thanks! Stable release works fine. Download Modules Directory: http://modules.processwire.com/modules/process-blog/ Github: https://github.com/kongondo/Blog You can also install from right within your ProcessWire install. Screenshots (Blog version 1) Video Demos ProcessBlog MarkupBlog Credits Ryan Cramer The Alpha Testers and 'Critics' License GPL2

I am a noob at this framework. While looking for dynamic options I found many modules have options/settings in the module. While I wanted to develop a module I found that I lack the knowledge of adding options in a module setting page. How to add options (radio buttons,selectors) in my processwire module?

ProcessWire 3.x markup module for rendering meta tags in HTML document head section. Note that this module is not a full-blown SEO solution, but rather a simple tool for rendering meta tags based on module configuration. Adding custom meta tags is also supported. Built-in meta tags The following meta tags are supported out-of-the-box: Document title consisting of page title and site name Character set Canonical Viewport Description Keywords Hreflang tags Open Graph og:title og:site_name og:type og:url og:description og:image og:image:width og:image:height Twitter meta tags twitter:card twitter:site twitter:creator twitter:title twitter:description twitter:image Facebook meta tags fb:app_id The full documentation with configurable options can be found here: https://github.com/Fokke-/MarkupMetadata Requirements: ProcessWire>=3.0.0 PHP >=7.1 Installation using Composer composer require fokke/markup-metadata Manual installation Download latest version from https://github.com/Fokke-/MarkupMetadata/archive/master.zip Extract module files to site/modules/MarkupMetadata directory.

GitHub: https://github.com/Toutouwai/TemplatesChildPages For any page, allows the restricting of templates that may be used for child pages. Usage Install the TemplatesChildPages module. The module adds an AsmSelect inputfield "Template restrictions for children" on the Children tab of Page Edit. Use the inputfield to select from existing templates and any child pages added subsequently will be limited to those selected templates. Note that any template restrictions added via this module are in addition to any "Family" restrictions set for the child and parent templates. In other words, if template Family restrictions prevent a template being selected for a given page you can't override this simply by including the template in the parent's "Template restrictions for children" field. Why use this module? The module allows you to add child page template restrictions without having to create new or duplicate templates for the parent page. This forum post explains the situation well. Similarly, it makes it possible to use the "Add New" page feature without an unnecessary proliferation of templates. If you specify a single template as restriction for child pages you can add a Page Add Bookmark for that parent page that allows site editors to easily add a new page using the right template for the location.