Leaderboard

WebP to JPG Converts WebP images to JPG format on upload. This allows the converted image to be used in ProcessWire image fields, seeing as WebP is not supported as a source image format. Config You can set the quality (0 – 100) to be used for the JPG conversion in the module config. Usage You must set your image fields to allow the webp file extension, otherwise the upload of WebP images will be blocked before this module has a chance to convert the images to JPG format. https://github.com/Toutouwai/WebpToJpg https://processwire.com/modules/webp-to-jpg/

For those who just want to let users upload WEBP format and are looking for a workaround, here is a simple module that converts WEBP to JPG on upload: I wonder though... how is it that the user acquired the WEBP image in the first place? Surely they didn't just pinch it off somebody else's website... ?

This seems to imply that the version of FieldtypeFile in memory is still at 3.0.146, since getValidFileExtensions was added in release 3.0.167. Clean out site/assets/cache/FileCompiler and make sure that FieldtypeFile is in fact found at wire/modules/FieldtypeFile.

Thanks @monollonom, though as per @androbey's suggestion the conditional is not necessary if the username matches the folder name and can be used directly to construct a path. On a side note, I wasn't aware that fieldTemplates was a thing until I saw your post so I've learned something very useful :-)

Following steps: Download the latest stable version of PW here Unzip the files Rename index.php > index_new.php and wire folder to wire_new Upload the files via FTP to your website root folder Rename ./index.php to ./.BAK.index.php and ./wire/ to ./.BAK.wire/ on server side Rename ./index_new.php > ./index.php and ./wire_new/ to ./wire/ Refresh the whole site > you maybe forced to relogin. Reload the modules by clicking the button on example.com/processwire/modules/ in the upper right corner After that you could use the ProcessWireUpgrade module to upgrade the other modules. Steps are also documented here: https://processwire.com/docs/start/install/upgrade/ if you have troubles have a look right here: https://processwire.com/docs/start/install/troubleshooting/#troubleshooting-upgrades Cheers ?

Maybe I am not understanding what you want but this screen recording shows it working on the frontend.

@gebeer We're running the module on a couple of sites on PHP 8.0 and 8.1 with no issues. If you do find any issues running on PHP 8+, open an issue on GitHub or let me know here and I will fix it as soon as possible!

In this case, best is to simply go with either an "if" or "switch" statement, something like: $datum = $concert->date; $format = "E, d. LLLL yyyy, HH:mm"; switch($user->language->name) { case "deutsch": $lang = "de-DE"; $format = "EE dd.MM.YYYY"; break; case "français": $lang = "fr_FR"; break; case "default": $lang = "en_US"; break; } $fmt = new \IntlDateFormatter($lang, \IntlDateFormatter::FULL); $fmt->setPattern($format); echo $fmt->format($datum);

It's crazy sometimes how quickly the work week goes by. On Monday I started working on a Stripe Checkout integration for a client (using the FormBuilderProcessorStripe module), and somehow today I'm still working on it, and it feels like only a day has passed. This particular integration is a little more complicated than others I've worked on. The user makes a few selections that determine the final price, and when they submit the form, it has to authorize (but not yet capture) the amount due, so that the money is basically in a holding state. Then it has to send a notification to another company asking them to approve or deny the request. If they approve it, then it captures those funds through Stripe. Or if they deny it, then it releases the hold on those funds. It's also connected to multiple Stripe accounts in different currencies, and it has to use whichever one corresponds with the transaction details. In this particular form, some of the purchases also involve a 3rd party web service to confirm availability. And there's more to it as well, but I'll leave it at that... it's just a lot of moving parts, so I guess that's why I haven't done anything this week other than work on that. But the good news is that much of it has been added to the FormBuilderProcessorStripe module, so that the next this time need comes up for you or me, hopefully it won't take so much time. Here's a few of the things that have been added to FormBuilderProcessorStripe: Previously you could just accept a payment. Now you also have the option to setup a separate authorization and capture. And you can capture from a newly added API method, from the FormBuilder entries screen, or from our Stripe dashboard. On the API side, all you need to complete the capture is the ID of the payment (called the payment intent ID), which is saved with the form entry. The capture typically must be done within 7 days of the authorization. Doing an authorization (and later capture) is preferable to a charge when you think there's a reasonable chance the it'll need to be un-done. One reason is because an authorization costs nothing, whereas a charge (or capture) does, regardless of whether it is refunded. The module also has a new option to create a Customer in Stripe that you can charge later. This is different from authorization/capture in that creating a customer doesn't authorize any particular transaction or funds, but rather saves their payment info in Stripe, enabling you to charge it anytime later. This is useful for many cases, but one would be where a customer wants to save their payment information with their account, so they don't have to re-enter it every time they make a purchase. Several new configuration options were also added. New public API methods were added for capture, cancel and refund payments. You can now pass any data from the form into Stripe metadata. You can now specify the Stripe API version that you want to use with the module. And you can now send email receipts, even if not enabled in Stripe. More transaction information is now shown when using the "view entry" in the admin. Several new hooks were also added. Technically this update to FormBuilderProcessorStripe is ready to post now, but I'd like to do a little more testing first, so I'll be posting this module update in the FormBuilder board next week. I also have some updates to the InputfieldFormBuilderStripe module as well (which uses Stripe Elements rather than Stripe Checkout), and it may be updated at the same time, or shortly after. No core updates this week, but hopefully I got enough client work done this week that I can really focus on the core next week. Thanks for reading and have a great weekend!

