theoretic

Hi friends! And thanks for Processwire 😉 I have a specific question about PW admin. There's a typical situation when content editors need access to the public page tree only. Ideally, such users should not have the top PW admin menu (Pages, Setup etc.) at all, same for the Admin branch in page tree. Developer users should have everything concerning development (Setup, Modules, maybe Access...) but the public page tree can be limited/restricted for them. It's pretty like how the Admin Restrict Branch module works. But different. Admin Restrict Branch only allows to select a single branch which will be available for certain users. And I'm not sure the ARB will affect the top menu. Is there an existing solution for my request? Or maybe it's time to think about extending the ARB functionality? Many thanks for any possible advice.

Thanks for your interest friends! After some attempts I decided to this the hard way. Here's my working code: $wire->addHookAfter("Pages::cloned", function($event) { $clonePage = $event->arguments(1); $clonePage->of(false); $languages = \ProcessWire\wire('languages'); $emptyLanguageValues = []; foreach($languages as $language) $emptyLanguageValues[$language->name] = ''; foreach( $clonePage->fields as $field ){ switch(true){ case $field->type instanceof \ProcessWire\FieldtypePageTitleLanguage: case $field->type instanceof \ProcessWire\FieldtypeTextLanguage: case $field->type instanceof \ProcessWire\FieldtypeTextareaLanguage: $clonePage->{$field->name}->setLanguageValues($emptyLanguageValues); break; case $field->type instanceof \ProcessWire\FieldtypeInteger: case $field->type instanceof \ProcessWire\FieldtypeFloat: $clonePage->{$field->name} = NULL; break; case $field->type instanceof \ProcessWire\FieldtypeFile: case $field->type instanceof \ProcessWire\FieldtypeImage: $clonePage->$field->deleteAll(); break; case $field->type instanceof \ProcessWire\FieldtypePage: $clonePage->{$field->name}->removeAll(); break; } } $clonePage->save(); $clonePage->of(true); }); This example covers the most used types of data fields. It was enough for me, and it can be extended to include more data fields. By the way, I suppose that it could be a good idea to have a possibility to turn data copy on/off while cloning. But it's in PW core so I don't dare to change this.

Hi friends! And thanks for ProcessWire! Content managers I work with like to create new pages by cloning the old ones. No bad in general, but they frequently forget to check and clean up all the content they copy, especially the multilanguage fields. So I decided to make a hook which should wipe all data fields of a recently created clone immediately after it has been created. Hooking such event is a piece of cake (thanks Processwire!) but cleaning all data fields appears to be a tricky business. Of course I've read this topic but it appears to be irrelevant in my case. My hook is basically like this: $wire->addHookAfter("Pages::cloned", function($event) { $clonePage = $event->arguments(1); $clonePage->of(false); //$clonePage->fields = $clonePage->fields->makeNew(); //fails // ...some more tricks including iterating through all data fields... $clonePage->of(true); $clonePage->save(); } Will be grateful for any possible advice )

Thank You @ryan! Maybe I was slightly wrong. Of course PW is not about "returning html by default". It's a site profile thing, not a core thing. Making an API-dedicated site profile is a perfect idea. Or even an "API + headless CMS" profile. I have seen some API-dedicated PW modules, but, considering the PW architecture, it could be better to have API functionality at site profile level.

I took a look at StaticWire. It's truely a basic SSG, but IMO it's rather a local tool not intended for use in hosting environment. It's okay if You have some hundreds of pages, but what if there's 1000+ of them?.. Generating a lot of static files at once can take too much memory and time, so personally I opted for a lazy static pages generation. Here's my module doing exactly this: https://github.com/theoretic/StaticPages It's open source, and it's free.

Hi friends! And thanks for ProcessWire! Maybe I'm a bit late to the party, but I'd also like to bring some ideas here. Processwire is a great CMS having many brilliant ideas inside. But there's always some space for further improvements. JAMStack paradigm It's about static html pages which have some javascript-driven parts interacting with some APIs and changing their look and feel depending on what users do and which data API provides. Sometimes there's just a single static html page which behaves as a multipage web application, sometimes there are just small dynamic chunks. This approach has many advantages: There's no need to generate pages each time they are requested from server. They can be generated just once. Returning static pages drastically reduces the server loading. Static pages are safe by nature. There's nothing to hack there. And even if someone hacks into the server, there will be only some static html files there. APIs return pure data, no html at all. The most typical API data format is JSON which is pretty compact and human readable already, and there are others (bson etc.) which are even more compact. Processwire vs JAMStack The current ProcessWire is pretty far from JAMStack paradigm: By default, PW is about generating pages on each server request. And, being fair, lots of such pages could be static (generated only once). If someone will take a closer look to how the actual PW admin works, he/she will find that there are ajax-driven things there. But in these cases PW generally returns the chunks of html markup, not pure data. There's no native PW tools providing an easy way to build an API over PW. There are some 3rd part modules, and it's not a rocket science to build a PW-based API from scratch, but no native support out of the box. Processwire as "headless CMS" Headless CMS is a CMS which can only return data, not html. This approach is an important part of JAMStack approach, and there's plenty of such CMSs on the market. PW can be a perfect headless CMS, but it's not by default. You need to build an API on the top of PW to make it "headless". I did this in some of my projects, and I'm quite happy with the result. But, come on, give me a reason why this functionality doesn't deserve to be in the PW core? ) Processwire as "static site generator" (SSG) SSGs are another important part of JAMStack world. They are tools allowing You to make static html files based on the data and the templates You have. Contrary to headless CMSs, SSGs are generally the tools used locally, and the result (static pages) is later uploaded to server. It's quite interesting that PW can be a server-based SSG! I also did this, and I was quite satisfied again. But AFAIK there's no core-level or even 3rd party tools to do this using PW. Bringing the pieces together PW can make a big step from the ol' good paradigm of server-side page rendering to the modern JAMStack. Two things are missing: Native tools for building an API on top of PW. Again, it's doable, but it's not native. A PW-compatible (maybe even PW-based) SSG which won't be a headache. Both things are not rocket science, and they potentially could bring much more attention to PW, make it interesting for younger devels. I had a lot of talk like "ahhh You're that guy from 90ties, still writing php code and making server-rendered pages? You're the past already, man!". Hope this will worth a good discussion ?

