Leaderboard

Goodbye jQuery, Hello Slideshow! UIkit 3 Beta 31 released !

Just a quick update to let you all know that: 1) With lots of help from @gmclelland we have been ticking off a lot of PHP 7.2 errors. Not sure that we have discovered them all yet though, so please let me know if you come across any. 2) I just forced the Validator panel to use the HTML5 version all the time. I was finding the other version wasn't working for some sites. Hopefully this won't cause any problems, but please let me know if you find anything amiss.

Never considered Tracy as a she . But yeah, its a girl's name isn't it. I'm gonna call Tracy a `she` from now on.

This is the new topic for the Settings Factory module (formerly known as Settings Train). Repo: https://github.com/outflux3/SettingsFactory I'm not sure what versions this is compatible with, it has only been tested on 3.x branch; it is not namespaced, and i'm not sure if namespacing is necessary or a benefit for this module; if any namespace or module gurus can weigh in on this, let me know. I'm also not sure if there needs to be a minimum php version; I have one live site using this now and it's working great; But before submitting to mods directory, would be better if there was some additional testing by other users.

File Editor GitHub https://github.com/f-b-g-m/ProcessFileEdit matjazp version https://github.com/matjazpotocnik/ProcessFileEdit A module that allows you to edit file directly in the in the admin area. First module and first time doing a file editor so the way i do it might not be the best. Feedback is welcome. Editor page Setting page

A client of mine was asking for a solution to send newsletter mails to a list of subscribers. I looked around for a module, but couldn't find any. Then I saw a screenshot on this blog post about UIKit update, and decided to recreate it. Huge thanks to @ryan for the inspiration. The module uses regular pages for building HTML content. These pages can be used to create a fallback link in emails (i.e. "Use this link if you can't view email properly"). During render it injects $page->mailerMode, which can be used to change page output between text and HTML, or to show a simplified, email only HTML output. Screenshots: Main screen is just a list of items. Create page: Module configuration page: During installation, module creates a page under admin for storing items similar to FieldtypeRepeater. It also creates some fields for storing mail info Todo: More testing Sending in batches (with a script that runs in background and real-time progress log) Plans: Integration with Mailchimp (for subscriber lists) Automation (as a separate module for creating email content pages) I'm hoping to complete and release the module in the following days. I think these features should be enough for the beginning, but I'm open to suggestions.

This week we've got a new version of ProcessWire 3.0.80. In this post we also look at how to create a language pack, and answer a lot of common questions about Pro module renewals, upgrades and more. Lastly, we take a brief look at the upcoming CKEditor 5. https://processwire.com/blog/posts/pw-3.0.80/

