Leaderboard

If you are interested I can take the time to publish a draft of a profile which you could use as starting point, and IMO it's better and easily than other solution that I could have tested. Basically it use a modified version of InertiaAdapter made by @clsource and let you code your app inside ProcessWire's template and using pages for everything fetched dynamicaly and internally, as JSON. You can see it "in action" in this example url: https://blog.sekretservices.com/ (Do not take care of the issue while refreshing the blog post due to hanna codes, it's an old version) For example, from your template you build the page properties as a simple PHP array, let's say I want to fetch the title of the page: $component = "Home/BlogPost"; $properties = [ // accessible from app components with $page.props 'name' => $page->name, 'title' => $page->title, 'subtitle' => $page->subtitle, 'content' => $page->body, 'author' => ucFirst($page->createdUser->fullname[0])."."." ".ucFirst($page->createdUser->surname), 'date_created' => $page->created, 'date_relative' => $datetime->relativeTimeStr($page->created) ]; Then from a component BlogPost.`{svelte, vue, react}` (or whatever) you can simply retrieve the page's props like: (Svelte example) <script> import {inertia, page} from '@inertiajs/inertia-svelte'; export const { title:title, body:body } = $page.props </script> <div class="blog-post"> <h1 class="font-sans mt-8 text-center font-bold">{@html title}</h1> <div>{@html body}</div> </div> Look at this sample, at the page's tree and the routes prop from the console : About the workflow, it's not really different from what you should be used to. You write your logic in template in PHP then write some HTML/JS in your component. Also, hot module replacement (HMR) is working ? A word about server side rendering (called SSR and which is needed to get best SEO results), it's working for React and VUE, still a WIP for Svelte ? Get a note of ?on every lighthouse performance. Bundled with ViteJS, powered by ProcessWire, I am glad to say that it's the best stack I have ever built and used ?? Edit: A small note, but the better one. You don't have to build your app again on every change on the backend, I mean for example when you add a new page, it's work out-of-the-box, you create and page, and it's available to your JS components. Edit2: To understand better, here we can achieve what you already used/saw with Laravel. Having a `src` folder with the JS things, another folder with the Laravel `app` and running artisan and some npm command. Here, in dev mode, you run `yarn dev` and you are ready. Simple as that.

Let's hope then this is the year! ?

Yes, it would for sure. I recall that Ryan was talking about making the PW API available through JS some years back. That would be exactly what we need. A RESTful API like the WP REST API in ProcessWire. This should ideally be available as an optional core module and support all Pro fields.

Maybe this question is too general and I don't want to hijack this topic, but: What are your reasons/advantages for using a headless CMS? Is it performance, targeting different channels than browsers or is it more fun to structure your content? I am curious, because I am still building websites the traditional way. ?

I found this nice tool that helps generating SQL and diagrams https://www.dbml.org/home/#intro Example Table makers { id int [pk, increment] name varchar(100) } Table cars { id int [pk, increment] maker int [ref: > makers.id] // # one maker -> * cars model varchar(100) about varchar(100) image_url varchar } Maybe useful for ProcessWire site planification too ?

They are not, but they can be used together. Static sites doesn't have to be so static, if you are using static site generators (11ty, astro, nuxt, next...), you can fetch content from the headless cms, then you can trigger re-build when content is changed, and automate the deployment. +1 for this. As processwire is in fact headless, having the REST api out of the box would be great. Take strapi as example... Imo, having REST api would be much more beneficial, then live previews for example. Saying this because there was a discussion about live previews, but also of js api... If i could vote, would always put the time into the js api...

