Leaderboard

After 8 months in development we are excited to bring you ProcessWire 3.0.226 main/master. This version has a ton of great new features, improvements and optimizations, plus more than 100 issue fixes. This post takes an in-depth look at highlights from this great new version. While there's even more in this version than is covered fully here, we hope this gives you a good taste of what you'll find in 3.0.226! https://processwire.com/blog/posts/pw-3.0.226/

The people around might enjoy and maybe even love ProcessWire. As it is free, as in beer and in freedom. At least outside the ProModules and some other third-party modules. Yet, with that background, you probably could make bonus points in one way or another. The ProcessWire docs are probably one of the best, the API is easy to understand even for beginners, and the community is unmatched, absolutely awesome! Probably one of the best around. Another great option for you with ProcessWire could be: ProcessWire is probably the best CMS to run a data-driven website. But back to your questions, and a very warm welcome. Most clients who used and knew about WordPress just knew the name and were told it was awesome. Almost all were annoyed by those upgrades each and every day and that things broke once in a while that resulted in another invoice to fix those issues. So... no, most of my or our clients looked for something that caused less stress and minor headaches. We market our websites as helpers, that do most of the jobs and take care of some parts of the site and even remind editors to do their job. But that's another story. Those who wanted to keep WordPress didn't become clients and were directed to other agencies that knew WordPress. That easy. Some plugins, aka modules, from WordPress would be nice-to-have, yet we have absolutely everything around in one way or another. ProcessWire can do things just with its core capabilities that WordPress needs at least one, two, or even more plugins for. For example: ACF, CustomPostType, Caching. It's all there—maybe no batteries included, but you could just add those/whatever you need, especially in terms of ACF and CustomPostTypes. Caching is a bit more tricky, yet even for beginners, it is quite easy to handle (just like me, years ago, in 2016 or so without almost no knowledge about PHP or ProcessWire). I'd go this far and say ProcessWire is a great way to start a PHP-Dev journey. RockFrontend has an easy built-in page reload on file changes. It's probably my most-needed feature ever. Besides that, I use Rockfrontend or TemplateEngineFactory to enable TWIG support (others enjoy LATTE more, but ok). While it seems that almost 95% of us here use TracyDebugger, I am not using it for the following reasons: I am not a programmer or developer. I do way more frontend, concepts, and SEO so I enjoy things that make my life easier, like LazyCron, ProCache*, FormBuilder*, ProFields*, and some additional 3rd-party modules to fix and boost SEO, like SEOMaestro, or automate things, with LazyCron, Hooks in ready.php, and maybe even some small custom modules. The real kicker is probably: Custom Modules and/or Custom Page Classes My preferred CMS before ProcessWire was Textpattern which was totally different, yet minimal and easy to use. It took me about a week to feel home in ProcessWire, built my first client project the same year, and never left ProcessWire - since 2014/2015. I built almost everything from simple landing pages to full-fledged projects. See those Site of the Week entries here: https://weekly.pw/issue/221/ https://weekly.pw/issue/371/ https://weekly.pw/issue/374/

Hey PR community, I just wanted to introduce myself and ask some questions. I'm a marketing and creative professional with some front-end skills mostly acquired by working in proximity with real developers ~20 years and by using technical-ish page builders like Webflow and Oxygen (for WordPress) where understanding HTML/CSS was necessary to make cooler things. I own a small creative agency called Freehive. We're famous among a very few people for creating release videos for GNOME and Ubuntu Desktop, and more recently helping Thunderbird redesign their website. We use Free and Open Source Software for design, animation, etc. and I'm regularly trying to convince creatives to kick their Adobe/Autodesk addictions subscriptions. I helped create the Inkscape marketing team several years ago and actively contributed there until a recent (necessary but temporary) break. I love FOSS, I love tools anyone can pick up and make a better life with regardless of their financial means. When I was looking for a more secure, open, and elegant solution than WordPress, you can only imagine how delighted I was to discover ProcessWire. With that background out of the way, I've got some questions: Have you found it difficult to convince clients to use something other than WordPress? What do you tell them, if so? If you've worked in the WordPress ecosystem, what do you miss? What are your top three (or more) dev tools or must have modules for making ProcessWire life easier? It's a lot to ask, so I appreciate even partial responses. Thanks, @ryan for creating this magnificent tool and sharing it freely. I really hope I can make it work and to give back somehow.

