Leaderboard

Welcome to the forums! I have three suggestions. First, when using PW, don't think about SQL unless you really, really have to – and it'll probably never be necessary! Second, when deciding how to structure data, it's usually best to start by thinking of each major item as a page, and move on to complex field types only if it would improve things (usually because it will help with human editing of data). So, for example, you might handle each booking as a page, and then use a Page Reference field to link to the relevant event. Third, if you haven't already, look in depth at selectors (very important and a great feature of PW!) for retrieving the data you need. Let us know if further help would be useful!

Good evening to all, watched a youtube video about Processwire a few days back from Bernhard Baumrock and thought I deep dive into this CMS/CMF and try to realize a new project with it. My project basically deals with the subscription to some events (10-20). Basic idea is that potential guests get an E-Mail with the Url and a random unique personalized GUID (40 chars) used to assign to free slots via a public Form without having access to the backend at all. Started with the Intermediate PW install and managed to setup an overview page showing a table with events pulled from it‘s child pages, a detailed page showing all infos for the actual event. Also managed to setup a custom form with three actions (subscribe, unsubscribe and check status of booking). For data storing I would like to create a settings page with text fields for the unique bookingID, a text field for linking a eventID to the bookingID and a datetime field to store the date of the submission. The bookingIDs will be available from start, where eventID and datetime are NULL first and get’s updated depending on the form action taken. I will have to store a table with about 100 entries (Sql rows) and 3 fields (Sql columns). Can this be realized with a repeater and the three custom fields? Should this page be a admin page, or a hidden frontend page? Are there any other options to store this values and access it via the PW API? Any hints would be highly appreciated. Cheers zx80

@MarkE What I'm intending to communicate is that it's up to the module developer how many of the WireCache features they want to support. That's because, as I understand it, it's not possible to support the the full WireCache feature set with something like Redis. The core WireCache (WireCacheDatabase) will continue to support the full feature set, as it always has. For 3rd party WireCache modules, the required feature set would just be the ability to get, save and delete cache by name ... what the majority of cache use cases are. If they can support more than that, great. But I think it's better to keep the door option to more cache options by not requiring specific and lesser-used cache features unique to PW. If a 3rd party module has to support the full WireCache feature set then likely there won't be 3rd party WireCache modules. For cases like yours, where you are depending on specific features, you'd probably want to stick with using the core default (WireCacheDatabase), unless future 3rd WireCache module is able to support them. @BitPoet Great! Yes, that's correct, the core does not use anything but get/save/delete by name. But it does use wildcard matching (for FileCompiler). Does Redis allow for matching by partial cache name? For instance, a cache name that has a wildcard at the end like "MyCache*"? If not, there are ways around it, but I was just curious. Maybe that is a good way around it. Though having to hit the database in addition to Redis might reduce the benefit, or make it slower than just using the database cache. Maybe another way around it is for WireCache to fallback to the WireCacheDatabase when a particular feature is needed that's not supported by the WireCache module. Good idea, I will add that. @kongondo I don't think so because the cache would have to write and read from the same place, otherwise I don't know how it would find caches that it wrote. But PW does support separate read and write connections for the database (WireCacheDatabase), and it will use them when they are provided.

https://www.bmt.net.nz/ This project began as a project to convert a 20 year old Microsoft Access membership and musical production database to a cloud based system. I completed that over a year ago, but then the organisation realised they wanted a new website, and much of the data was already in the system I'd built for them to manage their membership and shows. Building the public frontend required adding a few more fields on the backend, and reorganising some of the data, but most of it was there already. I've used Lister Pro extensively in this project and it's also my first project using RockMigrations. RockMigrations has proved really helpful in adding new fields, testing, then applying to the live site, and although there's a bit of work to go, the aim is to use RockMigrations to enable the whole setup to be installed as a module on top of a clean ProcessWire installation, as I suspect the setup should be useful for other groups, either with or without customisation of the frontend. Other modules I used were Formbuilder Pro for a membership form, Import Pages from CSV (to import exported data from Access database), Wiremail Gmail, to enable emailing to gmail addresses. I also wrote a custom dashboard module and updater. I wrote a modified version of the ListerPro action Send Email to enable sending HTML formatted emails.

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!