MODULE PREVIEW This is a new module I'm working on, Settings Train. Ever needed to setup one or more pages for site settings, need a lot of fields/settings and an easy way to access them in the front end. This module may be of use to you. You can of course either make an editor page using standard fields for settings, but the goal of this module is to allow files within the template folder to define their own 'dependencies' for settings. Description: this module allows you to create an unlimited number of admin/process pages, and on any process page you can enter the path to a json file that defines the fields to use for the process page. 1.) Contents of kitchen-sink.json [ { "name":"text1", "label":"Text Field 1", "type":"InputfieldText", "width":"100", "description":"", "collapsed":0, "placeholder":"", "value":"", "columnWidth":50 }, { "name":"text2", "label":"Text Field 2", "type":"InputfieldText", "width":"100", "description":"", "collapsed":2, "placeholder":"", "value":"", "columnWidth":50 }, { "name":"select1", "label":"Select Test", "type":"InputfieldSelect", "width":"100", "description":"Description of select 1", "options": { "default":"Default", "blue":"Blue", "red":"Red", "yellow":"Yellow", "dark":"Dark" }, "collapsed":0, "placeholder":"", "value":"", "columnWidth":33 }, { "name":"checkbox1", "label":"Checkbox Test", "type":"InputfieldCheckbox", "width":"50", "description":"Checkbox 1 description", "collapsed":0, "placeholder":"", "value":1, "columnWidth":34 }, { "name":"radios1", "label":"Radios Test", "type":"InputfieldRadios", "width":"50", "description":"", "options":{ "black":"Black", "white":"White" }, "collapsed":0, "placeholder":"", "value":"black", "columnWidth":33 }, { "name":"checkboxes1", "label":"Checkboxes Test 1", "type":"InputfieldCheckboxes", "width":"50", "description":"Checkboxes 1 Description", "options":{ "address":"Address", "phone":"Phone", "social":"Social Icons", "top_menu":"Top Menu" }, "collapsed":0, "placeholder":"", "value":"", "columnWidth":50 }, { "name":"checboxes2", "label":"Checkboxes Test 1", "type":"InputfieldCheckboxes", "width":"50", "description":"Checkboxes 2 Description", "options":{ "address":"Address", "phone":"Phone", "social":"Social Icons", "top_menu":"Top Menu" }, "collapsed":0, "placeholder":"", "value":"", "columnWidth":50 }, { "name":"textarea1", "label":"Textarea Test", "type":"InputfieldTextarea", "width":"100", "description":"Textarea 1 Description", "collapsed":2, "value":"" }, { "name":"pagelistselect1", "label":"Page List Select Test", "type":"InputfieldPageListSelect", "width":"100", "description":"Page List Select Test Description", "collapsed":0, "value":"0", "columnWidth":50 }, { "name":"asm_select1", "label":"ASM Select Test", "type":"InputfieldAsmSelect", "width":"100", "description":"ASM Select (templates) - select a template.", "options":{ "43":"Image", "59":"Options", "61":"Post (post)", "62":"Post Index (post-index)" }, "collapsed":0, "value":"", "columnWidth":50 }, { "name":"url_test", "label":"URL Test", "type":"InputfieldURL", "width":"100", "description":"Enter a URL", "noRelative":1, "collapsed":0, "value":"", "columnWidth":33 }, { "name":"integer_test", "label":"Integer Test", "type":"InputfieldInteger", "width":"100", "description":"Enter an Integer", "collapsed":0, "value":"", "columnWidth":34 }, { "name":"email_test", "label":"Email Test", "type":"InputfieldEmail", "width":"100", "description":"Enter an Email Address", "collapsed":0, "value":"", "columnWidth":33 }, { "name":"ckeditor_test", "label":"CK Editor Test", "type":"InputfieldCKEditor", "width":"100", "description":"Some Formatted Text", "collapsed":0, "value":"" } ] The json file can be anywhere (currently limited to the templates folder). For example, if you have a theme folder and that theme requires specific preferences to be set for that theme, you can have the settings page load the fields needed by that theme. Process Page in Menu: Process Page (editing the settings): Then you can access those settings in your front end like this: $train = $modules->get("SettingsTrain"); $themeSettings = $train->getSettings('news-settings'); the settings are delivered as a WireArray: so you can now do this: echo $newSettings->url_test; which outputs http://processwire.com For rapid site development, this can save you from having to manually setup fields for new projects settings, especially if you use those same settings a lot.

The module evolved from a couple of separate ideas/needs and other modules; First there was the General Settings module, which I used on a few sites and worked well. But that has some problems/caveats/gotchas: 1) by default it uses a $settings global variable that overwrites the Lister Pro settings global $settings; 2) it has limited support for inputfield types (thus why my forked version added support for more field types, collapsed status etc.); 3) you could only have 1 settings page with that module 4) you had to use the module's interface for setting up the fields. So the overall the idea of defining settings fields with json and storing the data inside the module config was inspired by PGS (process general settings). The settings values are stored in the database, in the module config of the main (non process) module. No, no data is stored in the template folder; only the field definitions; this is a feature, not a caveat/limitation. Settings Factory itself is part Warehouse, part Factory, and part Delivery Service.. Factory in that it takes raw materials (the json and php files you have created) and turns those into process pages where you use those inputfields... Warehouse in that it stores those settings values for you, each in it's own array named after your process page. Delivery Service in that is facilitates the retrieval of those settings as a WIreArray or Plain Array (depending on your needs) to the templates; One recent use case of this module is for defining Schema.org values for various Schema types; In this use case, all of the fields are defined in the json field definition file, and then the process module displays the input fields; the Schema rendering function/file reads the SettingsFactory data array straight into the schema (json-ld) since the keys are matching the Schema.org properties; So if you are doing a company site, you can give them a few pages of schema fields to fill out and then create your json-ld from those various arrays.. I think the use case for this module is pretty clear, and really comes down to 1 field, 1 value config settings, or definitions of things like Schema properties; as opposed to real fields that can contain values for that field on multiple pages.

