Leaderboard

The simplest, quickest, and maybe most useful module I've ever built ? TextformatterJsonDecode: Passes the given text through json_decode(), returning the value (if valid) as a stdClass object. Didn't even bother with a README - does what it says on the tin. Ha need one for the modules repo... This is particularly useful if you are storing JSON from an API in a Page field and want to access it in a similar way to normal Page objects e.g. <?php /* The data { "fieldName": "value" } */ echo $page->api_data->fieldName; // value I'll be using this extensively over the next few weeks, looking forward to it ?

@teppoSo far I used the core translation for two of my modules. I had only one to four strings to translate into German, as English was the default. I simply don‘t get used to translate the text inputs via backend form input fields per language, then create a CSV file from it and put it in the language folder of my module or template. Biggest hurdle for me seems that those language files are not automatically detected when another user installs my modele. So I need to guide users of my module how to install the supported module languages after installing my module. I would prefer just to throw in a CSV file per language into my module language folder without the need of a path/domain or hash value at all. So _t("English string") just uses the stuff from my module CSV file and falls back to English if the translation for the user defined language does not exist. Ideally I just copy the English CSV file, translate it to German and store it as de.csv. No need to translate fields via text inputs form elements or to install languages on top of the module installation. Would find it easier to translate just the CSV file e.g. via VS Code or Notepad++. P.S. However I am happy to have a core way build in I by default via _t() function instead of writing my own routine or dealing with language based arrays myself. Just would prefer a simpler way of translating my language files via text editor and to not need to install those files already in the module folder manually.

To add informations on Steve suggestions, and avoid more troubleshooting than necessary, as you are running out of space, the second issue "SQLSTATE[08004] [1040] Too many connections" is certainly due to lack of disk space. The explanation is: lack of disk space make MySQL waiting before INSERT, UPDATE, etc, can complete and then increase the number of pending connections until the limit of `max_connection` is reached. For checking disk usage you might want to use a better tool like duf (muesli/duf/releases) to get a nice insight of disk usage (you will might not be able to install it due to the issue, just remove some log files to get a bit space, you require less than 900kb).

This is a Leaflet version of Ryans Google Maps marker module. @Github

Long and short of this is thank you @kongondo for helping me to rectify the issue with my custom addon (which I will happily share) once done. It was due to me not correctly setting up the necessary methods and properties before installation, so one I knew that my custom addon's main class file was correct, per @kongondo's advice, I simply de-activated and re-activated the module and I am able to access the addone page and fieldname as expected. Big thank you as always dude!

Okay. I'm playing around a little bit with the getCode functions to pull names instead of IDs for certain things and looking at the repeatermatrix situation a little more but I will also look at the tab add situation after.

Hey @gornycreative thx for the question! This is something that I'd like to have but still haven't found time to implement. Maybe you could add a PR? I'm using wrapFields all the time and I'd love to have a setting to make it wrap fields in a tab ?

I'm looking at the code for wrapFields() - is this only for Fieldset and not FieldsetTab? If you are using custom tabs is adding a FieldsetTabOpen field type still recommended and then $rm->addFieldToTemplate('fieldname', 'content-page' , 'tab', 'tab_END'); still the best way to do it?

@joer80 I know it is weird but you can give it a try. Rotate the image twice. Gideon

This has been an issue for a long time but should be fixed since 2022, see https://github.com/processwire/processwire-issues/issues/1154 and let us know more details if anything of the suggested fixes (or simply a core upgrade) works for you.

Hi @snck, The approach here seems odd to me but I'm probably misunderstanding the use case. I'd do: <?php $img->size(800,400)->render( [ 'picture' => true, 'srcset' => [ 'rules' => ['800x400', '1600x800'], 'options' => [ 'upscaling' => true, ], ], 'allSets' => true, 'sizes' => '(max-width: 900px) 100vw, ((min-width: 901px) and (max-width: 1200px)) 67vw, ((min-width: 1201px) and (min-width: 1201px)) 50vw', 'class' => 'hero-img', 'alt' => "...", 'markup' => "<img src={src} alt='{alt}' class='{class}' width={width} height={height}>", ] ); I'd then switch off upscaling to see what that would do. What would you expect the markup to be in this case? Cheers, Chris

Hey - I know how you feel, work is busy here too! I think you're right about the readme, I will update thank you. ?

@kongondo Hmmm, one still doth not follow. I'll private message with further deets I think. There is no rush or obligation to help if you are busy (which I know you are), but I think you'll see what I'm going for ?

