Leaderboard

Hi @bernhard, I did some experimentation with an alternative idea for viewing Process modules on the frontend. I put together a proof-of-concept module you might like to check out: https://github.com/Toutouwai/ProcessFrontendAdminPage Process Frontend Admin Page A demonstration of how a Process module could execute on the frontend. This is just a proof-of-concept. Usage Install the ProcessFrontendAdminPage module. Create a new role named "frontend-only". Give this role the "process-frontend-admin-page" permission and no other permissions. Create a new user named "frontend-only" and give them the "frontend-only" role. View the "Demo frontend admin page" on the frontend while not logged into the PW admin. How the module works On install the module creates a "Demo frontend admin page" under Home. This page uses the admin template with the ProcessFrontendAdminPage process assigned. When this page is viewed by a guest they are silently logged as the "frontend-only" user. This allows them to see the rendered output of the Process module. The header and footer of the admin theme are not rendered when the page is viewed. When a user logged into the "frontend-only" account accesses any other page they are logged out. This is for the sake of logged-out users of other roles, so that when they go to log into the PW admin they don't find themselves already logged in as the "frontend-only" user. Taking the concept further You could embed the ProcessFrontendAdminPage output in an iframe on another page, to preserve a global header/footer and avoid conflicts with the admin CSS. You could add extra markup, Javascript and CSS to the ProcessFrontendAdminPage output to make it look more like the rest of your site. You could create additional executeSomething() methods to render different output depending on URL segment. You could create additional pages within your site that use the admin template and assign the ProcessFrontendAdminPage process. I think you would have to use API code to do this. Then in the execute() method you could check the name of the page being viewed and render different output accordingly.

Tiny explanation: The new directive only creates a fresh instance of a PHP class in memory, in this case a DateTime and a DateTimeZone object. The latter is initialized to 'Europe/Berlin' and used as the timezone parameter for initializing the DateTime object, which, in turn, is stored in variable $ct. Nothing affects the system.

You're all good - it won't affect the PHP / PW timezone. You can test stuff like this yourself - you can see that even though it's outputting the current time in Berlin in the first dump, the default timezone is still America/Los_Angeles

Hey guys, I played around with this idea a little more, because I have 3 projects where I need similar functionality and I really don't want to build all that functionality over and over again for every single project (and all future ones). I created a short screencast that shows how it works. The concept is to hook into ProcessLogin::execute, because this method is what every guest user will see regardless of what admin page he requested: $wire->addHookAfter("ProcessLogin::execute", function(HookEvent $e) { $requestedPage = $this->session->getFor('ProcessPageView', 'loginRequestPageID'); $process = $this->pages->get($requestedPage)->process; $segment = $this->input->urlSegment1; $method = 'execute' . ucfirst($segment); // debug info if(function_exists('bd')) { bd($requestedPage, 'requestedPage'); bd($process, 'process'); bd($segment, 'url segment'); bd($method, 'method'); } // prevent infinite loop if($process == 'ProcessLogin') return; // prevent warning on loginpage without /login urlsegment if($process == 'ProcessPageList') return; try { $e->return = $this->modules->get($process)->{$method}(); } catch (\Exception $e) { $this->error($e->getMessage()); } }); ProcessGuest.module is a simple module that shows that this concept actually works pretty well: <?php namespace ProcessWire; class ProcessGuest extends Process { public static function getModuleInfo() { return array( 'title' => 'GuestAdmin', 'summary' => 'GuestAdmin to ProcessWire', 'version' => 106, 'permission' => 'page-view', 'page' => [ 'name' => 'guest', 'title' => 'Public Guest Page', ], ); } public function execute() { $this->headline('execute()'); $this->wire('processBrowserTitle', 'execute()'); $form = $this->modules->get('InputfieldForm'); // create fieldset $fs = $this->modules->get('InputfieldFieldset'); $fs->label = 'This is a public backend page demo'; // add status inputfield $f = $this->fields->get('title')->getInputfield(new NullPage()); $f->label = 'foo'; $f->columnWidth = 30; $fs->add($f); // add button field $b = $this->modules->get('InputfieldButton'); $b->value = 'Demo button'; $b->icon = 'bolt'; $f = $this->modules->get('InputfieldMarkup'); $f->columnWidth = 70; $f->value = 'Vestibulum rutrum, mi nec elementum vehicula, eros quam gravida nisl, id fringilla neque ante vel mi. Duis leo. Phasellus leo dolor, tempus non, auctor et, hendrerit quis, nisi. Sed aliquam ultrices mauris. Vivamus euismod mauris.<br><br>'; $f->value .= $b->render(); $fs->add($f); $form->add($fs); $form->add([ 'submit' => [ 'type' => 'submit', 'value' => 'submit', ], ]); return $form->render(); } public function executeFoo() { $this->wire('processBrowserTitle', 'executeFoo()'); $this->config->scripts->add('https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.24.0/moment.js'); return 'foo <div id="moment"></div><script>$("#moment").text(moment().format());</script>'; } } See it in action (and notice that the user is NOT logged in): Of course, this is a dirty hack, but it seems to work quite well and it might be good enough for a first proof of concept implementation to get ryans attention about it. What do you think? Unsolved problems so far where I could neet your input: Everything is centered - where does this styling come from? I know that the login-form get's centered, but I didn't find the exact class/script that is responsible for it so I couldn't remove it. Any ideas how we could use a similar technique but with a custom admin url so that we could mask the original admin url of the backend? Maybe hooking into a 404 exception? Or creating a custom frontend page? But how could one render an admin page then? $this->headline() does not work, so there might be other things not working with this technique...