I want to show you a project that I started developing in summer of 2022 and that went online in january 2023. Kulturhaus Wilster ("Arts Centre Wilster") https://www.kulturhauswilster.de The Kulturhaus Wilster - also called "Wilster's living room" by many visitors - is a socio-cultural center in the heart of Wilster. Wilster is a small City located north from Hamburg, germany. Despite the fact that this is a small venue they offer large amount of events. The events range all the way from concerts to theatre and everything inbetween! The old version of the site was a super simple WordPress website in a black-and-white only color scheme. In my opinion it did no justice to the very colorful program that the Kulturhaus offers so I tried my best to bring some color into the game. The whole website should have a shabby-chique look combined with clean, modern elements. The Homepage offers a preview of the next 8 upcoming events. A blog section is also included and the latest post is displayed next to the event calendar book as PDF download. The event pages offer a quick-reservation form (tickets are not sold online) and a quick look to the next upcoming events in the sidebar. The website features a large event calendar. It was a really nice exercise in using ProcessWires very own paging and selector features. Events can be searched and filtered by type (and month), too. All with a few lines of code only. For example "Look for events that take place in the future in a specific category" $events = $pages->find("select_event_cat.title~|%=$c, template=event, date_event>=today, sort=date_event, sort=time_from, limit=6"); Besides that the website features some colorful content pages with large images, galleries, textboxes and some teaser elements. The editors of the website are able to display all facets of the Kulturhaus this way. Tech Talk: Frontend Framework is Bootstrap 4.6 ProcessWire Modules used on this one are: - WireMail: SMTP (https://processwire.com/modules/wire-mail-smtp/) - SEO Maestro (https://processwire.com/modules/seo-maestro/) - All in one minify for asses (https://processwire.com/modules/all-in-one-minify/) - PageImageSource for webp image srcsets (https://processwire.com/modules/pageimage-source/) - JkPublishPages is used for time-controlled publishing of the blog posts. Please check out this module! Thanks @Juergen - @bernhards great RockFrontend was also used. In this particular project only the autorefresh feature (because this module was brandnew back then and development of the page was almost done). But even "only" using autorefresh makes it worth using it! Please have a look:

I originally developed and launched Real SF Properties in 2015 and did a complete design and programming refresh in 2022: https://realsfproperties.com/ The site was designed by BuzzCandy.Design: http://buzzcandy.design/ This was my first time using Tailwind CSS and it was a great fit for this project. I wish it existed back in 2015 because while UIkit has been my go-to CSS framework for several years now, there are some site designs (and designers) that I work with that simply need a higher level of precision to slice correctly and be maintainable. Sure, I could have used vanilla CSS and done it the classic way (separation of concerns), but Tailwind CSS and doing everything with utility classes (locality of behavior) does come with major benefits, even if the markup is not so easy on the eyes. This site does not use a matrix page builder or anything fancy. The sections are hardcoded but with the ability to add data using the various page data structures that feed in accordingly. It has also has an accessibility score that is extremely high. It's a quick loading site even though ProCache or CDN is not yet enabled. Other frontend libraries include Flickity and Headroom.js. More details on my personal website: https://jonathanlahijani.com/projects/real-sf-properties/