Some additional feedback so far... The PageQueryBoss module, which @monollonom recommened looks pretty nice and works out really well so far. There are issues, but way less than before. I will use and play around with it for a bit. Maybe that's what I was looking for. In regards to those other modules I mentioned before... GraphQL In my setup I had to change each and every field to make it available for public (legal) requests. That's awesome for a setup that needs control about each and everything. But that's nothing I needed or need. Therefore changing a lot of fields without knowing anything about possible issues in other pleases, wasn't an option. Pages2Json The simple JSON feeds were easy to create but... customizing, repeater fields, matrix fields and such... were way out of focus and not that easy at that time (we haven't had a lot of budget and time to get things done)... so maybe it's a nice solution after all. I used it before and it's still in some other projects but in this special use-case... it wasn't that perfect for me. So... I can't say anything bad about the module, yet it wasn't a solution for that specific project. Another thing... While those modules work for some use-cases and in probably a lot of existing projects, they are still 3rd party (which isn't a bad thing, but...) and looking at the "last update" dates... they are somewhere between 2018 and 2021. Which isn't that bad compared to some core and 3rd party modules, yet I have to rely on those modules for the next couple of years. Changing PW versions, PHP versions and whatsoever. Some support threads are way outdated and sometimes even look "bad" with unanswered questions. Didn't and still don't feel comfortable with this - not only in this very case. Therefore I use so many ProModules for a lot of things.

Subscribe Podcast RSS feed and save as something you want. The additional example module ProcessPodcastSubscriptionsEpisodes create new pages per episode. Download/Install Github: https://github.com/neuerituale/ProcessPodcastSubscriptions Module directory: https://processwire.com/modules/process-podcast-subscriptions/ Composer: composer require nr/processpodcastsubscriptions

It's not really about the Headless CMS - at least not in my case. I'd be totally fine with just editing .md (content) or .njk (templates) files from the command-line. While this works perfectly fine for me, my clients aren't that keen to work this way. They love their interfaces to edit content, creating pages and such. So there is still need for some kind of interface of some kind for my clients. As I love ProcessWire and all the things I can do with it, using it as a Headless CMS would be the perfect match. Not only that but ProcessWire is way ahead compared to other CMSs, especially combined with ProModules. Yet it's not that easy to get this up and running to use it with 11ty, Hugo, Gatsby and other SSGs (Static Site Generators). Or at least it wasn't for me and still isn't. That's why used WordPress for quick solution. There is a REST API/JSON feed with everything I needed right from the start, some additional changes and I was ready to go. But as soon as I know how to get these JSON feeds from ProcessWire, I will switch that project over for obvious reasons. And the reason why this even became a topic for me: static sites are way more comfortable in terms of "release and forget". If a client doesn't change anything within a year or two, it doesn't matter at all. There are no risks, no security issues, no updates, nothing. Sure you have to maintain a ProcessWire instance even though you rarely use it but you can disconnect it from the deployment and nothing will happen to the real site. But maybe in some cases it's already enough to use Forestry CMS, which right away talks to Github - kinda awesome! @lokomotivan listed some very good reasons for static sites ans SSGs and I will go this route as soon as I can for existing projects and upcoming ones. Let alone the performance differences are quite insane, even when using ProCache. I hope to get one of my larger side-projects up and running with this kind of setup in the next months. Maybe with ProcessWire, maybe with another option (just to get a feeling for other tools). While I already get awesome numbers in performance tests, the amount of unwanted traffic through bots, spiders and a lot of script-kiddies is an issue for me. Using Netlify or Cloudflare as hosting solution this wouldn't be an issue anymore. So... while classic websites are still a thing, I'd like to add another option to my tool belt and I'd love to use ProcessWire with it.

https://github.com/processwire/processwire-issues/issues/1533

A tiny update: I replaced the wire directory with the one from the current MASTER branch (v 3.0.184) an now it works as expected. So maybe there is an issue in the DEV branch only (wich may or may not make the way in an upcoming release). @ryan FYI (Let me know if you need any more information about this)

I also still build websites traditional way, depending on the project, and needs. If I need a CMS and more advanced features, using pw, if need a more basic website, then trying to use SSG. Usually without cms, content in markdown… Just started with SSG sites, but planning to move to it as much as I can. Don’t have to keep your front-end files on the same server Easier to deploy websites (static sites, SPA). You can deploy your website to github, netlify, cloudflare pages… no server needed Easy to build multi websites with one backend Easier to collaborate via git Easier to share data between websites Tooling, preprocessor parsers, purge css, live reload etc… Easier to switch front-end entirely, eg: change front-end framework, change static site generator…

So I recall, and still waiting ? It was on top of his list but... EDIT: https://processwire.com/blog/posts/roadmap-2017/#whats-in-store-for-processwire-in-2017 To quote ryan (4. Jan 2022): https://processwire.com/talk/topic/24876-pw-30170-– core-updates/?do=findComment&comment=209625

So I recall, and still waiting ? It was on top of his list but... EDIT: https://processwire.com/blog/posts/roadmap-2017/#whats-in-store-for-processwire-in-2017

Hi, just wanted to share my experience working with larger data sets in PW. For a recent project I had to import rather large data sets (between 200 and 5000 rows) from Excel sheets. The import files got processed in chunks and I had to save only one value to one float field on a page. There were about 15.000 pages of that type in the system and another 1800 pages of a different type. The process of saving each page got really slow when looping through hundreds or thousands of pages. Inside the loop I retrieved every page with a $pages->get() call. This was really fast. But saving got very slow. It took about 4 minutes to process 2500 pages on my dev docker machine and about 2 minutes on the live server with 16 virtual cores and 80GB of RAM. There was one hook running on change of the page field that I saved the values to that did a simple calculation and saved the result to a different float field on the same page. And I guess that was one reason for slowing the process down. After changing the logic and doing the calculation in the import loop, things got a little better. But not much. So I wonder if PW is just not designed to handle large amounts of page saves in an efficient way? I would have thought otherwise. What I ended up doing is writing the values directly to the field in the DB with a simple method public function dbSetData($field, $id, $value) { $db = $this->wire->database; $statement = "UPDATE `{$field}` SET `data` = {$value} WHERE `pages_id` = {$id};"; $query = $db->prepare($statement); if ($db->execute($query)) return true; return false; } and also getting the required value for the simple calculation directly from the DB public function dbGetData($field, $id) { $db = $this->wire->database; $statement = "SELECT `data` FROM `{$field}` WHERE `pages_id` = {$id};"; /** @var WireDatabasePDOStatement $query */ $query = $db->prepare($statement); if ($db->execute($query)) { $resultStr = $query->fetchColumn(); if (is_string($resultStr)) $result = $resultStr + 0; return $result; } else { return false; } } And that drastically dropped execution time to about 8 seconds for 2500 rows compared to 2 minutes with $pages->get() and $pages->save(). I guess if I need to setup a scenario like this again, I will not use pages for storing those values but rather use a Pro Fields Table field or write directly to the DB.

Unfortunately we where not on InnoDB. But the problem was not so much memory consumption but rather long execution time for saving pages. Total mem consumption after saving values to 2500 pages was around 45MB only.

There are different ways of making a Rest API You can check https://github.com/Sebiworld/AppApi and

Thanks @monollonom - I didn't know that module but I will have a look at it. Maybe that's more of what I need. Thanks @dragan - you are right, a Headless CMS is something completely different than a SSG. I already found a nice SSQ solution and right now I'm looking for a fitting CMS. I looked at a lot of those mentioned above, yet ProcessWire is way more advanced and more capable of almost anything. And sure... creating JSON feeds is easy until you have a more complex setup of fields, references, repeaters, Matrix fields and such. That's exactly that point @gebeer made here. In WordPress it was super easy to get it right from the start - sure still not a super complex structure, no real repeaters, but way ahead. I'm fine with going into the code, write my output but I sometimes just need something that works right out of the box. Wordpress could be a good fit but maybe even better one of those other CMS out there. This in the core, with support for (matrix) repeater, combo and all the good stuff... this would open a totally new and large user base.

Hi, in a recent project I had to import large amounts of data that got uploaded through the frontend. To avoid lags in the frontend I pushed the actual import work to processes in the background. Since timely resources for that project were limited, I resorted to a quite simple method of starting the workers public function startSalesImportWorker() { $path = $this->config->paths->siteModules . "{$this->className}/workers/"; $command = "php {$path}salesimportworker.php"; $outputFile = "{$path}/logs/workerlogs.txt"; $this->workerPid = (int) shell_exec(sprintf("%s > $outputFile 2>&1 & echo $!", "$command")); if ($this->workerPid) return $this->workerPid; return false; } Here's the worker code namespace ProcessWire; use SlashTrace\SlashTrace; use SlashTrace\EventHandler\DebugHandler; include(__DIR__ . "/../vendor/autoload.php"); include(__DIR__ . "/../../../../index.php"); ini_set('display_errors', false); error_reporting(E_WARNING | E_ERROR); $slashtrace = new SlashTrace(); $slashtrace->addHandler(new DebugHandler()); // $slashtrace->register(); $lockfile = __DIR__ . "/locks/lock-" . getmypid(); // restart when fail or done function workerShutdown($args) { // release lockfile if (file_exists($args['lockfile'])) unlink($args['lockfile']); echo PHP_EOL . "Restarting...\n"; $outputFile = __DIR__ . '/logs/workerlogs.txt'; $command = PHP_BINARY . " " . $args['command']; sleep(1); // execute worker again exec(sprintf("%s > $outputFile 2>&1 & echo $!", "$command")); } register_shutdown_function('ProcessWire\workerShutdown', array('lockfile' => $lockfile, 'command' =>$argv[0])); // wait for other workers to finish while (wire('files')->find(__DIR__ . "/locks/")) { sleep(5); } // create lockfile file_put_contents($lockfile, $lockfile); try { // ini_set('max_execution_time', 300); //300 seconds = 5 minutes wire('users')->setCurrentUser(wire('users')->get("admin")); echo "starting import: " . date('Y-m-d H:i:s') . PHP_EOL; /** @var \ProcessWire\DataImport $mod */ $mod = wire('modules')->get("DataImport"); $mod->importSales(); echo PHP_EOL . "Import finished: " . date('Y-m-d H:i:s'); // run only for 1 round, then start a new process: prevent memory issues die; } catch (\Exception $e) { $slashtrace->handleException($e); die; } I got the idea for restarting the same worker from https://www.algotech.solutions/blog/php/easy-way-to-keep-background-php-jobs-alive/ Note that I am using https://github.com/slashtrace/slashtrace for error handling since it gives nice CLI output. And I couldn't figure out how to utilize the native PW Debug class for that since I needed stack traces. Overall this solution worked quite well. But it doesn't give any control over the worker processes. At least there was no time to implement. Only after having finished the project, I discovered https://symfony.com/doc/current/components/process.html which seems to have everything you need to start and monitor background processes. So next time the need arises I will definitely give it a try. I'm imagining a Process module that lets you monitor/stop background workers and a generic module to kick them off. How do you handle background processes with PW?

.I guess the reason why @wbmnfktr resorted to WordPress is that you have the JSON feeds readily available without any coding. And I often thought that it would be really awesome if we had something like this in PW. With all the modules mentioned AppAPI GraphQl etc you still need to write code to get the desired output at the desired endpoint. WordPress handles this out of the box. And this makes it attractive. PW would definitely benefit and get more attention if there was a module that automatically creates RESTful API endpoints following the page tree structure.

I don't know much about the tools you mentioned and regarding your JSON generation issue I'm not sure I see why the modules you mentionned don't fit the bill, but have you also checked/tried: ? Assuming you have templates named "post", "movie", "page",... you could have something like: $wire->addHook("/api/(post|movie|page)/(.*)", function($event) { $template = $this->templates->get($event->arguments(1)); if(!$template) return; header("Content-type: application/json"); $fields = $template->fieldgroup->explode("name", ["key" => "name"]); if($event->arguments(2)) { $page = $this->pages->findOne("template=$template,name=".$event->arguments(2)); if($page->id) { return $page->pageQueryJson($fields); } } return $this->pages->find("template=$template")->pageQueryJson($fields); }); This way you could have pw.domain/api/post returning all posts and then you could query a specific one with pw.domain/api/post/page-name. (one thing to note is the module does not handle repeaters (or other third parties fields) out of the box, though the docs seem to mention how to do so actually it does but I have an issue in my setup, I think) In case this doesn't help or I didn't get your issue, would you mind to elaborate ?

@jploch Ok, seems to be fixed. I haven't bumped the modules version number in PWs modules system now. Please manually (FTP) update these two files: https://github.com/horst-n/PageImageManipulator/blob/master/PageImageManipulator02.module https://github.com/horst-n/PageImageManipulator/blob/master/ImageManipulator02.class.php If you can try it out and report back, this would be fine. Also on github was a issue report from @Craig with a fix! (Thanks ? ) Haven't seen this, as I train to use git from the command line for the last month. ?

With all respect to the beautiful website .... but the domain name ? I have seen a lot of domain names but never something like this. Think of Visitors outside of Brazil and who is going to memorize something like arbynatashamarques ? Even on a business card it would look kind of absurd. A domain name should be short, easy to memorize and recognizable for a brand, a service, a product, etc. etc. But maybe this is just me.

Seems that things changed slightly ? This worked for me today: Translate file /wire/modules/Inputfield/InputfieldDatetime/types/InputfieldDatetimeText.php Set path: /wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js Search keys: datetime, date picker, monday, translate, sunday, german

@MilenKo Thanks! That helped me out. $favorite_books = $pages->find("template=books-inner, sort=-random, start=0, limit=3");

admin.php works just fine as well if the hook should really only run on admin pages.

Sorry, I've not tried adding hooks in the admin.php file before so I don't know the perfect answer to this. However, if I wanted to hook just admin page renders then I'd keep my ready.php hook and have it filter on the page's template to see if it was an admin page. Like this... $page->addHookAfter('render', function($event) { $template = $event->object->template; if ($template == 'admin') { $event->return = str_replace("</body>", "<p>Hello World!</p></body>", $event->return); } }); Which should restrict changes to just the admin pages.

Because of the $, $download_counter is a variable here. You’re not accessing the page field “download_counter”, but a field by the name of whatever that variable contains. You should also disable output formatting before modifying a field. Use $page->setOutputFormatting(false) or $page->of(false). Lastly, it’s possible to save just the field by calling $page->save('download_counter'). Untested: wireSendFile($page->download_file_link); $page->of(false); $page->download_counter = $page->download_counter + 1; $page->save('download_counter'); $page->of(true);