The HTML for these elements is not rendered at all - in AdminThemeUikit at least. See $layout == 'modal' and $adminTheme->isModal here. It's a way of calling protected class methods from hooks. See here.

First off, just increase raw power. Try bumping up your VPS with more power. Easy solution and this stuff is so cheap nowadays. Upgrade the software if possible I've had instances with 300+ fields on a template with more than 500k pages. Queries started to slow down around 200 fields. I bumped the Mariadb version to the latest, switched to INNOdb, PHP 7.2.x and it was running pretty smoother on a digitalocean medium sized VPS ($40/mo). We also had tons of runtime fields and we cached those so a page save would do the calculations instead of calculating runtime. When we eliminated those the application became really snappy with 200-300 concurrent key users doing all kinds of imports and running reports while the 1000 regular concurrent users didn't notice lots of slowdown. Most of the slowdown nowadays come from the interface itself. We used a lot of jQuery kinda tooling inside ProcessWire admin and since the users don't have the fanciest computers, some browsers are not really capable of rendering the back-end. I guess we needed to switch to a SPA, but I'm not working on the project anymore. Jup, this is the key. Especially while desiging applications this is really important. Try to split up as many as you can. I don't store address information on the order, but on the client, and possible even on an address template which you can re-use. You can also use Page fields to combine all those. To comply to GDPR you can also store the blob of address info in one or two fields on the order itself. So if a client requests to remove his data you can easily remove the accoun and associated addresses. And you still have the address data. Another solution is to use the FieldsetPage to create on instance of all address/personal information. In the background PW creates another page containing the info. You add this field to the page once for invoice and once for the shipping info.

Soo, erm, I was running 3.0.125 ? Sorry guys.

Sure that the error refers to RepeaterPageArray in that particular line? Should be RepeaterPage instead. And if it refers to RepeaterPage, are you sure running 3.0.126? Just tried on 3.0.126 and it works as expected.

This looks really promising! What do you think? I'm using this library: https://github.com/davidjbradshaw/iframe-resizer It's as simple as adding your iframe to your frontend: <style>iframe{width: 1px;min-width: 100%;}</style> <iframe id="myIframe" src="/your-public-backend-page/" scrolling="no"></iframe> <script>iFrameResize({ log:true, bodyMargin: '0 0 30px 0', }, '#myIframe')</script> Further improvements could be to sync the page url with the iframe url, but the great thing is: We'd only have to do this once and could use it on all our projects. No matter what frontend we are using! Imagine what a powerful tool this could be: Creating forms, registration pages, carts, event signup pages etc etc., everything as modular and reusable as we know it from the pw backend. And everything instantly styleable via RockSkinUikit ?