Thank you for your reply @horst. Exactly, the module "Animated GIF Image Sizer" was shipped within the PW core. This is how i installed it: In the backend i went to module > core. Then I scrolled to the module "Animated GIF Image Sizer", then clicked on the "Install" Button next to it. Then the module page opened and I clicked on the "Submit" Button in the upper right corner. OK, I tried enabled the debug mode, then deleted the cached versions of the GIF, and reloaded the frontend in order to re-regenerate the resized GIF. It's strange, because in setup > logs > image-sizer I am getting this message which seems to be fine: AnimatedGif Resized: rocket.gif => rocket.453x575.gif (453x575) 0.1704 secs 154457 => 36848 bytes (quality=80, sharpening=soft) I am not getting any error messages or something, but the resized GIF is still not animated. Any idea, what it could be?

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.

Hey @Robin S - I just wanted to remind everyone how awesome this is It can reduce the number of required templates (and template files) substantially in some cases where you have a standard setup, but with some minor differences to the fields in each template. Of course you could take it to extremes and have just one template per site, so you need to be careful to find the right balance, but it's a really powerful addition to PW IMO. Thanks again!

v0.0.2 released - a complete overhaul of the module. Custom Inputfield Dependencies now does the same thing but in a completely different way (thanks to a great idea from @adrian) The module no longer requires Hanna Code and inputfield dependencies are now set on the "Input" tab of "Edit Field". See the first post for all the details. If you are using v0.0.1 of the module then this is a breaking change and you will need to redefine your dependencies (sorry ). But the new approach taken in v0.0.2 is so much better that hopefully you'll find the change worthwhile.

Thank you very much - has a wrong encoding on my PHP Editor setup....so you saved my day! Best regards mr-fan

Attachments work very well using this mailer. I'm using it to send out event photos to purchasers - nice, nice, nice. Thanks for the work on this, Horst!

First off, I won't stop developing ProcessWire unless I'm dead. But lets say that one of you showed up at my door and shot me, and then I'm gone for good. This is free software and you don't get any guarantees there, no matter what CMS it is or how big the community or adoption of it is. But what you do get is the source code and permission to use it and do with it what you need to. There is far more security in that than any proprietary or commercial system. We should all feel very lucky that this project has attracted such a capable development community around it (more than any project I've ever seen), and there are several guys here that are fully capable of taking over the project if I go down in a hang-glider crash. I'm always reluctant to list off people because there are so many people that contribute to the core and I don't want to forget anyone. Suffice to say, I may hold the keys to the master GitHub account, but this is a project of many developers, at least 5 of which are fully capable of taking over the project if I kick the bucket. I'm certain that some of these guys could do better than me with it. Please don't take that as an invitation to show up at my door with a weapon. But I would suggest this may be better odds than with the bigger projects you'd mentioned. Lets also point out here that ProcessWire is not WordPress–it does not need daily updating in order to keep running. Most sites I build with ProcessWire are running the version they are launched with. With ProcessWire, you do not need to upgrade your site every time a new version comes out. You can generally upload it and forget it, and it'll keep running till the site as long as the server itself is running. What other CMS can you say that for? (I can't think of any) Personally, I think adoption of something like Drupal, Typo3, Joomla, etc. is more of a risk, because you are dealing with a legacy platform – you are adopting technology from 10 years ago. You are also adopting something that is a target for hackers and spammers. WordPress is perhaps the biggest target, and something I've very apprehensive to setup for clients. Ultimately when a company chooses to adopt a legacy platform because "it's what the clients know" or [more likely] what they themselves know, it's a lazy decision. It's not looking out for the clients' best interests, and it's pursuing mediocrity. When you pursue mediocrity, you pay for it in the long run. There is no better testament to that than the legacy platforms that agency seems attached to. 1-3 years after installing [Drupal/Joomla/Typo3/WordPress/etc.] for the client, they are going to be looking for "something different" in terms of the CMS (we all know this) and they won't be coming back to the same agency. The agency that thinks it's playing it safe is really just hurting themselves when they give their clients something tired and mediocre that anyone can give them. Instead, give them ProcessWire, and they'll know you are different and better (a secret their competition does not have), and they'll be a lifetime client.