Hi Bill, thanks for your suggestions, pretty much went your proposed way already. I wrote a PHP/PW console script, deleting and adding a page for each possible end user based on a given data template with BookingId, EventId and Last access time. Those fields gets updated based on the chosen form action. Rest was realized with default PW stuff like fields, templates and pages. The selector API you mentioned really makes it easy to find pages/fields, get/set/update field data on the fly and to sanitize user input. Quite impressing how far I got in two days from scratch with my very first PW project and some medium PHP level skills. Finished a working prototype this morning. Now need to add some security features to the form like IP reload/retry ban and Captcha. Will check out the API documentation and see how to implement those stuff.

Yes, completely possible! Indeed, I'm not sure why you're losing the spaces. Do you have a text formatter (on the Details tab) applied to the field? If so, this might be removing the spaces. If the textarea uses a rich text editor (CKEditor, TinyMCE), it's possible that the editor (or an associated function) is removing the spaces, so it'd be worth checking the settings. I can't think of one that would do this off the top of my head, but I may well have forgotten something! If it's neither of these, take a look at the HTML in your browser using the Inspect option. And if that doesn't clarify whether spaces are getting through to the page, you could check using something like: echo str_replace(" ", "_", $page->myTextField); If underscores appear, the issue is something to do with the rendering of the page. You could try replacing the the underscores with &nbsp; in the above, though this shouldn't be necessary for the spaces to render in a <pre> element.

How would the two caches ever match up? You'd have to write your data to both caches at once, which means you'd end up with slow writes anyway. If you want to use two different caches at the same time for different kinds of data / different areas of the site where one or the other provides real benefits, you can instantiate another WireCache with PW's built-in database engine manually. Assuming you have WireCacheFilesystem installed, you could still do: <?php namespace ProcessWire; /* You can put that block in site/ready.php to make $dbCache available everywhere: */ $dbCache = new WireCache(); $dbCache->setCacheModule(new WireCacheDatabase()); wire('dbCache', $dbCache); /* End of site/ready.php */ // Template code: store a value in the database cache that often gets written but seldom read: $dbCache->save('testentry1', 'This is saved to the database', 3600); ... echo $dbCache->get('testentry1'); // Template code: store a value in the filesystem using PW's default engine that gets read // a lot more often than it is written: $cache->save('testentry2', 'This is saved in the filesystem', 3600); ... echo $cache->get('testentry2');

We look after a lot of non-profit sites including half a dozen schools and they're mostly hosted on Digital Ocean instances managed by Cloudways. Their cheapest instance is currently $11 a month and that's what we normally start and which provides good performance for most cases (there are some additional per Gb backup charges but they're normally very minimal). You can scale up instances if you need to. One thing we find particularly useful is being able to 'clone' sites so we keep a skeleton PW site up to date and can just replicate that to kick off a new project (no, all our sites do NOT look the same...). You can also clone a site to a staging site and then push changes from that to the live site. We generally stick sites behind a free Cloudfare account as well (because honestly why wouldn't you), and Cloudways also have a deal with Cloudflare where you get the enterprise level for $5 a month which seems great if you need it (we rarely do). We also use https://krystal.uk/ for clients who need emails - that's more of a traditional CPanel setup but works well for us.

HTMX is quite good. $config->ajax won't detect HTMX requests though, so I recommend adding this to your /site/ready.php: // if htmx request, DO NOT use _main.php if(array_key_exists('HTTP_HX_REQUEST', $_SERVER)) { $config->appendTemplateFile = ''; $config->htmxRequest = true; } That assumes you are using the Markup Regions output strategy by the way. Use $config->htmxRequest as needed.

Like the title says. Accidentally renamed "wvprofile_body" to "Body" where I actually meant to change the label. Didn't notice that I had entered that into the wrong field, hit Save. ProcessWire destroyed the wvprofile_body table then showed me an error saying that the field "body" already exists. I have no idea what happened. I've never had this happen before, but I've also never accidentally renamed a field to an existing field name. Has this happened to anyone else? Doesn't PW check for a unique name before deleting data? Looked in the database directly, the entire wvprofile_body table is gone. Keep backups.