Thx Robin, this is (almost) awesome! ? I forked your repo and did two minor changes: I implemented a hookable method to modify the HTML, here to remove the admin url that is exposed in the pw config js object: https://github.com/BernhardBaumrock/ProcessFrontendAdminPage/commit/1fed071d3f951b82fbae6c98b2c4834efec2b6bd I removed the $session->redirect in the processmodule. I guess the reason why you did that was to get rid of the ?modal=1 parameter in the url? The parameter is appended in InputfieldForm when ?modal=1, so I reset this parameter on initialisation of the process: https://github.com/BernhardBaumrock/ProcessFrontendAdminPage/commit/d19f71c03b7169734dca243bc45f35a205782bf3 Do you know how/if we could throw a regular 404 on a Unrecognized path exception in the backend? Thank you very much for your work on this! ?

Quick update Please (whatever deity you choose), I'm close to publishing an alpha version. The PushAlert API is easy. It's the PW integration that challenged me. If you only ever want to capture subscriptions to PushAlert and send notifications carte-blanche via a PW template without capturing stats, and/or sending advanced options, eg to a specific user instead of everybody, the instructions in the PushAlert docs will get you going. This module is more than just a wrapper... more soon including the readme.md (why does that always come last?) Anyone interested in being a guinea pig tester?

You could try https://electronjs.org/ - I haven't tried it yet but I guess this should be quite simple to learn/use for a webdev ?

Hey @bernhard - sorry about that - it didn't work as you expected. Please try the latest version which lets the Console panel work as a guest when you use the "logout" option via the User Switcher and also it now works on localhost when using the "Force guest users into DEVELOPMENT mode on localhost" which should take care of @Robin S's request above. Hopefully the next version will include the new Tracy core features along with some other tweaks - just need to find some time ?

It doesn't work because your wildcard SSL certificate in the format "*.example.com" only matches one "level" of subdomain, so it's not valid for www.subdomain.example.com, see https://serverfault.com/questions/104160/wildcard-ssl-certificate-for-second-level-subdomain The redirect directives look good to me, Apache doesn't care about how many subdomains you're matching in the RewriteCond. But the browser cares about the invalid SSL certificate. The redirection won't work in this case, because the browser won't accept the SSL certificate, as it's not valid for www.subdomain.example.com. Since the SSL handshake and certificate validation takes places before the redirect headers are followed, the browser will show the security warning before doing anything else. I'd wager that if you manually add a security exception, the redirection will work. If you want to redirect https traffic to another https URL, you need a valid certificate for both the domain originally requested by the client and the target of the redirection, or the browser will show the security warning before or after the redirect, so your solution with the additional SSL certificate is the only one that can work. Why do you even need to support the second www subdomain? Sounds like one of "those" client requests ?

