Leaderboard

All of this week’s dev branch core commits are from today, though some were worked on throughout the week. There's a mix of issue fixes and worthwhile new features. The InputfieldTextTags now can handle a couple more situations than it could before, such as single-Page selection mode and numeric-only tags, when used as an input type for Page fields. Another worthwhile addition is that ProcessWire now compares the PHP time to the database time once per superuser session and alerts you when they differ. It also provides some instruction on how to fix that situation. This prevents you from getting strange page modification times like "3 hours from now" when you just saved, and similar cases, for when the DB time happens to differ from the PHP time. (Thanks to @bernhard for the suggestion). This week's update is a day early because I've got to pick up my daughter from camp tomorrow and it's a couple of states away, so I'll be on the road tomorrow rather than at the computer. I hope you have a great weekend!

DaCha is a water sports center in Egypt and a hotel. https://surfdacha.com/en/ Multi-language. The backend implements the management of customer reservations and bookings. Naturally, the website is made on ProcessWire. UiKit 3 layout Modules: LoginRegisterPro, Cookie Management Banner, Map Marker, FrontendForms, Markup Sitemap XML, Video embed for YouTube (and Vimeo), Tracy Debugger. The backend implements the management of customer reservations and bookings.

I think you could use an inputfield dependency for this, with the "forpage" keyword: https://github.com/processwire/processwire/pull/255

Have a safe road trip! Make it a memorable drive back with your daughter, too, and enjoy the weekend! Thanks for the suggestion on the time fix, @bernhard! I'd seen it a bunch of times but never realized it was a mismatch. Good catch! Looking forward to checking the commit logs, especially for the InputfieldTextTags.

If you want to avoid the extra burden of maintaining this on multiple translation services, I think it's best as an add-on. Although I've made everything baked-in for now, I'm looking at the api reference for google and we could abstract and make a DTO for both, however it looks like the implementation would be way more complex on google's side, starting by the fact that the endpoint is not even the same api version. The more I think about it, the more I think I'm overcomplicating things. The way I see it that would be the easiest: I would make a new client for deepl and can already access the account type and api key from your package's config. I would not need to hook into Fluency for managing it. Anything done programmatically to translate, I already can use the public translate() method by adding the glossary id to the options['requestParameters'] The only thing I need to hook on in Fluency would be the "Translate to all languages" field link and rebind a new ajax call with the glossary id to the request parameters, I have not tried but it seems feasible. So then there should not be any need to make anything public or hookable!

It's not likely to change without the developer consciously doing so, but $config->http404PageID is much more expressive than "27" anyway.

Hey @FireWire First of all, thanks a lot for this amazing module! I'm currently working on a project with Fluency + DeepL that needs the glossary feature: https://developers.deepl.com/docs/api-reference/glossaries/openapi-spec-for-glossary-management Since glossaries created on the DeepL website cannot be accessed by the API, they need to be sent to the API with ProcessWire, and translation calls need to have a param with the glossary id for every language pairs. I have most of the work done, and I'd be willing to share it once I clean it up, however I'm not sure how to go about this. My first instinct was to do a stand-alone module with Fluency as a dependency, however I can see that it is heavily locked down with final classes + private and unhookable methods. I'm wondering if there's some interest for this, and if yes, you'd rather have a pull request with the DeepL Glossary feature baked-in, or a pull request which would open up some classes / methods to be extendable, which would allow me to make a new module? Thanks!

I'll have a chat with some of the mods about what we do with it as I don't have time to manage it any more and it needs updating - has done for years.

IconsFilter A module for ProcessWire CMS/CMF that enables filtering of icons by name in the InputfieldIcon view. Usage Install the IconsFilter module. Navigate to the Icon section in the Basics tab of field or template settings. Click on 'Show All Icons'. Use the filter input at the top right to search for icons by name. Credits Special thanks to the original author, Robin Sallis for creating this module.

https://processwire.com/api/ref/sanitizer/entities-markdown/

Thanks for the quick help! After doing all the suggested steps I finally found the problem and the solution: Ryan had posted an update of the Combo module which I installed and now it works. As the problem probably existed for a longer time all the data is gone, but at least I can continue working now.