Sure mate, come back at it anytime!

@elabx Thank you for the reply. I can't say I understand how this works fully yet, but thank you! I may be asking for clarification later :D @flydev Thank you for these great recommendations as well!

Admin Style Chroma This module provides a user interface to control the colors and typography of the AdminThemeUIKit backend theme for ProcessWire 3.0. The requirements are: PHP >= 7.x ProcessWire >= 3.0.179 AdminThemeUikit >= 0.3.3 Less >= 4 InputfieldColor >= 1.1.6 Installation The module can be installed from the Modules Directory or from the zip file archive from the main branch. When you first install the module, you will be taken to the configuration page that consists of four panes: Chroma Scheme Colors Using the color selectors, you can select the first color - your main color - and a second color if you wish - your accent color. Only the first color is required. The default color scheme installed by the module is a grayscale dark mode theme. Your main color does not got modified and gets applied to principal interface elements. If you are currently using the rock.less style as your admin style, this color gets applied to the @rock-primary LESS variable. Your second color gets desaturated. Current Palette Results In the background, depending on your mixer type either one or both of your color selections will be calculated and applied to eight master colors. These colors are displayed here. Your first color choice is applied without any modifications to palette color 3. Your second color choice (when applicable) is desaturated and treated according to your mixer type selection and applied to palette color 6. In general, colors 1-4 are applied to interface elements and their hover states. Colors 5-8 are applied to backgrounds and muted states. In UIKit parlance: Primary color = @chroma-lum-sat-3 Secondary color = @chroma-kum-sat-1 Muted color = @chroma-lum-sat-7 Default color = @chroma-lum-sat-6 Contrast rules are them applied to these colors to get regular and strong labels that are used to assure correct contrast to applied. Please Be Aware: The accessibility contrast threshold of 43% (the LESS default) is applied, but it is still possible to select color combinations that will evade readability scores from Google Lighthouse. Below the current palette dots you will se sample swatches and their hover states can be activated. Chroma Scheme Options The selections made here will alter the LESS files imported into the final admin.css and will either calculate a second color from the first one your select or use the second color. Color Mixer Type There are several mixers included. I'm always interested in other viable additions. Future versions of this module will likely include an ability to add your own custom select options to the interface to reference your own LESS include files. Single : This mixer mode takes your first color, and desaturates it in order to get the second color needed to build the theme palette. Contrast : This mixer mode takes your first color, negates it and desaturates it in order to get the second color needed to build the theme palette. Duotone : This mixer mode takes your first color and uses it to build out the top half of the palette, and takes your second color, desaturates it slightly, and uses it to build out the bottom half of the palette. Cool Harmony : This mixer takes your first color and spins its hue counterclockwise on the color wheel to get the second color and uses it to build out your color palette. Warm Harmony : This mixer takes your first color and spins its hue clockwise on the color wheel to get the second color and uses it to build out your color palette. Luminance Direction Light to Dark (Dark Mode) : This mode sets the palette to run from light colors at 1 to dark colors at 8. When using duotone, the light to dark ordering applies to each 4-color block individually. When using single color mode, the secondary color is a darkened version of the main color. Dark to Light (Light Mode) : This mode sets the palette to run from dark colors at 1 to light colors at 8. When using duotone, the dark to light ordering applies to each 4-color block individually. When using single color mode, the secondary color is a lightened version of the main color. Vibrance Level While the secondary color is always somewhat desaturated, you may wish to dial down or dial up the saturation depending on the text contrast requirements of your color theme. Subdued : The most aggressive desaturation level. Standard : Reasonable desaturated for most applications. Vibrant : The least desaturated settings, though still slightly desaturated. Chroma Scheme Fonts The drop down selectors here will detect css stylesheets found in your ste/assets/fonts or site/templates directory. If you use RockFrontend to download your Google Fonts, it will detect these fonts as well. If you select "No Custom Font" for either the Header Font or the Body Text Font, the default AdminThemeUiKit font rules will apply. Add Google Fonts This feature makes use of a modified version of Bernhard Baumrock's method (found in RockFrontend) for procuring Google Font files and saving them on your server. After looking at his references on CSSTricks is was pretty clear that the header manipulation approach was going to be the best one. When first installed and run, the Admin Style Chroma module will download json lists of Google Font options and cache them in your site/assets directory. There is currently no method in place to check for new fonts, so if for some reason you are not seeing a Google Font you want to use, deleting this file should force the module to repopulate it: /site/assets/AdminStyleChroma/google_fonts.json The Google Fonts are downloaded by individual family and saved along with their CSS file in: /site/assets/fonts/{family}/{family}.css If you select font variants beneath the dropdowns, these values will be passed to the request. If you do not specify which font variants you want, Google will return the defaults for that font family. If you which to include special italic/oblique variants for each weight, set the option appropriately. If a variant does not exist for a given weight, Google will attempt to serve the closest weights available. If you make selections (or don't) and select a font that you have already downloaded before, the previous family files will be overwritten. PLEASE NOTE : If you download a lot of fonts, this process could take some time. Style Compatibility A lot of styles have already been corrected. A number of styles within the ProcessWire core that use plain css or scss have been overwritten via specificity. A 'chroma' class is also added to the body tag, which drives many of the newly inherited classes, but due to the design of some features of certain modules there are other classes defined outside of the heirs of this class. I'm not always happy with how warnings appear. Future versions will address these issues. I've included many rules to provide support for the following areas: Tab Wrappers Page lists and actions Radios, Checkboxes and Selection Colors Selections, Marked text Panels and widgets Image related popups Awesomeplete RepeaterMatrix TinyMCE Interface Tracy Debugger Page Hit Counter Release Note Changes Admin On Steroids Admin Helper Search Engine Color Spectrum Easy Repeater Sort Page View Statistics Nette Tests All changes here are entirely superficial quality of life style improvements. The functionality is not altered. Depending on your TinyMCE settings you may see these improvements but you may not. I've made changes that address quirks that I have personally seen. I am always open to adding rules for other modules where the styles are off or assume a white background. I hope one day we will have a proper discussion of less/css normalization for module authors, but even when that occurs it is hard to say how we will retrofit older modules, etc. For now, this is a patchwork process.

We've been running pretty much the same jQuery and jQuery UI versions for the last 10 years or more. I haven't really seen much urgency to upgrade because the versions we have work quite well, and I wasn't so enthusiastic about the amount of work and potential headaches the upgrade might entail. Over time there have been been a few security issues found in the jQuery library, which I've always kept an eye on, but they weren't ever things that affected our usage or caused any concern here. The biggest hangup I had was just that upgrading meant also updating a lot of code that uses jQuery, since many of the changes to the library are not compatible with code written for earlier versions. (Newer versions of jQuery have a slightly less convenient API than earlier versions). I place more value on stability than on having new versions of things. But it's always been in the back of my mind that sooner or later it would be nice to get these libraries upgraded for many reasons. After all, newer means better and faster right? Well, not always, but that's been the theme in jQuery at least, that newer versions of the library have some performance benefits over older versions. For awhile now, ProcessWire has been using newer jQuery version only when $config->debug = 'dev'; and I've been testing that out for quite awhile (maybe a year?). This week we upgraded our "main" core jQuery version from 1.8.3 to the last available 1.x release 1.12.4 (4 years newer), which is the one I've been testing. We also upgraded our "dev" jQuery version from 1.12.4 to 3.6.4, which is the newest available version, released by jQuery last month (March 8, 2023). In addition, our jQuery UI "dev" version is now updated to the newest available version, 1.13.2. After awhile, these "dev" versions will become our main versions, but likely not before the next main/master version. While the core seemed to work fine as-is with the newer jQuery (1.12.4), the newest versions of jQuery (3.6.4) and jQuery UI (1.13.2) required quite a few JS file updates to support, and that's primarily what you'll see in the commit log this week. If you'd like to test the newest versions of these libraries in the ProcessWire admin (in a dev environment), edit your /site/config.php file and set: $config->debug = 'dev'; When you do that, it will also load the jQuery migrate library with logging ON. Meaning, the Javascript console will contain messages about things that need to be updated. There's still work to do in the core here, so if you enable 'dev' mode then chances are you'll see some messages about things in the admin too. The "dev" debug mode also makes it use the newest jQuery UI library. Keep an eye out for any visual glitches or any UI things that don't work. For instance, I found that when using the newest jQuery UI version, the image resize/crop tool wasn't working quite right, though I hope to have that figured out soon. Chances are there may be other examples like that, if using the 'dev' debug mode, so please let me know if you come across any. If you are a module author, your module uses jQuery and you want to make sure it's working well with the new main core version (1.12.4) you can also enable jQuery migrate verbose messages in your javascript console by setting the following two in your /site/config.php: $config->debug = true; $config->advanced = true; I've found that updating code for jQuery 3.6.4 seems to be backwards compatible with 1.12.4, so maybe just using the $config->debug = 'dev'; option is a good bet when testing, but I wanted to mention both options are available. I'll be continuing to update our core .js files for 3.6.4 and jQuery UI 1.13.2, and next week will likely update some of our 3rd party jQuery libraries such as the TableSorter library and others. Also, I've not forgotten about pulling InputfieldTinyMCE into the core, that'll likely be in the next version 3.0.216. Thanks for reading and have a great weekend!

Field Initial Value For most field types, allows the definition of an initial value that is automatically set when pages are created. The initial value can be set in template context if you want a different initial value in different templates. Example for a "Countries" Page Reference field using AsmSelect: Example with explanatory notes in a CKEditor field: Differences from "Default value" The core allows setting a "Default value" for certain field types. The "Initial value" setting added by this module is different from the "Default value" setting in the following ways: The "Default value" is a setting that applies only to the inputfield, meaning that the value is shown in the inputfield by default but is not stored until you save the page. By contrast, the "Initial value" is automatically saved to the page when the page is first created. Related to point 1, when a page is created via the API rather than in the ProcessWire admin the "Initial value" is saved to the page but the "Default value" is not. The "Default value" has no effect when a field is not "required", but the "Initial value" is set for both required and not required fields. Related to point 3, a user can empty a field that had an "Initial value" applied but a field with a "Default value" set cannot be emptied. The "Initial value" setting is available for more field types than "Default value". Supported field types The following field types are supported, along with any types that extend them: FieldtypeText (includes types that extend it such as Textarea, CKEditor, URL, etc.) FieldtypeDatetime FieldtypeInteger FieldtypeDecimal FieldtypeFloat FieldtypePage (with all core inputfield types) FieldtypeCheckbox FieldtypeOptions (with all core inputfield types) FieldtypeToggle FieldtypeSelector FieldtypeMultiplier (ProField) FieldtypeCombo (ProField, only supported when File and Image subfields are not used) FieldtypeStars (third-party module) If you want to try field types beyond this you can define additional types in the module config, but your mileage may vary. Unsupported field types It's not possible to set an initial value for these field types, along with any types that extend them: FieldtypeFile (and FieldtypeImage) FieldtypeRepeater (includes types that extend it such as Repeater Matrix and Fieldset Page) FieldtypePageTable FieldtypeTable (ProField) Notes Seeing as the initial value is defined in the field config it has no idea of the current page - for the purposes of rendering the initial value inputfield the home page is supplied as a dummy page. This probably isn't an issue in most cases but it might have an effect for some Page Reference fields if they use the current page to limit the selectable pages. https://github.com/Toutouwai/FieldInitialValue https://processwire.com/modules/field-initial-value/

thanks anyone and thank yout, robin s, that was the solution! plus i guess i spent some money on pro fields ?

Hi and welcome @ryangorley ? 1. give a read to: https://processwire.com/about/what/ and 2. refer to #1 3. the very first one tool you and the team need while working with ProcessWire is: https://adrianbj.github.io/TracyDebugger/#/ https://processwire.com/talk/forum/58-tracy-debugger/ ✨Suggestions: - keep an eye on @Robin S gems (modules) handy on every situation: https://github.com/Toutouwai - subscribe to weekly.pw - and do not hesitate to search and use the forum, even for "i will feel dumb" questions. Enjoy ?

The "raw" ProcessWire API, is a bit more verbose but not really a show stopper. Also to be clear with API I mean the whole deal of classes involved in the admin or pages/fields like Field, Fieldtype, Inputfield, InpufieldForm, InputfieldWrapper, etc and hooks involved, not just the global $page, $pages, $input variables. Say with RockMigrations you'd do: $rm->migrate([ 'fields' => [ 'some_fifeld' => [ 'label' => 'Some Fields', 'type' => 'title' ] ]; ]) In "plain" PW API: if($fields->get('some_field')){ $field = new Field(); $field->name = "some_field"; $field->type = "FieldtypeTitle"; $field->label = "Some Field"; $field->save(); } And most of this doesn't really change much with any other field. But indeed since ProFields tend to elaborate on complex things to solve, they might involve a few more steps.

Looks cool! Could you attach full screenshots of admin pages styled this way? Just for fun)