Hi everybody, just came up with an idea of a new concept how we could develop our processwire pages... As some of you might know I've developed this module to skin your backend fast and easily: Why? Because several things are a lot quicker and easier to achieve in the backend then rebuilding such admin-tasks in the frontend: User login, profile editing, data presentation with access control. For example, right now I'm building a kind of dashboard for a client where users can book slots for therapies, manage their profile and data etc. This is all done in the backend and users get access after registration. So far, so good... I really like this concept, because modules are clean and especially reusable. There is a standard for how we develop things in the backend. Everything works the same, on every project, on every installation, from any developer. Today I thought: Wouldn't it be great to have those benefits also for several FRONTEND things? Or, in other words, for several parts that need to be available for PUBLIC users (guests)? For example, we could build a shopping cart checkout easily with the tools we already have in the backend. There are several hosted shopping-cart services where you get a hostet checkout-page that does also look a little different than the website's frontend, so I think this would not be a problem for certain tasks (https://foxy-demo.foxycart.com/checkout) The only problem is, that the user would have to register before it could use those tools. So I thought: Is there a possibility to make some areas of the backend available to the public? Is this a good idea at all? Or are we opening security holes there? Isn't FormBuilder doing something similar with the iframe-embed method? This is just an early stage idea, but I'd be happy to hear your thoughts on this. As much as I like ProcessWire, I don't like that I have to build lots of things for the frontend over and over again...

Hi guys and girls Firstly, I can't believe how many posts I have read in your forums, with actual answers......"Proper" actual answers....that answer the question someone had asked. I'm not sure if you guys venture far outside of this forum, but you're not missing anything....It's restored my faith in posting on forums....so I'm looking forward to this experience. OK, where do I start......I have a hybrid "Property Development / Financial Planning / Project Management" business model, which requires: a) A database that can handle complex calculations, fetching data from many different tables for one calculation as well as handling many to many type relationships b) A Customised Project Management system that uses the same tables as the database in a) with the same functionality as MS Project (I've tried them all and nothing tops MSP) c) The ability to use emails (Sent and received) as triggers to trigger workflows d) The ability to "Read" the data contained in an email and trigger events accordingly d) Something I can build and customise myself and e) Everything needs to be self hosted Now, as you can probably gather from my elocution, I'm no IT guru but I am a problem solver. I need complete control over what is displayed, how it is entered and the website itself as the database (I say "database" but the correct term is more than likely "CRM"), The PM system, the reporting tools, the memebrship platform, the emailing system and the website will all be working with the same data....So after 18 mths of looking for a system, I saw Processwire and with my limited knowledge, I thought it looked like the way to go finally. So I have installed it on my CPanel, done the "Hello World" tutorial then wanted to know what direction I take to statr building this Monolith. I have read that there are "Pages with API" or "Tables" and I believe I need to decide as you can't switch easily from one to the other if you change your mind. All I'll need is a little steer in teh right direction, I don't expect someone to provide me the solution I just need someone to point me in the direction. Thanks Legends. Jeremy Allen.

....everyone is so nice here. Hey Psy That was the impression I got by going through all those CMSes. Guys and Girls, a MASSIVE "Thank you" for your (Prompt) advice here, between Bernhard's links and that icing on the cake by Psy, I've gotten further and feel more confident in the past 6 hours than I have with other help forums in the last 2 years....and everything was relevant. JA.

Hi @Steve_Stifler and welcome to ProcessWire Forget the WP model of themes etc that force you into their on-screen boxes. With ProcessWire you have complete control over what goes where & how on the frontend. You design your frontend layout and retrieve the data you need to populate the page in the templates

That's not really true. The number of fields and templates does matter as those will be autoloaded for every request hitting processwire. It's not like 10 fields make a difference, but adding an additional 100 fields or 100 templates can indeed cause a slow down. It's different with pages though. Those are really only loaded on demand.

Hi @Wanze, congrats on your nice module! I'm currently testing it out for a client and find it overall very nice, thank you for your work! I have some feedback, even though I'm not sure if I'm understanding everything you do correctly. So please excuse me if I'm mistaken ? Having to set the default values for the meta tags on the field/template level, instead of using the PageTree (the Page level) seems unpractical. Most of the time I give a site editor access to the PageTree, sometimes to some modules, but I definitely keep them away from 'dangerous' stuff like Fields and Templates. However, editors should always be able to edit the SEO information without bugging the developer for an update. In other words, the preferred place for the default SEO information should imho be at the root of the tree: the homepage. (Or perhaps inside the a module config). To me it would make total sense that SEO information follows the same inheritance structure as pages do. Often rendered titles will consist of a page title and some ancestor title. So you should be able to select the parent's title and expand on it, much like the 'List of fields to display in the admin Page List') -home (title: "My Site") |-projects (title: "Projects") ||-project1 (title: "Project number 1") ||-project2 (title: "Another project") It would make sense to be able to get the following: -home (seo.meta.title: {title} would result in "My Site") |-projects (seo.meta.title: {title} - {parent.title} would result in "Projects - My Site") ||-project1 (seo.meta.title: {title} - {parent.parent.title} would result in "Project number 1 - My Site") ||-project2 (seo.meta.title: {title} | {parent.title} | {parent.parent.title} would result in "Another project | Projects | My Site")

......and within a 2hr window I get a response.....So I'm gathering you've had a thing or two to do with finance type systems Bernhard. I currently have a WP site which my pretty pictures are hosted on (investorhq.com.au) but find it VERY inflexible for placement of anything you want to put on the screen, always having to work within theme that for some reason I can't work out (and even including the "Blank" themes) want to include a sidebar, and some text which I can't get rid of.....anyway, I haven't delved into how to create a front end yet for PW but am I going to experience the same here? I intended to not use tables for reporting and make it more pretty pictures and other distractions.