Thank you very much for taking the time to do this! That looks just what I need to point me in the right direction, at least I now have some hope I am starting off in the right direction. I will let you know how I get on and if I get stuck on some aspect of this I will probably be bothering you again... ! Regards - Paul

Yes

Hi Paul, lets try to get started with a basic flow. Create a file called mytable.php in the root directory (along side the index.php file) and paste the following code : Then In your template file put the following code : Hope it get you started.

Great News indeed!

Please try... wire('settings') Note the difference in quotation marks - the forum editor changes single quotes to curly quotes (at least, they look like it to me) Such quotes are not accepted as string markers in PHP, so if you copied-and-pasted directly from Macrura's reply, you would probably get an error like that.

Firstly, sorry about the number of settings in Tracy - that isn't a sign of your lack of PHP knowledge, but rather a sign of my indecisiveness Really this is up to you. I leave it running - it's not accessible to regular users anyway. In production mode it can send you emails when it logs errors. But if you want you can uncheck the "Enable Tracy" option so there is no load at all from it, although it's not noticeable in production mode anyway.

wire(‘settings’) in func/module

Developing a website or whatever without Tracy is for masochists! Sorry I can't resist!

Sorry if it seems like I am promoting Tracy here, but if you were using her, you could just do this in the Console panel and you'd instantly see if $user is an object and what the name of that user is.

Yeah I use it at work, created this with it https://play.google.com/store/apps/details?id=com.interswitchng.ifisagent&hl=en It feels lighter to me than Ionic and faster, and yes it can be built with other frameworks. But TypeScript and NG2 isn't bad though

I ended up going with Settings Factory, since it may just make more sense in the long run. The module is really more of a facilitator to the display of inputfields related to settings, and their subsequent storage and retrieval, so not sure there is any good metaphor that could be used...

You'd have to represent each reaction (e.g. seen, read) using a Page with a user (Page Reference) and a timestamp field (using `created` may suffice) and relate it to an action (e.g. X posted a new picture). Using simple image fields for storing images probably wouldn't be enough. Because images now have to hold a lot more data than they were designed for (when was this image posted, who reacted to it, what was the reaction). You'd need a more complex data structure (using Pages and fields, or custom fieldtypes) to represent all actions, reactions and events. In short: it's not trivial. Or I'm making this complicated in my head.

There exist two Pro modules which will help you to build this e-commerce website. Padloper (already mentioned) and Variations : https://variations.kongondo.com (check the tutorial and the video) Also there are two good reads on Snipcart, a tutorial and a case-study - a must read even if you plan to not use Snipcart: https://snipcart.com/blog/processwire-ecommerce-tutorial https://snipcart.com/blog/case-study-ateliers-fromagers-processwire Welcome to the forum @Samk80 and good day to you

Hey Sam, Welcome! It's definitely possible to build something like that. There's a few reasons why you didn't find an exact module for what you're trying to do. ProcessWire is more of a development framework and toolset than a plug-and-play CMS. It provides you easy access to a relational database, user and session management, querying, and front-end rendering through its API. As that's the case, much of what you want to do – create product records with categories and tagging, and query those records with those fields – can be done pretty easily with native PW functionality. A skeletal walk-through of how you might do this: Create a Product template in the admin. Create the fields you'd like for the Product – probably a Title, Body, Categories, and Tags. The last two could either be hard-coded (as a Select – more rigid) or relational (as a Page Reference/PageArray, using other Pages as data – more flexible). Create Pages with the Product template, and populate the data. Create a Product front-end template, /site/templates/Product.php (file shares the same name as your admin template name), with code like this: <h1><?=$page->title?></h1> <div class="body"> <?=$p->body?> </div> <div class="categories"> <?php foreach ($page->categories as $c): ?> <?=$c->value?> <!-- This is assuming your Categories are a simple Option fieldtype, without titles. --> <?php endforeach ?> </div> <div class="tags"> <?php foreach ($page->tags as $c): ?> <?=$c->title?> <!-- This is assuming your Tags are a Page Reference fieldtype. --> <?php endforeach ?> </div> Edit your front-end home template, /site/templates/home.php, and list some of your Products, maybe like this: <ul> <!-- List pages with Product template, limit results to 10 --> <?php foreach ($pages->find('template=Product, limit=10') as $p): ?> <li> <a href="<?=$p->url?>"> <?=$p->title?> </a> </li> <?php endforeach ?> </ul> That'll get you started with displaying and querying Pages. You might want to take a look at this article to better understand how Templates, Fields, and Pages relate to each other. E-commerce is one of the less well-represented areas of ProcessWire, but is 100% doable. The main bits that don't exist out-of-box are a shopping cart, order management, and the checkout process, but could definitely be built using PW. The module Padloper has both a cart and checkout process. You could get something mostly self-contained like Stripe or Snipcart running within a PW install in short order. Whatever the case, E-commerce in PW, and in fact most systems, will require some development and figuring out. Hope that helps!