I would like to add my 50cents here as well. I basically agree to what @Stefanowitsch mentioned above. I love to use RockFrontend for the following reasons: LATTE, LATTE, LATTE then AutoRefresh and thats it for me personally. I also like to keep all my modules as much as possible to the latest version. With RockFrontend this means, I get lots of new stuff, which might or might not affects my site (I always need to test this), but which I do not really need most of the time. Maybe it would make sense to split the module into two parts. RockBackend and RockFrontend where RockFrontend needs to have RockBackend as a dependent module somehow? I personally find it strange that a module which offers neatless integration with LATTE and auto compiles LESS files also provides scritps for fluid font sizes, animations, downloading fonts to local folders, etc. I know this is just my personal preference and the way I work, and others will have a different approach here and will use many features of what the module offers. And by no means I want to criticize Bernhard for the way he develops his module.

Thanks @elabx! According to the docs RockMigrations doesn't support all ProFields. Have you found a workaround for that issue? Is the documentation out of date and they're now supported by chance?

RockMigrations, FormBuilder, ProCache, I think all if not most ProFields. DDEV for local development.

Okay I'll try some other things.

Love this! Makes total sense. Although I did try to make AlpineJS part of my boilerplate and quickly gave up. Just easier for me to add a JS file and do my stuff with vanilla. Right now I just have a Vite thing, a js that imports and inits scripts from a file (like the one that Bernhard mentioned). Effects like my text reveal thing require adding the type of ready-made JS and CSS that I tend to avoid. However if it could be part of a library of stuff a developer can browse and easily add to their project, it might be a cool idea. Alpine might help with this.