For PW, that's really nothing. The number of fields, templates or pages is almost irrelevant when it comes to performance. It's mainly what you do with these that can have an impact, i.e. complexity. Do you have complex selectors running? Do you use repeaters excessively? And when you say "page rendering": frontend and backend? Or only one or the other? e.g. what is known to slow page rendering down, is when you have lots of richtext-fields in a page (page-edit view), and lots of repeater/repeater matrix and similar fields. The browser needs some time until all that JS is doing its thing and can start render the DOM... In such cases it's worth to fine-tune field-settings. I would try to copy the whole site somewhere else and compare speed. Maybe switch debug-mode off. Last, but certainly not least, use Tracy Debugger to analyze bottenecks.

.ProcessLogin #pw-content-body { text-align: center; }

Glad you got it sorted. Just thought I'd mention that in addition to the procedural wireRender() file, we also have $files->render() https://processwire.com/api/ref/wire-file-tools/render/

The trick is to set the options AFTER saving the field, otherwise they seem to be overwritten with an empty value. $old_field = $fields->get('abzuege_neu'); d($old_field, 'Field exists'); if ($old_field){ $fields->delete($old_field); } $ja = new SelectableOption(); $ja->title = 'Ja'; // $ja->value = 'Ja'; // only if this should be different from title $nein = new SelectableOption(); $nein->title = 'Nein'; // $nein->value = 'Nein'; // only if this should be different from title $fieldtype = $this->modules->get("FieldtypeOptions"); $field = new Field(); $field->type = $fieldtype; $field->inputfieldClass = 'InputfieldRadios'; $field->optionColumns = true; $field->name = "abzuege_neu"; $field->label = "Abzüge"; $field->save(); // Now add the options to the field $options = $fieldtype->getOptions($field); d($options, "existing options"); $options->removeAll(); $options->add($ja); $options->add($nein); d($options, 'SelectableOptionArray'); // $manager = new SelectableOptionManager(); // $managerOptions = 'option1|Option 1 // option2|Option 2 // option3|Option 3 // '; // you can also set IDs and values if needed // $manager->setOptionsString($field, $managerOptions, false); $fieldtype->addOptions($field, $options); d($field);

Using foreach($page->repeater as $repeaterItem) { echo $repeaterItem->if('inventory<10', 'Low Stock', 'In Stock'); } Will come up with the error that 'if' is not a RepeaterPageArray function.

@Robin S Sorry for the late reply: Your solutions works perfectly. Thanks!

Hey @horst It is solved ? If not, you might could try what is suggested in this answer on StackExchange : https://webmasters.stackexchange.com/questions/116301/how-to-force-ssl-and-www-for-a-subdomain-as-an-independent-domain Edit: ok, didn't read the post's update.

I have developed a site as freelancer for an agency and set it up without the additional www. (And nobody told me that it is needed) when going online, it comes out that they have sent out invitations per email and post with the additional www. in front. So I need to fix it ASAP. ?

@Pete I can build Windows desktop app only or multi-device application if needed, but I cannot start coding something before three weeks. Language used will be C++ or Pascal, so if it is not to far, let's discuss this in PM ?

Great!! Thank you very much, will try it soon ?

Thank you all. Bug report is here: https://github.com/processwire/processwire-issues/issues/817

I've made those changes for you. I guess you couldn't edit because you didn't set an author when you first submitted the module. The interface is pretty clunky at the moment. Hopefully Ryan will improve it with the revamp.

Now I see. It does not show, because I have moved the 404 page under "admin", as suggested by kongondo. If I reparent the 404 Page under "home" again the trashcan is showing for my "editor". Strange. Would you say it's a bug? Shall I report it? Thank you.

Oh, cool! I'l have a look at it and see if it can be used in all admin themes! Thanks!