If you mean PW in general, then... Add Material Icons: yes Replace FA with Material icons: no While that long list of Material Icons looks nice at first (and I use them often) there is a heap of essential things missing. A couple of random examples: Facebook, external link.

There's nothing to integrate, array-config is a joke repository :), it's just there to show that you can you can return variables from files and use them with include statement, instead of dealing with parsing, validation of JSON/YAML etc. I want the same thing with @adrian, which is essentially how getModuleConfigArray() method of ConfigurableModule interface works. public function getModuleConfigArray() { return [ 'colors' => [ 'type' => 'radios', 'label' => $this->_('Color Set'), 'options' => [ 'classic' => $this->_('Classic'), 'warm' => $this->_('Warm'), 'modern' => $this->_('Modern'), 'futura' => $this->_('Futura') ], 'value' => 'classic', 'optionColumns' => 1 ] ]; } Exactly. Also, I agree with @tpr and @szabesz on the naming. While fa-train looks really smooth, fa-industry or fa-wrench isn't too bad either. We really should switch to Material Icons, though. There's an icon for everything, and every icon is crafted with top notch attention to detail. FA looks quite rough in comparison. Small list of Font Awesome icons can be replaced with their Material counterparts, or both can be combined

Sounds awesome, thanks! How about changing the name to Settings Factory? Train doesn't sound proper to me.

I'm thinking of integrating mailing services like Mailgun, SparkPost, SendGrid (currently working on Mailgun), and their `Mailing List` features via their APIs, because it's much easier to delegate potentially difficult points to a service experienced in this kind of work, instead of using regular SMTP to send emails (not to say I'm discarding SMTP option) Using a mailing service also brings an easier way to add/remove subscribers to a list. With a method like $modules->ProcessMailer->getSubscriptionForm($options), I can return an instance of InputfieldForm, and developers can modify and render it as they see fit. Then I can issue a call to their API and add subscriber to a list.

The basic functionality of the module is great, but I wanted the capacity to add paths, and potentially geometric areas, and the easiest way I found to generate them was using something like Google Earth, or various mobile GPS apps which export KML files. KML files can contain map markers as well, but the module already handles these fine. The Google Maps API allows adding KML layers, and of course Processwire already has a files fieldtype, so it's easy to create a files field that only allows files of type kml. I had to make a few modifications to the FieldTypeMapMarker as well. MarkupGoogleMap.js //Add support for KML overlays, eg exported from Google Earth, or various GPS apps. this.addKml = function (url) { var zIndex = 99999 + this.numMarkers + 1; var layerOptions = { url: url, map: this.map, zIndex: zIndex } var kml = new google.maps.KmlLayer(layerOptions); } MarkupGoogleMap.module I added a 'postinit' property that is output after the map has been rendered. I found that the overlays can only be added after the map has been initialised, so the existing 'init' property didn't work. Here's how I used it in a template: $map = $modules->get('MarkupGoogleMap'); foreach ($page->kml as $kmlFile) { $overlays .= "mgmap1.addKml('$kmlFile->httpUrl'); "; } $content .= $map->render($page, 'location', array('type' => 'ROADMAP', 'postinit' => $overlays)); The code could probably be improved to have the foreach loop inside MarkupGoogleMap.module, and just pass the name of the overlay field if any, but it needs to be optional, as not all maps will have an associated field with kml files.