Great answer @BitPoet, thanks! Personally I also avoid pasting from Word because the result is, umm, not very well predictable. But my clients ask for that time up to time, so I just wanted to be sure I'm not idiot, and all that copypaste problems are not my problems only.

Hi friends! And thanks for Processwire! Maybe I'm asking a noob question but I couldn't find any clear answer here. Is it possible to paste content from a doc / docx / odt file to a wysiwyg textarea field and to have all images automatically saved to a dedicated image field? Did some experiments, it appears that this may work somehow on MacOS with docx files. But it's definintely not working on Windows, any wysiwyg, any browser. Guess I'm not the only one having this question. Any advice is welcome )

Hi @bartelsmedia! I wrote to You already. I think I have specific skills which can be useful for Your project )

Hi friends! Many thanks for this brilliant module! It appears I've found a heavy issue concerning php 8.3.7 . In brief: Fluency crashes, giving multiple errors of this kind: Uncaught Error: Undefined constant "Fluency\Engines\DeepL\CURLOPT_CONNECTTIMEOUT" in site/modules/Fluency/app/Engines/DeepL/DeepLEngine.php:220 Digging inside reveals the following code sample: $requestConfig = [ CURLOPT_CONNECTTIMEOUT => 5, ... CURLOPT_CONNECTTIMEOUT looks here like a constant, however it's not. PHP 8.3.4 can however handle this kind of arrays, and Fluency works like a charm. But it's not the case for PHP 8.3.7 . I think it's worth taking this into consideration during further development. I've also created an issue on the Github module page. Hope this will help to make this module even better ?

I've found the solution. Hope this will be helpful to someone ) //options for AsmSelect should be (int)key=>value pairs $options = [ 1=>'A value', 15=>'Another value', 200=>'And even more', ]; //default values should be array of keys, not values $defaultValues = [ 15, 200, ]; //options can also be an array of (int)keys $otherOptions = [ 25, 35, 45 ]; ... $config = [ [ 'name' => 'myField', 'type' => 'AsmSelect', 'label' => $this->_('My field'), 'options' => $options, 'value' => $defaultValues, ], ... ];

Hm, not bad, not bad ) Could be a working solution if we'll extend the default Page class with some extra data. Thanks )

Thank You @da²! Both ways are usable. But I still think it's a bit "patchy", especially hardcoding the paths/URLs of the default images. Having a "regular" image inputfield allowing to upload images, add some metadata to them etc. could be a much better solution. That's why I had the idea of creating the second set of per-template fields.

Hi fellas! And thanks for Processwire! Couldn't find myself an answer to a question which appears to be not too complex. I'm developing a configurable module which uses a MyModule.config.php file to store its config fields. I'd like to use the AsmSelect fieldtype with some (maybe dynamic) options there. Basically it's dead simple: $config = [ [ 'name' => 'MyFieldName', 'type' => 'AsmSelect', 'label' => $this->_('My config field'), ], ... ]; This code displays the AsmSelect, but I have no idea how to add options there. Tried some staff like this: $config = [ [ 'name' => 'MyFieldName', 'type' => 'AsmSelect', 'label' => $this->_('My config field'), 'options' => [ 'name1' => 'value1', ], ], ... ]; , but couldn't get any result. I know that it's possible to define config inputfields right inside the .module file, but I'd like to separate the config from module itself (and the MyModule.config.php is a perfect way to do so). So dear Santa, do You have any idea on how to add some options to my inputfield? Thanks in advance )

Hi fellas! And thanks for Processwire! I have an idea which, I suppose, might appear interesting to the PW community. I'd call it "template fields". Come on, we have it already! Any template may have fields, it's Processwire basics. Yes. And no! The fields attached to any template are used with the pages having this template, but not with the template itself. Feel perplexed? A short pseudocode example to explain what I'm trying to say. //one-of-my-templates.php ... foreach( $productPages as $productPage ){ $productImage = $productPage->image? : $productPage->template->image; //outputting some html etc. } ... Default field values (e.g. default images) are not a strong point of Processwire. Okay, we can use 3rd-party modules like @Macrura's Settings Factory (but oops, SF doesn't support image fields). Or we can create a dedicated "defaults" page with dedicated "defaults" template having all necessary fields... hmm, looks like a patch, yes? At last, we can give up and use some hardcoded image urls (yes, it's "patchy" again!). Using a kind of $page->template->image could be a much better solution. Let's imagine a second set of data fields bound to any template. The first one represents the fields used like $page->myfield. The second one could be used in the following way: $page->template->myfield or even $template->myfield. This approach may give us much more flexibility than PW already has, and I don't suppose it should be too complex to implement. Maybe it will be reasonable to make a module offering this new functionality. Think I possibly could do this... but would like to see the community reaction first. So what do You think friend? Is it worth doing or not? Thanks in advance for any opinion.