It's more about server/hosting security than validation as it happens server-side and before any request reaches ProcessWire. ProcessWire works out of the box in about 95-99% situations already. Maybe not in case of NGINX but that's another thing. Knowing more about systems and their configuration isn't a bad thing at all. I don't want to miss anything I know about servers and how to handle them. Have you ever installed Typo3? It is (or at least was) pain in the a** and they still have a nice market share. I'm more afraid of doing my taxes and still I have to deal with it. There are professionals for those things. I wouldn't spend too much time and effort in replacing some lines in the .htaccess file. Why bother with something that's already working almost all of the time? Debugging those installation or migration issues within the core of a CMS is way more difficult than (un-)commenting some lines in a plain-text file. And to be honest... I'm quite shocked that WordPress has just a few lines in its .htaccess. Last but not least... In my opinion: No... I think the .htaccess could do even more in some cases. For example: https://processwire.com/blog/posts/optimizing-404s-in-processwire/

Version Update 1.0.3 The current version 1.0.3 has some minor improvements. Items are inserted at the last position on the target page and set to the status unpublished. Furthermore, the clipboard is synchronized live, so you can jump between browser tabs without reloading the target page, for direct pasting. And the module runs only in the backend in the autoload. > Grap a copy: https://github.com/FlipZoomMedia/InputfieldRepeaterMatrixDublicate

There's a problem with your JavaScript and CSS Files, many 404 Errors (Console output of google chrome): font-awesome.min.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) MarkerCluster.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) MarkerCluster.Default.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) leaflet-providers.js:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) leaflet.awesome-markers.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) leaflet.markercluster.js:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) MarkupLeafletMap.js:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) leaflet.awesome-markers.min.js:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) leaflet-providers.js:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) MarkupLeafletMap.js:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) leaflet.awesome-markers.min.js:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) leaflet.awesome-markers.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) (index):67 Uncaught ReferenceError: jsMarkupLeafletMap is not defined at HTMLDocument.<anonymous> ((index):67) at j (jquery.min.js:2) at Object.fireWith [as resolveWith] (jquery.min.js:2) at Function.ready (jquery.min.js:2) at HTMLDocument.K (jquery.min.js:2) /favicon.ico:1 Failed to load resource: the server responded with a status of 404 (Not Found) font-awesome.min.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) leaflet.awesome-markers.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) MarkerCluster.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) MarkerCluster.Default.css:1 Failed to load resource: the server responded with a status of 404 (Page Not Found) And the links: <link rel="stylesheet" type="text/css" href="/site/modules/FieldtypeLeafletMapMarker/assets/font-awesome-4.6.3/css/font-awesome.min.css"> <!-- Styles supporting the use of Leaflet.js --> <link rel="stylesheet" type="text/css" href="https://unpkg.com/leaflet@1.0.3/dist/leaflet.css" /> <link rel="stylesheet" type="text/css" href="/site/modules/FieldtypeLeafletMapMarker/assets/leaflet-markercluster/MarkerCluster.css" /> <link rel="stylesheet" type="text/css" href="/site/modules/FieldtypeLeafletMapMarker/assets/leaflet-markercluster/MarkerCluster.Default.css" /> <!-- Scripts supporting the use of Leaflet.js --> <script type="text/javascript" src="https://unpkg.com/leaflet@1.0.3/dist/leaflet.js"></script> <script type="text/javascript" src="/site/modules/FieldtypeLeafletMapMarker/assets/leaflet-markercluster/leaflet.markercluster.js"></script> <script type="text/javascript" src="/site/modules/FieldtypeLeafletMapMarker/assets/leaflet-providers/leaflet-providers.js"></script> <script type="text/javascript" src="/site/modules/FieldtypeLeafletMapMarker/MarkupLeafletMap.js"></script> <!-- Extend Leaflet with Awesome.Markers --> <link rel="stylesheet" type="text/css" href="/site/modules/FieldtypeLeafletMapMarker/assets/leaflet-awesome-markers/leaflet.awesome-markers.css" /> <script type="text/javascript" src="/site/modules/FieldtypeLeafletMapMarker/assets/leaflet-awesome-markers/leaflet.awesome-markers.min.js"></script>

That sounds like a reasonable way to return early if the form is not the one you are wanting to modify. Any problems if you do that?