@gornycreative I've uploaded a new version of the module to the dev branch in the repository and it would be great if you can take it for a spin. The UI is fixed so that the field renders with the correct styling. Working with the values introduced some new opportunities and I took some notes from the feedback on the FormBuilderHtmx module on return values. The new rendering options are: Form ID or null when no form is selected (int) Form name or null when no form is selected FormBuilder form object or null when no form is selected Adding the ability to work with the FormBuilder object directly affords some extra utility, it's a direct passthrough in that FieldtypeFormSelect retrieves and returns the form that $forms would have had you done that manually. This was in lieu of using a Page select field since Pages and Forms are retrieved differently. Examples are included on form config pages. I kept the Form ID option as default to help prevent a breaking change, but I haven't directly tested this version against the last version so let me know if you run into any issues. Download from dev, I'll push a new version if everything works out well.

We're planning for paranormal circumstances here.

The core dev branch version has been bumped up to 3.0.240 this week. As always, see @teppo's excellent ProcessWire Weekly for details on what has been added recently. More can also be found in the commit log. This week adds the ability to hook into ProcessWire's admin live search to add your own custom results. This is useful for modules or for your own hooks placed in /site/templates/admin.php. Previously, only modules implementing the SearchableModule interface could manipulate the admin search engine results. Now there's another even simpler way to do it. We'll focus on examples placed in /site/templates/admin.php, but they could also go in /site/ready.php, /site/init.php or in an autoload module's init() or ready() method. The following is a simple example for when one types "today" into the search engine, it returns search results of pages that were modified today. $wire->addHook('ProcessPageSearchLive::findCustom', function(HookEvent $event) { $data = $event->arguments(0); // array $search = $event->object; // ProcesPageSearchLive $group = 'Pages modified today'; // description of this type of search if($data['q'] === 'today') { $items = $event->wire()->pages->find("modified>=today, include=unpublished"); foreach($items as $item) { $search->addResult($group, $item->title, $item->editUrl); } } }); The point of that example is just to demonstrate something simple. In reality, that example isn't that useful because you can already type "modified>=today" to get the same results in the search engine. So let's look at a potentially more useful example. There have recently been requests for better "id" search support in the search engine. In this next example, we add support for "id=123" searches, where it will match templates, fields or pages having id "123" (or whatever ID you specify). Further, it will also support it if you just type "123" on its own. Here's how we might accomplish that below. We'll limit this particular type of search to the superuser since this hook doesn't have any access control checking. if($user->isSuperuser()) { $wire->addHook('ProcessPageSearchLive::findCustom', function(HookEvent $e) { $search = $e->object; /** @var ProcessPageSearchLive $search */ $data = $e->arguments(0); /** @var array $data Search data */ $type = $data['type']; // what to search $q = $data['q']; // search query text // support search of "id=123" or just "123" // skip search if not an "id" search, or query is not a number if(($type != 'id' && !empty($type)) || !ctype_digit($q)) return; // reduce default search operator "%=" to just "=" (if used) $operator = trim($data['operator'], '%'); // search for id in templates, fields and pages foreach(['templates', 'fields', 'pages' ] as $apiVarName) { $apiVar = $e->wire($apiVarName); // get API var $selector = "id$operator$q"; // selector i.e. id=123 or id<10, etc. // some additional considerations for page ID searches if($apiVarName === 'pages') { // PW already handles "id=123" for pages, so skip that kind if($type === 'id' && $operator === '=') continue; // add more to selector for page searches $selector .= ", include=all, limit=$data[limit], start=$data[start]"; } // find by selector $items = $apiVar->find($selector); // tell ProcessPageSearch which results we found foreach($items as $item) { $title = $item->get('title|label|name'); $url = $item->editUrl(); $search->addResult($apiVarName, $title, $url); } // optionally return false to tell it to stop searching after this hook // which would prevent the default behavior of the search engine // $e->return = false; } }); } As you may (or not) know, the search engine displays help if you type the word "help". Help for the search engine usually consists of example searches and descriptions of what those examples do. If we want to add some help for our example above, we could add this to to the top of our hook above, perhaps right after the $data = $e->arguments(0); line: if(!empty($data['help'])) { return $search->addHelp('ID Search Help', [ 'id=1234' => 'Find templates, fields, pages with id 1234', '1234' => 'Same as above but “id=” is optional', ]); } That's the gist of it. These are fairly basic examples but hopefully communicate enough to show that you can add any kind of results you want into the search engine. Right now it's pretty simple and enables anyone with a ProcessWire site to add custom results into the admin live search. But if you find your needs go beyond this, the SearchableModule interface does support more options too. It's also worth using TracyDebugger to examine the $data array that the hook receives, as there are several other things in there you may find useful as well. Thanks for reading and have a great weekend!

@Matzn although the OP didn't specify, I'm assuming that the included content is coming from the same domain and therefore it's not a cross-origin problem, @Liam88 let us know if that's not the case. @Matzn's #5 suggestion is worth a try, you can use either <object> or <embed> instead of <iframe> but you can't populate it using a literal chunk of HTML, which is what I assume you're getting from `<?=$page->landing_page_html?>'`, you'll need to provide a URL that returns the content, so something like... <div> <embed type="text/html" src="<?= $pages->get('/landing-page/')->url ?>" width="600" height="400" /> </div> or <div> <object type="text/html" data="<?= $pages->get('/landing-page/')->url ?>" width="600" height="400"></object> </div>

This week I'm releasing the ProcessWire Fieldtype/Inputfield module "Functional Fields" as open source in the modules directory. This was originally built in 2017 for ProFields, but hasn't required much in terms of support resources, so I thought I should release this newest version (v4) publicly. While this module is completely different from other Fieldtypes, I think it's quite useful and fulfills some needs better than other Field options. Give it a try and please let me know what you think. For an introduction to Functional Fields, please revisit this blog post which covers all the details: https://processwire.com/blog/posts/functional-fields/ Functional Fields is available for download in the modules directory here: https://processwire.com/modules/fieldtype-functional/ Thanks and have a great weekend!

For me too. In the past I had to manage a Contao website and Contao is since version 4 build on Symfony. So you have to use Composer for almost everything, as far as I know. They have a tool Contao-Manager which provides a GUI instead of using the CLI, but its better if you are very experienced with Composer. This website in particular had many extensions and dependencies, some of them were discontinued, which could easily break the complete Composer setup and with that the whole website. I had spend hours and days just to init, rebuild, upgrade the composer dependencies, just to get the website running on my local environment. I am glad that ProcessWire websites cannot break this easily and I don't have to be a Symfony/Composer master just to install modules. ? Of course as you can tell I am biased and maybe not experienced enough with Contao and Composer. To be fair, you can in theory install extensions in Contao without Composer. Also this just could have been a problem of this particular website.

Honestly, the fact that PW does not require composer is a selling point for me. I develop on multiple hardware, depending on where I'm at (home on my gaming machine, at work on a business class PC, or on my 2011-era Macbook Air) - all running a Docker-based solution with shared file access to a Dropbox instance (in other words: very slow access to host OS files in the virtualized host OS). It took well over an hour for my Macbook Air to finish its composer install of Statamic. When the non-composer version of it was available, it took a little over a minute to unpack everything. There are absolutely massive benefits to standing on the work of others who have come before, but the massive inclusion of unnecessary code also exists (and @wbmnfktr already mentioned the additional attack vectors and need to keep things up-to-date, and how things can break from dependencies). I'm always concerned with one small included library in a composer setup getting a repository pull request from a bad actor that gets accepted...and then any/all platforms that use that little library (and keep up-to-date) are now essentially, unknowingly, vulnerable. I'm glad that ProcessWire offers both options. Having a composer option is awesome. When solutions don't offer a simple alternative to composer, it just sucks (for me). I wish I had more to provide in terms of similar CMSs to compare to ProcessWire, but the only ones I'm aware of, and I don't even entirely consider them all too similar, have already been mentioned. ? Some features of Grav CMS, maybe, are comparable in terms of its intention for customization.

Whether or not the system is built on top of a framework is, in my opinion, largely irrelevant. Or perhaps it would be better to say that "it is impossible to guess if and how it would've mattered in the big picture". Call me cynical, but dependencies are never free. Each adds weight to the codebase, requires upkeep and maintenance (sometimes including major updates or rewrites), and increases potential attack surface. Also many dependencies — and especially frameworks — bring in their own way of doing things, and since ProcessWire's architecture (hooks, data structure, etc.) is really a major selling point for the system, using a framework could've had a massive impact on that. Part of the reason why ProcessWire is such a brilliant system could very well be due to it not being powered by a framework itself. This means that every decision could be made without considering how that would fit the framework. What is also interesting, in my openiin, is the framework landscape itself. Back when ProcessWire 2.0 was launched, Laravel — now considered the latest state of the art PHP framework — wasn't even around yet. Zend Framework was probably the biggest name back then, or at least the one that most serious developers considered "most likely to thrive and stay around"... yet it was discontinued. Had ProcessWire gone with the "safe bet", that would've meant a big rewrite later, or alternatively staying on a platform that is merely a shadow of its former glory. Long story short, I think Ryan made a good choice ? Don't get me wrong, though: I'm a big fan of the Composer ecosystem — almost all of my modules are available as Composer dependencies, etc. And, in my opinion, ProcessWire actually integrates quite nicely with external dependencies. Since HTTP clients were mentioned, I'll use that as an example as well: in some recent projects I've used Guzzle together with ProcessWire. I may not be able to (easily) swap the client used by the core itself, but I've yet to come across such a need anyway. Of course this comes with a cost: I recently had to migrate one project to a new server simply because a third party dependency decided to drop PHP 7.4 support. In a minor version, because why the heck not. Not that it's a bad thing necessarily to bump up the PHP version, but having to do that sort of thing in a hurry just because I prefer to use a recent and patched version of a dependency is just bollocks. This is starting to get a bit rambly, so I'll just leave it here.

Yes, I misunderstood the initial post. Marco has been in contact via PM and has supplied me with additional details that I've added to the opening post.

In addition to my comment, this might be a nice addition: https://openalternative.co/categories/cms And yes... ProcessWire is not listed yet anywhere. We should add it there, shouldn't we? Or maybe @ryan himself. Just asking. https://openalternative.co/submit

Customized templates and fields Each and every content type only has the fields it really needs. Books, companies, recipes - it doesn't matter what kind of data my clients or I have to deal with. The templates and fields will reflect that. Therefore clients don't even have to learn anything in regards to creating or editing data. Super easy. It's typesafe (by my definition) We can discuss the meaning of 'typesafe' here but... I think ProcessWire is somewhat typesafe because I define each field, template, relationship, and almost everything else. I know where to expect what kind of data and know what data is allowed in which field. No guessing, no errors. (Sure this depends on your setup and your will to invest some time.) Works perfectly fine for non-developers I won't call myself a coder or programmer - I just tinker around with code and have fun. When I started using ProcessWire, getting around was super easy, and learning the fundamentals took only a day or two. From there on, it was easy-going. It's impressive what you can achieve with only some if/foreach/echo in PHP/ProcessWire. I said it a few years back and still stand behind it: ProcessWire seems to be the easiest way to learn and work with PHP. Low maintenance There are ProcessWire projects of mine that haven't been updated in the last 5+ years and still work without any PHP or security issues. The moment a project is finished and works without flaws it will do so for a very long time. There is no real need to update a project. Small footprint, high performance A ProcessWire website doesn't need that much of a big hosting package. The moment you start using Core cache functionalities or even ProCache most websites are fine and ready for an average amount of traffic. Maybe not ready for a slashdot/reddit/ProductHunt-peak but that's a totally different story. I can get so much out of ProcessWire compared to WordPress (and others I used/tested in the past). ZIP downloads and no real need for a package manager What I really love and enjoy is that you can get everything as a ZIP file, unpack those, move them around and do whatever you want or need with them. Not needing NPM or composer to get started - like in the good old days - is just perfect. In the last 1-2 years I did a lot with NPM due to 11ty and Astro, yet an old-school ZIP file has its very own charme. For comparison: Installing CraftCMS feels good and really nice, yet I absolute don't know what's happening, what is needed, and so on. It's like a blackbox. It works but I don't know why. I hate that.

Hi all, This one is special because it's for a project of ours, Erika and mine. http://muesli-cafe.com/ We are starting a crowdfunding campaign to open a breakfast place in Porto where we will serve muesli. This is quite a bold attempt because muesli is not common at all in Portugal and it will take a good communication effort from our part. We will need all the help we can get, if you guys want to contribute here's the project's crowdfunding page http://ppl.com.pt/en/prj/muesli-cafe-porto and you will be all welcome to Porto to taste our delicacies It will be great if we make it

Love the concept. I haven't any spare cache, but if you want any thing cooking/serving wise, let me know. Send me more info and I will put it on my food blog, however http://foodloversdiary.com EDIT: hahaha - I mean CASH, not cache!

I created an empty language pack. Go to: Admin > Setup > Languages Create a new language Drag & Drop the attached zip-file in the Language Translation Files Field. Start to edit the files. empty-lang_pack_pw_3.0.41.zip EDIT: Obsolete in latest PW Versions. Create a language pack by your own. Go to: Admin > Setup > Languages > Add New Save Press button: 'Find Files to Translate' Select all files in the box 'Translatable files in /wire/' Select files in the box 'Translatable files in /site/' which you want to add to your custom language pack Press 'Submit' Start translating Download zip or csv file by pressing the related button at the bottom of the page where translatable files are listed. Done