Leaderboard

This week ProcessWire gained the ability to maintain separate read-only and read-write database connections to optimize scalability, cost and performance. The post covers why this can be so valuable and how to configure it in ProcessWire— https://processwire.com/blog/posts/pw-3.0.175/

/site/modules/MyModule/MyModule.module.php /site/modules/MyModule/FieldtypeMyModule.module.php /site/modules/MyModule/InputfieldMyModule.module.php Then add FieldtypeMyModule and InputfieldMyModule to the "installs" array of MyModule.module.php and MyModule to "required" array of the fieldtype and inputfield.

That did not work in 2014 - maybe it works in 2021 - wow, time flys ? https://processwire.com/talk/topic/7400-instant-processwire-dev-hosting-lightningpw/

I hear what you're saying. I wonder whether it's worth having a look at something like how Umbraco (https://our.umbraco.com/) is structured. It's built on ASP.Net rather than PHP, but next to ProcessWire it would probably be my next most preferred CMS because you can do pretty much anything with it, and a lot of concepts are similar, although I still think ProcessWire overall is easier to work with, looking objectively I think maybe Umbraco has a community and business model that might be worth looking at, as some of what they do might work with ProcessWire. One of the things they do is offer preconfigured hosting with Umbraco installed and maintained, and I wonder if that might be something that could be a source of funds for ProcessWire, and also a way around the idea that ProcessWire is developer focused and not so much for end users. Have a few professional site profiles, and the option for quick deployment and hosting taken care of, and it might be easier to get more people onboard with ProcessWire. I want ProcessWire to thrive, as I enjoy working with it, but clients ask me what happens if something happens to me, so I need to know that it continues to support an active community so that I can reassure clients that there are plenty of people who can support them if for any reason I cease being able to.

One of my first projects with ProcessWire. Online for a while, but still up to date and currently new features are being developed again. The most interesting feature of the site is the integration of the external tool and the PDF creation of the registration form with integrated API connection to always be able to directly output the most current dates. External Service: SEMCO ( https://www.semcosoft.com/de/ ) Used Modules: HannahCode Pages2PDF AIOM+ MarkupSitemap XML and some others In Development: Shop with Padloper Site: https://www.school-dynamic.de/ At this point I like to say Processwire makes it so easy for me to solve even more complicated tasks and get impressive results. Because I must confess, my PHP skills are unfortunately not yet where I would like to be.

A Fieldtype for dynamic options that are generated at runtime via a hook. Configuration Inputfield type You can choose from a range of inputfield types on the Details tab of a Dynamic Options field. Your field will return a string or an array depending on if the selected input field type is for "single item selection" or "multiple item selection". Maximum number of items You can define a maximum number of items the field is allowed to contain. The core inputfields supported by this module will become disabled once the limit is reached. This option is only applicable if you have selected an inputfield type that is for multiple item selection. Format as Pagefile/Pageimage object(s) If the field will store paths/URLs to Pagefiles/Pageimages then you can enable this option to have the formatted value be a Pagefile/Pageimage object for "single" fields or an array of Pagefile/Pageimage objects for "multiple" fields. There is a related Select Images inputfield module that allows you to visually select image thumbnails. Defining selectable options Selectable options for a Dynamic Options field should be set in a FieldtypeDynamicOptions::getSelectableOptions hook in /site/ready.php. The hook should return an array of options as 'value' => 'label'. An example hook is shown on the Details tab of a Dynamic Options field: $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); if($field->name === 'your_field_name') { $event->return = [ 'red' => 'Red', 'green' => 'Green', 'blue' => 'Blue', ]; } }); Formatted value If a Dynamic Options field uses a "single" input type then its formatted value is a string, and if it uses a "multiple" input type then its formatted value is an array. The unformatted value of a Dynamic Options field is always an array. Also see the Configuration section above for description of an option to have the formatted value be Pagefile/Pageimage object(s). Examples of possible uses $wire->addHookAfter('FieldtypeDynamicOptions::getSelectableOptions', function(HookEvent $event) { // The page being edited $page = $event->arguments(0); // The Dynamic Options field $field = $event->arguments(1); // Select from the "files" field on the page if($field->name === 'select_files') { $options = []; foreach($page->files as $file) { // Value is basename, label is description if one exists $options[$file->basename] = $file->get('description|basename'); } $event->return = $options; } // Select from files in a folder if($field->name === 'select_folder_files') { $options = []; $path = $event->wire()->config->paths->root . 'my-folder/'; $files = $event->wire()->files->find($path); foreach($files as $file) { // Value is full path, label is basename $options[$file] = str_replace($path, '', $file); } $event->return = $options; } // Select from non-system templates if($field->name === 'select_template') { $options = []; foreach($event->wire()->templates as $template) { if($template->flags & Template::flagSystem) continue; $options[$template->id] = $template->name; } $event->return = $options; } // Select from non-system fields if($field->name === 'select_field') { $options = []; foreach($event->wire()->fields as $field) { if($field->flags & Field::flagSystem) continue; $options[$field->id] = $field->name; } $event->return = $options; } // Select from FormBuilder forms if($field->name === 'select_formbuilder_form') { $form_names = $event->wire()->forms->getFormNames(); // Use form names as both keys and values $event->return = array_combine($form_names, $form_names); } }); https://github.com/Toutouwai/FieldtypeDynamicOptions https://processwire.com/modules/fieldtype-dynamic-options/

My wife loves to cook, and I always like to further my knowledge around Processwire. So I thought I'll build a small page with the some small function to learn something. Used modules: ProMailer RepeaterMatrix Pages2PDF AIOM and some other litte modules Current functions: JSON-LD for recipes and page search Automatic ingredient calculation when changing the number of servings Creation of a PDF of the recipe Basic PWA (here is something to do, actually) Planned functions: a lot ? Site: https://www.dothiscookingthing.de

@adrian ah that's fantastic! Thanks for your fast reply!

Well, feel free to do so - I'll happily drink them with my friends once the pandemic is over ? http://paypal.me/baumrock Hooking the page edit form is a lot easier: $wire->addHookAfter("ProcessPageEdit::buildForm", function($event) { $form = $event->return; $page = $event->process->getPage(); if($page->template != 'yourtemplate') return; if($f = $form->get('yourfield')) { $f->notes = "Show allergens <a href='/link/to/allergens' class='pw-panel'>here</a>"; $f->entityEncodeText = false; } });

I dont think that is possible as a page needs to be saved once created for the id. However, you can change the name before you first create it.

Thanks for the thoughtful feedback @teppo I used the Renderer::renderTabLabel hook which works great for modifying those tab labels. Regarding the heading stuff, I went with: 'results_heading' => '' and then modifying the group labels and adding those to: 'results_list_group_heading' Now I've got everything looking the way it did before but with the benefit of your core group_by code! Thanks again - this is brilliant.

This week I've been working on something a little different for the core. Specifically, ProcessWire's database class (WireDatabasePDO) has been rewritten to support separate read-only and read-write database connections. Jan, who administers the processwire.com server, asked if I could implement it. I looked into it and thought it had significant benefits for ProcessWire users, so it worked out that now was a good time to implement it. The rewritten database class is actually complete and now running on a live test installation, but I have not yet committed it to the core dev branch because I want to fully document it first. This will happen next week in a blog post. By then I'll have processwire.com using it too. But I can already say that it's a cool thing watching the graphs in AWS show the difference it makes when we start hitting the site with crawlers. You might be wondering what the benefits are in having separate read-only and read-write database connections. I'll get into some of the details next week. But essentially, read-only database connections can scale in a way (and at much lower cost) than read-write connections can. And when using a service like Amazon Aurora, they can scale on-the-fly automatically according to traffic and demand for resources. Not only does it open up the ability for a ProcessWire-powered site to scale much further than before, but it has potential to reduce the costs of doing so by perhaps 50% or more. If you are interested in reading more, we are currently testing the features using Amazon Aurora and RDS Read Replicas (see also Replication with Aurora). However, the ProcessWire core support for this feature is not bound to anything AWS specific and will work with any platform supporting a similar ability. Thanks for reading, I'll have more on this next week, and also have it ready to use should you want to try it out yourself.

Thanks for implementing this Ryan. It was a secret feature request of mine I had wrongfully assumed would be out of scope and will immediately assist me in scaling a PW project I'm working on currently. Well done. ? (Offloading to S3 would also be awesome, anything to make PW more stateless)

I'd say that these are more like two sides of the same coin: You've solved the file issue by directing static file requests to CDN and pointing file related requests to a single (?) master instance. This is of course a valid approach, but in this type of setup you've got at least two types of instances (read and read-write), which can make things more complicated than just replicating a single instance type based on the load, and may not work so well for sites that often require direct access to assets. This could also potentially impact fault tolerance: in case you indeed only have one write instance, that going down for any reason would be a big blow. Most cloud setups I've worked with have handled this the other way around: files offloaded to external buckets and database shared among instances. One benefit of this is that those instances are identical, there's no "master" to rely on. In most cases S3 hasn't had major impact on performance (plus there's always CDN) and I've never run into a case where database would've been an absolute bottleneck. Of course DB requests should be limited: most web requests can be served from static cache, and if advanced caching is needed, in comes Redis. The long story short is that I believe core level ability to store files somewhere other than local disk would be a splendid improvement for cloud use. It's true that you can get past this and it's not strictly necessary in order to run ProcessWire in the cloud, but it would simplify things quite a bit. That being said, I definitely get what you mean by this being the more complex part ? Also, just to be clear, I think that the database abstraction is a great addition!

@monollonom I knew there was a reported PDO issue pending, but didn't remember the details so was going to be looking for it this coming week to make sure it was included (along with any others), thanks for pointing me to it.

Hi Ryan, as part of your rewritting of the WireDatabasePDO class, did you get a chance to have a look at this issue ?

@MrSnoozles @teppo This is not a limiting factor in scalability at least. First off, at least here, the file-based assets are delivered by Cloudfront CDN, so they aren't part of the website traffic in the first place (other than to feed the CDN). If you wanted scalability then you'd likely want a CDN serving your assets whether using S3 or not. But a CDN isn't a necessary part of the equation in our setup either. File systems can be replicated just like databases. That's how this site runs on a load balancer on any number of nodes. Requests that upload files are routed to node A (primary), but all other requests can hit any node that the load balancer decides to route it to. The other nodes are exact copies of the node A file system that update in real time. This is very similar to what's happening with the DB reader (read-only) and writer (read-write) connection I posted about above, where the writer would be node A and there can be any number of readers. Something like S3 doesn't enhance the scalability of any of this. Implementing S3 as a storage option for PW is still part of the plan here, but more for the convenience and usefulness than scalability. You can already use S3 as a storage option in PW if you use one of the methods of mapping directories in your file system to it. But I'm looking to support for it in PW more natively than that. It is admittedly more complex than the DB stuff mentioned above. For instance, we use PHP's PDO class that all DB requests go through, so intercepting and routing them is relatively simple. Whereas in PHP, there is no PDO-type class that the file system API is built around, and instead it is dozens of different procedural functions (which is just fine, until you need to change their behavior). In addition, calls to S3 are more expensive than a file system access, so doing something as simple as getting an image dimensions is no longer a matter of a simple php getimagesize() call. Instead, it's more like making an FTP connection somewhere, FTP'ing the file to your computer, getting the image dimensions, storing them somewhere else, then deleting the image. So meta data like image dimensions needs to be stored somewhere else. PW actually implemented this ability last year (meta data and stored image dimensions). So we've already been making small steps towards S3-type storage, but because the big picture is still pretty broad in scope to implement, it's more of a long term plan. Though maybe one of my clients will tell me they need it next week, in which case it'll become a short term plan. ?

Also interested in this. My impression is that offloading assets to Amazon S3 / Google Cloud Storage etc. is a relatively common need, and there's currently no bulletproof solution. Some third party modules have attempted to, but I'm not sure if any of them really solve all the related needs (image management etc.) — and while remote filesystems such as EFS are easier to work with, they also come with certain downsides (such as a higher price point). I seem to recall that Ryan mentioned something about this a while ago too ?

This is a great feature for larger sites. Really excited about this. Speaking of scaling: I would imagine a limiting factor right now would be, that the uploaded assets are bound to the local drive. Is that a problem for your setup / would proccesswire.com benefit if it was possible to store files on S3? And is there a post somewhere explaining your setup on AWS?

corporate.blue-tomato.com is a new Website about the Corporate behind Blue Tomato. You can find informations about the history and values of Blue Tomato and also all open job positions. Used Modules ProCache ProcessGraphQL (used with React on the job overview page for searching/filtering the jobs) ProFields: Combo ProFields: RepeaterMatrix (Used for some kind of a "PageBuilder") SeoMaestro TemplateEngineSmarty / TemplateEngineFactory

What we need is really easy ways to contribute and build motivation towards contributions. - slack/discord for real-time Comms - merging PRs in the Processwire repo instead of the weird closing the PR and copy pasting it in. I raised a PR years ago, got no feedback and was told it may have fine in via copy and paste. I closed the PR myself to reduce noise and haven't entertained the idea of contributing since. Unless this has changed, start treating it like a modern open source project - roadmap on the GitHub board - indentified maintainers on the GitHub repo - a backlog / causal kanban style agile setup - monthly maintainer video calls to go over backlog etc. Maybe anyone can join. Maybe video recorded. - a patron or way to donate to the PW project. This pot can be used to pay maintainers to work on critical features etc. E.g. through donations with have enough money to fund 1 week of work, what should Ryan / another maintainer take time off their normal work to work on. - key goals established for the core maintainer team. We should as a whole be marching the same direction. (Though obviously people can work on what they want, but has to pass review) - a plan that @ryan is comfortable with to slowly distribute the reigns. We don't want to move too fast and over burden the core. - some sort of backlog voting system, instead of posts on the forum. - Id really like to modernise the process around Processwire. That scares anybody larger than a sole freelancer away from the project. Bigger users mean more support. More pro modules being sold etc. - on that note. Can we have the shop not just be Ryan's modules but extended to other pais for modules. I don't like that they are strewn across the web. (And Ryan charge a fee.)

Great work @kongondo. This looks fantastically feature-filled. You've obviously made a massive investment in this module, especially from a behind the scenes technical point of view. It is a shame in one sense it isn't built out if processwire pages, but it's obviously more powerful or efficient to have escaped the limitations of that setup. My only concern personally is the UI. I do prefer it over the standard UIkit setup of Processwire but I think myself and my clients would prefer they were closer visually to make it more of a seamless experience. I like the siderbar though, I can't think of a PW paradigm you could have used for that. Could you explain the difference between order notes and order comments though? Great works, thumbs up. Tell me where to send the money.

Well basically when you follow the RESTful approach when creating systems, you use resources rather than actions. you can know more here http://restcookbook.com/ http://restpatterns.org/ http://www.restapitutorial.com/ and this books https://leanpub.com/build-apis-you-wont-hate http://www.soa-in-practice.com/ Example if you want to make an admin for the users resource. you can have this URL http://api.example.com/users In the traditional CRUD aproach, the verb is inside the URL like http://api.example.com/users/create but in REST you must use only HTTP Verbs to interact, so the same endpoint url makes different actions depending on the verb used to call it. In our system that could be http://api.example.com/users GET - result in a list of users POST - creates a new user ------------------------------------- http://api.example.com/users/clsource GET - result in the user data PUT - updates the all the data of a specific user PATCH - updates a specific data field of a specific user DELETE - deletes the user Using the HTTP response codes and mime types you can notify the result of an operation, usually with a JSON or XML body for information. The Web services Approach, specially REST web services, enables us to separate complex systems in smaller ones, easier to mantain and test. Basically you can have multiple backend systems that just are APIs and one frontend system that glue them all. this add a layer of security and robustness, because you can separate your systems in different servers. A possible attack can not affect all the system, just small parts of it.