Regarding the disk space: Can you SSH in to the server and check the available disk space using the following command `df -h`? Is there still space on the /tmp mount point? (Look for the %use space column in the /tmp row and make sure it isn't full.) To start diagnosing the second issue, you can type "How can I start to diagnose this issue "SQLSTATE[08004] [1040] Too many connections"" into a free chatGPT connector like bingblong. It should give you some solid starting points. Regarding bingblong - it's a good, free connector, but you might want to install ublock origin before you use it. Alternatively just sign up for a regular free chatGPT account.

Ok, it just required a small tweak to the regex that finds the H1 element in the support files (it adds them to that page) and demotes the H1s to styled H2s. In ProField's case, the H1 is not the first line of the readme file - something I was never expecting - so we ended up with multiple H1s in the DOM, with associated styling confusion. Version 0.11.3 should fix it for you.

Good day, everyone! I am happy (and a bit scared) to announce the release of a long awaited new maintenance version for this module. @Mats blessed me to take control over the module. In fact, the repo is moved not to my github account, but rather to an org called Friends of ProcessWire in which there are some brilliant devs already, and maybe more will join. But that is a story for another post I am planning to write soon (a little intrigue))) As for now please test the new 3.0.4 version. It has some code merged from @ukyo (big thanks to him!) and a few lines by myself. I hope that this release does fix a few issues and hopefully not introduce new ones. But I can't be sure here, so changed the stability tag to Beta. Here is the changelog: Now the module uses https://nominatim.openstreetmap.org for all geocoding. Before it still used Google geocoding API in places. Fixed the issue with the map display in admin when the field is in the repeater or in the collapsed fieldset. There is still a problem with ajax tabs. Fixed ProcessWire namespace declaration. Fixed markup in README.txt. Executable bit is removed from all files in the repo. Git branches are renamed to be more familiar. The latest released code is now in the master branch again instead of PW3. The dev is used for current dev. Previously used branches are renamed and kept for now, though will be probably deleted in the future. Updated the module page in the modules directory.

Yeah that's inside a fieldset

This module is an optional (and still somewhat experimental) add-on for SearchEngine. It adds support for indexing file contents, replacing earlier SearchEngine PDF indexer module. Features SearchEngine by itself will only store the name, description, tags, and custom field values for file/image fields. This module, on the other hand, attempts to extract human-readable text from the file itself. As for file types, at least in theory this module supports any filetype that can be reasonably converted to text. It has built-in support (mostly via third party libraries) for... office documents (.doc, .docx, .rtf, .odf), pdf documents (.pdf), spreadsheets (.xls, .xlsx, .ods, .csv) and plain text (.txt). The module also ships with a FileIndexer base class and exposes the SearchEngineFileIndexer::addFileIndexer() method for introducing indexers for file types that are not yet supported. Links GitHub: https://github.com/teppokoivula/SearchEngineFileIndexer Composer: composer require teppokoivula/search-engine-file-indexer Modules directory: https://processwire.com/modules/search-engine-file-indexer/ Getting started install and configure SearchEngine (version 0.34.0 or later), install SearchEngine File Indexer, install third party dependencies — if you installed SearchEngineFileIndexer via Composer you should already have these available, otherwise you'll need to run "composer install" in the SearchEngineFileIndexer module directory, choose which file indexers you'd like to enable. The rest should happen automagically behind the scenes. Additional notes The important thing to note here is that we're going to rely on third party libraries to handle parsing (most) files, and things can still go wrong, so please consider this a beta release. It did work in my early tests, but there's little guarantee that it will work in real life use cases. Just to be safe it is recommended to back up your site before installing and enabling this module. Another thing to keep in mind is that indexing files can be resource intensive and take plenty of time. As such, this module provides some settings for limiting files by size etc. Regardless, this is something that likely needs further consideration in the future; some future version of this module, or an additional add-on module, may e.g. add support for indexing pages/files "lazily" in the background.

I see ProcessWire as a system that you build things on top of, and that's the purpose of it. You don't download ProcessWire to start publishing content in 5 minutes (even if you can), but rather to build a site or application. So ProcessWire is much more of a tool to accomplish some end means, rather than the end means itself. ProcessWire and WordPress are completely different animals in this area (opposites really), and I think it helps to explain why you can't assume that WordPress and ProcessWire would be considered in the same light via the GPL. I think the GPL is flexible enough to handle both. That's not to say we might not switch to MIT in the future, just to avoid even having to talk about it. But I prefer to stick with GPL at this time. When it comes to my own commercial modules, I still consider them open source for the users that have them, and any fees paid are for access to and support of the product. The 1-year timeline applies only to support. You can continue using the products as long as you'd like.

A lot of the hate wordpress gets is from people doing it wrong or being handed a website that was done wrong. The "right" way to do them now is to use a custom fields plugin like metabox and then updates are very similar to a processwire website. There is a custom post type the client accesses and adds posts to, and they dont mess with the design side at all. You can even lock them out of it using roles. You just have to use a little restraint and hit the dynamic data button on your page builder instead of typing it in. And bricks builder is much better than the more popular elementor. Clean code, made in vue3. Even has php blocks. Done the right way takes away many of the arguments people use against it. I can pop one out at $130 an hour using something like frames that has predesigned rows. https://getframes.io/