It's not official documentation but the topic has been discussed here: The page and diagram that @teppo created and linked to is dead now but I've found it very informative so here's the diagram for posterity: It would be wonderful if @ryan or someone knowledgeable created an updated version of this.

Oh, yes, it is. I'll have to be more careful. Thank you.

The form is blocked by my adblocker (uBlock origin) ? Maybe the same thing happens to you...

Hi @bernhard I can't connect to the website. Blank page only.

@taotoo, @bernhard, @Jan Romero Thanks for your clarification. Regarding 300dpi file size I was wrong. I did experience this kind of slowness and high CPU usage with a client project that I recently migrated. It turned out the previous owner did not define any image scaling. They used to export 300dpi files from Indesign with 20MB file sizes and users uploaded multiple images to the ProcessWire project. Approx. 100MB were loaded on every page refresh. After taking a closer look I managed to resolve the issue. Thanks again.

For me personally I see RockFrontend as a tool for development. Not a frontend framework. The main reasons why I am using RockFrontend are: - Auto Refresh - Make use of the rfGrow Feature for fluid font sizes & Handling Assets: - Auto compile LESS to CSS - Minify CSS and JS Files I know that there are already some JS-Snippets included (like rf-scrollclass) but I it's too tempting to start in including more and more Frontend Framework features. I personally use only a fraction of what RockFrontend offers and it's hard keeping track because new features arrive continuously ? If more and more frontend framework features will be included at some point in the future you have to decide wether RockFrontend will evolve into it's own frontend framework, shipping scripts and styles for everyday usages.

