Leaderboard

I hope you all have had a good start to 2020! Last week's release of the new master ProcessWire version 3.0.148 has gone smoothly, and if you haven't yet upgraded, it's a good time to do so. This week I've been working to finish up the new front-end file upload field called InputfieldFrontendFile, which is part of the LoginRegisterPro module package. I've released beta version 1 of that module in the LoginRegisterPro support board in the downloads topic, so it's ready for download now, as is a new version of LoginRegisterPro to accompany it. Today, I've written up a lot about this module, as well as posted a few screenshots here: Front-end file uploads with InputfieldFrontendFile module I've also got some ProcessWire core updates in progress this week for the dev branch, but this week has gone by so quickly I think I'll have to save those for next week. Thanks for reading and have a great weekend!

ProcessWire Dashboard Download You can find the latest release on Github. Documentation Check out the documentation to get started. This is where you'll find information about included panel types and configuration options. Custom Panels The goal was to make it simple to create custom panels. The easiest way to do that is to use the panel type template and have it render a file in your templates folder. This might be enough for 80% of all use cases. For anything more complex (FormBuilder submissions? Comments? Live chat?), you can add new panel types by creating modules that extend the DashboardPanel base class. Check out the documentation on custom panels or take a look at the HelloWorld panel to get started. I'm happy to merge any user-created modules into the main repo if they might be useful to more than a few people. Roadmap Panel types Google Analytics Draft At a glance / Page counter 404s Layout options Render multiple tabs per panel Chart panel load chart data from JS file (currently passed as PHP array)

This module is inspired by and similar to the Template Stubs module. The author of that module has not been active in the PW community for several years now and parts of the code for that module didn't make sense to me, so I decided to create my own module. Auto Template Stubs has only been tested with PhpStorm because that is the IDE that I use. Auto Template Stubs Automatically creates stub files for templates when fields or fieldgroups are saved. Stub files are useful if you are using an IDE (e.g. PhpStorm) that provides code assistance - the stub files let the IDE know what fields exist in each template and what data type each field returns. Depending on your IDE's features you get benefits such as code completion for field names as you type, type inference, inspection, documentation, etc. Installation Install the Auto Template Stubs module. Configuration You can change the class name prefix setting in the module config if you like. It's good to use a class name prefix because it reduces the chance that the class name will clash with an existing class name. The directory path used to store the stub files is configurable. There is a checkbox to manually trigger the regeneration of all stub files if needed. Usage Add a line near the top of each of your template files to tell your IDE what stub class name to associate with the $page variable within the template file. For example, with the default class name prefix you would add the following line at the top of the home.php template file: /** @var tpl_home $page */ Now enjoy code completion, etc, in your IDE. Adding data types for non-core Fieldtype modules The module includes the data types returned by all the core Fieldtype modules. If you want to add data types returned by one or more non-core Fieldtype modules then you can hook the AutoTemplateStubs::getReturnTypes() method. For example, in /site/ready.php: // Add data types for some non-core Fieldtype modules $wire->addHookAfter('AutoTemplateStubs::getReturnTypes', function(HookEvent $event) { $extra_types = [ 'FieldtypeDecimal' => 'string', 'FieldtypeLeafletMapMarker' => 'LeafletMapMarker', 'FieldtypeRepeaterMatrix' => 'RepeaterMatrixPageArray', 'FieldtypeTable' => 'TableRows', ]; $event->return = $event->return + $extra_types; }); Credits Inspired by and much credit to the Template Stubs module by mindplay.dk. https://github.com/Toutouwai/AutoTemplateStubs https://modules.processwire.com/modules/auto-template-stubs/

My desktop Chrome doesn't show it either, but my iPad Mini does... The problem lies in your CSS. Remove the height:auto from the audio element. Mhh.... the height:auto comes from uikit.min.css... however, I do a lot of audio elements on my websites and I never specify a height. Let the browser decide it!

@teppo has to interview them for ProcessWire Weekly.

Yes the PaymentStripeIntents module does implement their new Intents API and is therfore SCA ready.

I really appreciate your effort and time you put in this.

I checked it and I need to rebuild the profile - I will update Bootstrap to the latest version at the same time as this profile was shipped with the beta version. Stay tuned.

possibly mod security

Thank you both! In the meantime I have found the corresponding line of code in the FieldtypeOptions module. Before saving the options, ProcessWire checks, if the current user is a superuser. So any non superusers cannot save option values (in the current / newest ProcessWire version 3.0.148). So I modified the corresponding if statement, in order to allow users with "field-admin" permission. Thanks again for your suggestions. I took the opportunity to take a closer look at Tracy Debugger and I will definitely keep the page field select module in mind.

You could change your Select Options fields to Page Reference fields. Page Reference fields are more powerful and flexible and the better choice in most cases. One of the advantages is that users can edit, sort, add and remove options for fields simply by working with the pages that represent the options. You can create a References branch in your page tree to hold the option pages for your Page Reference fields, and the Page Field Select Creator module is useful for quickly setting up new fields.