+1 for dropping support. Maybe adding a check before upgrade and showing a warming/hint that older php versions can use the old tracy module (that is already great) with a link where to download it?

See the post below. You can prefix the actual visible date value with a hidden sortable value (e.g. yyyy-mm-dd). Example code here. Follow the $dateSorter variable. The span with class="date-sorter" is hidden in the module's CSS file. The value in the span is the prefix. Sorting will be done based on it.

It looks like there are many settings that can be defined for InputfieldSelector, but only initValue can be set via the FieldtypeSelector field config. For the others you have to use a hook. The previewColumns setting controls the columns shown: $wire->addHookBefore('InputfieldSelector::render', function(HookEvent $event) { /* @var InputfieldSelector $inputfield */ $inputfield = $event->object; // Only for the FieldtypeSelector field of the given name if($inputfield->hasField != 'test_selector') return; // Define the columns you want $inputfield->previewColumns = ['name', 'template', 'modified']; });

OK, I'm back in the office and can share some more thoughts. Thx for your input so far. I'm talking about "no authentication whatsoever", yes. But I'm not talking about "free-for-all-editing". Of course I don't want to have public access to all my pages, that would be nonsense. But I was wondering if it could make sense to have some tools of the backend available to the public. ProcessModules are one example. Forms could be another. I'll explain the idea by examples: Shopping Cart Have you ever developed a shopping cart for one of your clients? It's not that easy, right? You have to take care of data storage (cookies or localstorage or session), you have to take care of the user interface (adding items, removing them, changing amounts etc), you have to make sure everything is safe (sanitization, csrf etc) and so on. This is a lot of work to do and we all know that our website's frontends are all different, so building this for one client would mean that you have to build a lot of this functionality over and over again for the next client. The alternate approach: What if we could build backend modules (process modules) and grant access to guest users? We could build a shopping cart module, that handles all these complicated things for us and uses built in tools, such as csrf, inputfields, routing ( executeFoo(), executeBar() ). It could have expiration features based on the session time. It could make it easy to register new user accounts. It could be And the best: It would be reusable! That's a huge benefit and could make developing several tools so much more efficient and fun (and maintainable). Also think of forms in general. They are always a pain, because they need field validation (front + backend), need to remember their state on failure etc.; This is all already there in the backend! It's just hidden behind a login and I wondered if it couldn't be a huge possibility to bring certain parts of those great featureset to the public. Similar to FormBuilder, as I already stated. Another example: Think of a kind of photo-book service. Users could visit your site, start building their photobook, upload pictures etc.; Just to try things out. It would be great to give those features to your users without any signup process and create the account afterwards. Eg. during checkout.; Or what about a theatre booking service? Display a seatmap, book tickets, show prices, etc: All a LOT to do in the frontend. If we developed a backend-oriented module where we can change colors of links, masthead etc, this would make things so much easier and it would be one click for the next project!! I hope you get my point. Until now, I didn't really think of developing such things in the backend, because I thought it would be a lot more effort to style the backend to my needs than building a new custom frontend solution. But that's totally wrong! It's now really just changing some color codes in LESS when using RockSkinUikit module. These pages could even be loaded in an iframe in the frontend. The height of this iframe could be adjusted via javascript, so the user wouldn't even see that he is actually in the backend. Tools are already there: It's just displaying the admin page with ?modal=1 GET parameter. While thinking of this approach new ideas and possibilities keep popping up in my head: We could build a forum software. It could be a set of process modules, using CKEditor, image upload etc. - but of course only EDITABLE for logged in users. But the thing is: The process-modules (read-only) part would need to be visible also for guests. Building a forum software with ProcessWire as it is (or better to say: as we use it) now, would be a pain, because every installation of PW has a different backend. Moving all parts that can (and should!) be standardized to the backend would be a logical step IMHO. Well... while writing I had another idea: Maybe it would be possible to create a new user + role for such modules, like "public-backend". When a website visitor add's a product to the shopping cart, he could be automatically logged in as user "public-backend". This user could then have access to the process modules that handle all the shopping cart features. We already have the demo-mode of the backend, so I think it should be possible in general to bring non-registered users into the backend. What do you think? Sorry, ideas and visions are quite hard to explain in another language. Did I make things clearer? ?