The master/main branch is now updated to version 3.0.225. Early next week I'll be adding a git tag for the version number as well. I usually like to merge dev to the master/main branch first, let it marinate for a day or two, and then tag it. That's because once we tag it, it triggers other services to pick it up and broadcast it. So letting it marinate for the weekend just adds a layer of comfort, for whatever silly reason. That's pretty much how I've always done it. When I did the merge, it reported 511 files changed, 76421 insertions(+), 23539 deletions(-), so there's quite a lot in this version. There's enough, that I'm going to need another week to document it all into a new blog post, which should be ready by this time next week. Our contributors list also continues to grow nicely with this new version. Thanks to all those that have submitted PRs, reported issues, and submitted feature requests. Big thanks to @matjazp in particular who has been helping a lot in identifying, testing, organizing and even coding the solutions for numerous issue reports. More details on this new version next week. Until then, thanks for reading and have a great weekend!

Continuing from last week's post and discussion, ProcessWire 3.0.218 decouples the modules system from the cache system. Now the modules system maintains its own internal caches (at least once you do a Modules > Refresh). It'll still use the $cache API as a backup (temporarily), but now you can safely export the database without the "caches" table, or even delete the "caches" table, if you want to. It'll get re-created as needed. In this version, work also continued on the new WireCacheInterface (and major updates in WireCache) so that we could support external modules to handle cache storage. This capability is kind of similar to how we support 3rd party WireMail and WireSessionHandler modules. The first example is WireCacheDatabase, which is the default cache storage handler for the core. And today we have a new module called WireCacheFilesystem that replaces the default WireCache database storage with a file-system based storage, once installed. It's not yet clear if there are major benefits one way or the other (cache in database vs. file system), as I've not been able to put all this new code through performance testing yet. I'd definitely be interested to hear if anyone has a chance to test things out. I expect the file system might be faster for reading caches, while the database may be faster for writing caches. At least that's what I found with a few preliminary experiments, but they haven't been very thorough, so take that with a grain of salt. I thought we needed at least 2 examples of classes implementing WireCacheInterface before we'd be ready to support potential 3rd party WireCache modules. I imagine that 3rd party modules getting into dedicated cache options independent of database or file system is where we'll start to see major performance benefits. At least for sites that use the cache heavily. That's all for this week, have a great weekend!

Haven’t tried it yet, but it looks like there is a new fork of selectize at https://tom-select.js.org I just saw this and thought I would report it here in case it is relevant?

Just an FYI for everyone who may upgrade to the latest PW dev version today. If you make use of AOS's excellent "Add button to check/uncheck all checkboxes" feature, it will break the top level menu dropdowns in the PW admin (and maybe other JS). The fix is to replace: ("[data-no-checkall-checkboxes="1"]") with: ([data-no-checkall-checkboxes="1"]) in: /site/modules/AdminOnSteroids/scripts/aos.min.js

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:

Not sure if I'm missing something... No module, 2 lines of code: $restaurants = $pages->findRaw("template=restaurant", ['id', 'title', 'modified']); $json = json_encode(['restaurants' => array_values($restaurants)]);