You should check first if this is really a permission issue or something else. Enable Tracy Debugger's user switcher, and then switch to one of those agency accounts and try to reproduce that behavior. Check the browser console for errors, and of course if Tracy is reporting anything.

v0.1.6 released. Adds module config options to override the requirements coming from the password inputfield, so the generator can create stronger passwords than the inputfield requires.

I use page references heavily in my projects. Page Autocomplete has a field (Settings specific to ...) on the Input tab of the field settings page that can be used to specify what fields are used during the query. You can even select multiple fields, e.g. a category_ref_by_id field can specify multiple ID fields. This way you can merge individual data sets into a single one. Each source set can have its own ID, and the ...ref_by_id field can use all of them. I have no plans for the automatic creation of the missing referenced page but it can be achieved very easily. Just create another DataSet using the same CSV file and import the appropriate "category" columns for creating the missing pages. You can also try to use the location attribute in the DataSet config to make a reference to the file uploaded to the original DataSet (see the wiki) to avoid duplicate uploads. If you need to perform these imports automatically you can create two tasks (category import and the original one) and specify a dependency between them (first import categories then the full data set). See Tasker wiki.

I'm also very interested in the backend part and all the security implications it might have, though being absolutely sincere I'm not seeing myself using Delphi. Thanks for your interest in sharing!

I just voted YES because of the backend part ? Thx in advance!

The free edition of Delphi looks interesting, but then I saw the terms - once you generate more than $5000 in revenue per year you have to pay. The community edition of Microsoft Visual Studio doesn't have any revenue limits, although I've had issues with it crashing and corrupting project files, and losing dependencies, so something more reliable might be worth a look. Native apps connected to a REST API are something I've started doing via ASP.Net and Xamarin, but I'd be interested to see how to do it via Processwire, at least for the backend, as I suspect that might be easier to code than ASP.Net. At this stage I don't really need iOS or MacOS, just Android, so I guess I could use Android Studio for the front end. AFAIK, Apple doesn't build devices with integrated barcode scanners without having to write code, but there are Android devices that do, and the scanner simply becomes an alternative input method to the touch screen.

Thanks for reporting back! I just published a new version on GitHub which has some great performance improvements and a lot of other new features! The orders list is now loaded in 1 - 1.5 seconds (instead of 4 seconds). The dashboard is also affected by these changes and should load much faster now!

UPDATE 2019-11-15 In the last 3 weeks I (nearly) finished the complete order handling for store merchants (ProcessWire backend). This includes the following features: search for orders filter orders extensive overview of all order details download of invoices resend invoices to customers refund amounts to customers ... all right from within your ProcessWire backend! That doesn't sound like much, but it was a good piece of work. ? Here is a short clip to demonstrate the new features:

Nginx' performance advantages over Apache were built on three factors: modern-day multiprocessing in the server, a lot less overhead due to reduced functionality and memory caching. Over the last five years, Apache has greatly reduced that gap by adapting Nginx' multiprocessing approach (one keyword there is the event MPM module), so Apache isn't spending most of its time spinning up and tearing down whole server instances anymore. File system access has greatly improved with solid state disks, too. Apache still has a lot more functionality, and its distributed config file approach, most prominently the ability to make configuration changes with a .htaccess file inside the web directories, hurts performance. Its dynamic module loading approach and the dozens of pre-installed modules most distributions ship also take up processing time and memory. Nowadays, Apache can be stripped down a lot and compiled to be head to head with Nginx, though few actually care to do that, since it also means removing functionality one might need in the future. A stock Apache is usually still quite a bit slower and reaches its limits faster (about the factor 2). This becomes an issue under heavy load or on slow machines. Where Nginx still shines brightly is load balancing. Apache can do it too, but with Nginx it is straight forward and well documented, having been there for a long time. For those interested in a bit of (highly subjective) history: for a long time (speak eighties and nineties), the classic forking mechanism that was common on *nix OSes was the way to do multiprocessing in network servers, and therefore in Apache too. This meant spawning a full copy of the server process and initializing it, then tearing it down when the request was done. Apache brought a small revolution to that approach by implementing preforking, meaning to keep spare server instances around to fulfill requests with little delay. After a while, there were other approaches too when faster multiprocessing approaches become part of common operating systems, like multi threading, which is supported by Apache's "worker" multiprocessing module (MPM). There were, however, big caveats with using other MPMs. Since file systems used to be slow, sometimes awfully so, in the old days, and since the classic CGI approach of starting an executable from the file system, supplying it with information through environment variables and standard input and capturing its standard output was a security nightmare - even without thinking about shared hosting - nifty programmers included full languages interpreters inside Apache modules. mod_perl and mod_php became the big thing, the latter coming to dominate the web after a few years. These interpreters, though, often had memory leaks and issues with thread isolation, meaning at best that an error in one thread tore down numerous other sessions and at worst that the server had a propensity for information leaks, remote code execution and privilege escalation attacks, the former security nightmare squared. Thus, these tightly integrated interpreters more or less locked their users into the classic prefork approach where every instance is its own, basically independent process. With PHP as the market leader not evolving in that regard, things were frozen for quite some time. This was when Nginx conquered the market, first by serving static HTML and associated resources with lightning speed (CMSes generating static HTML were still a big thing for a while), but soon by taking care of all the static stuff while handling the dynamic things off to Apache and caching parts of its responses in memory. Finally, though, PHP finally got a fresh boost and grew stable enough for its engine to re-use interpreter instances. It was easier to contain things inside an interpreter-only process instead of dealing with all the server peculiarities, so FastCGI daemons finally became stable, known and used, and suddenly the need to have the language interpreter contained in the web server fell away. Apache got leaner and Nginx more flexible. Caching servers like Varnish became popular since it suddenly was relatively easy to build a fast, nice, layered caching solution with a combination of Nginx, Varnish and a full fledged web server like Apache or IIS, able to serve thousands of highly dynamic and media rich pages per minute. About that time, SSL grew in importance too, and hosting providers learned to love Nginx as a means to route domains to changing backends and provide fast and easily configurable SSL endpoint termination. Over the last years, Nginx got other features like generic TCP protocol load balancing that offset it from other servers and make it more into a one-stop solution for modern web applications. It does boost its popularity that Nginx is often the first (or the first major) web server to ship evolving technologies, making the front pages and pulling in early adopters, http/2 being one of the most prominent examples there.

UPDATE 2019-08-08 The module has made hug steps forward and we are nearing a first beta release version. So for those of you who are interested, I wanted to let you know what happened in the meantime ? The dashboard interface was refined. Currency selector for switching dashboard currency (based on your currency fields) Added dashboard sections for managing Orders, Customers and Products Added a WireTabs interface to easily switch between the different dashboard sections. Orders, Customers and Product-details are opened and edited in ProcessWire Panels Added further properties to SnipCart product anchors like: categories, product dimensions, weight, and so on. Added field selector to SnipWire settings for choosing the desired field (FieldtypePage) to be used for categories handling. Refinded caching behavior. *) *) the proper caching of SnipCart data fetched through their REST API is giving me headaches. I'm still not sure what to cache and how long. For example, think of retrieving the list of purchase orders and creating a pagination. Every single page has to be cached. What if new orders are added when flipping backwards? Then the page numbers could get out of hand. (this only as an example). As SnipCart has relativ slow API response times (about 1.8-2.5 seconds for a request), I'm even thinking about developing a separate background job runner which continuously fetches data from SnipCart and caches it locally. Our SnipWire module could then only use locally stored data only. What needs to be done: As SnipCart has a totally broken presentation of multi currency values in it's dashboard (for example: they simply sum up order values in different currencies!) I need to calculate performance values manually. And this will be a huge job as the data comes from different REST API calls... Orders, Customers and Products detail editors (order status update, setting the order tracking number, add metadata information, creating notifications on the specified orders, ...) Order refunds handling through the SnipWire dashboard Integration of external shipping providers Integration of external taxes providers Subscription handling through the SnipWire dashboard Discount creation and handling through the SnipWire dashboard Documentation, documentation, documentation! and much more ... Here are some fresh screens:

UPDATE 2019-06-15 The taxes repeater field in module config editor was updated: changed to a grid view for more flexibility added field validation prepared the taxes-repeater field code to become a standalone flexible Inputfield module for general use (Array/JSON repeater input field which stores its values in a single text field) The taxes handling is completed! SnipWire now acts as a full flexible taxes-provider for Snipcart (we use Webhooks for this). No configuration needed in Snipcart dashboard. SnipCart orders are now fully working (except shipping handling). The sample shop templates got an update: customer login/logout customer dashboard link/button to view orders history and subscriptions editing of customer profile Other updates and fixes: The SnipWire Dashboard was updated (Charts, Orders, Customers, ...) --> see screenshot below. The Dashboard fetches its data from Snipcart via CURL multi - the response time for a fresh load is now under 2 seconds The Webhooks handler now supports all Snipcart events via hookable methods. Snipwire now supports all major Admin themes (Uikit, Reno and Default) All module classes/files are more structured (e.g. separate helper and service classes) Under the hood many bugs are fixed and code is updated to prevent unexpected errors. Added a crispy SVG logo for all SnipCart back-end pages ? Screen-recording of updated taxes-repeater: Screenshot of SnipWire Dashboard:

I am tempted to add this to Tracy

Just had an idea: what if we created a module that creates some kind of static file that the IDE can read listing all fields of a given template. Maybe we could also extend this module to parse all hooks even for properties that where added via a hook does anyone need a challenge for christmas? to your question, pwuser1 (welcome btw): some use phpstorm, some vscode, some sublime, some atom...