Leaderboard

Hi @da² Thank you very much for your inputs. I used a session variable and updated it as you suggested. It works as expected. If we find an alternative solution to resolve this, it would be greatly appreciated. Thank you

-

The database was named by the developer, or even the hosing server. If you have access to the hosting control panel, you might be able to upload files via FTP. In that case you could upload a "test.php" file to the root directory of the site (this directory would contain the "wire" and "site" directories and the "index.php" file) with the following code in it: <?php include("index.php"); echo $pages->get(2)->httpUrl; Than you can open the url http://mywebsite.com/test.php and the answer will show up. I also attached the file so you can download it ? test.php

Hey! I would like to announce that there is a new ProcessWire powered collaboration between me and Jan Ploch ? @jploch. When I moved to Hamburg, I contacted him through the forum and we ended up working at the same shared office. Meanwhile we collaborated on some projects and then started our own company (a GbR, in Germany). We named it KONKAT Studio. Now we are publishing our brand new website konkat.studio As you may know, Jan developed a page builder for ProcessWire called PAGEGRID. At first, we were going to develop our website the usual way, but then we decided that we should take PAGEGRID for a spin and beat the hell out of it, to see what we could come up with ? We had this idea of three rows scrolling in different directions, and because PAGEGRID has scroll animations built in, we managed to do it all without writing a line of code. We may write a case study soon for those who are interested.

There are a few commits on the dev branch this week, but nothing particularly notable. I had to do some client work this week but also ventured back into the Invoice site profile, which I mentioned quite awhile ago, but hadn't yet released. I'm hoping to finish that up and release it as another site profile option for ProcessWire very soon. Perhaps as soon as next week. I had originally planned on building out that Invoice site profile quite a bit more, but having used it for my own invoices for many months (maybe a year?), I think it's better to keep it simple. Otherwise I'd be making assumptions about what others might need. Even in its relatively simple state, it suits my own needs well. And I think if it gets more complex, then people are less likely to explore and modify it, making it less useful as a site profile. The site profile is also simple enough right now that it doesn't need to be a Pro module or need Pro-module support. Since we don't have a lot of site profiles to choose from, I'd rather keep it free. It is admittedly more of a mini application than a website, which is why I think it might bring some more diversity to the available site profiles. Chances are it won't replace whatever invoice service you might be using, but I think it's still pretty useful, whether using it to create invoices, or just using it to explore more of ProcessWire. More next week. Have a great weekend!

On the dev branch this week we have a good collection of issue fixes and feature requests. The dev branch commit log has all the details. One feature added this week which I think could come in very handy is #520 (via @Jonathan Lahijani) which adds the ability to hide individual images in an images field. When an image is hidden, you can see and work with it in the admin, but it gets removed from the field value on the front-end of the site at runtime, effectively hiding it. I know I'll use this a lot, particularly on photo galleries where I may want to remove an image or two from appearing in the grid of photos, but don't necessarily want to delete them. Images can be hidden (or unhidden) from the Actions select of each image, where you'll see a "Hide" option (or an "Unhide" option if the image is already hidden). Hidden images are also dimmed out when viewing the images field in the admin. On the API side, you can hide or unhide images and files using $image->hidden(true) to hide, $image->hidden(false) to unhide, and $image->hidden() to get a true or false as to whether or not the image is hidden. Though this will only be useful on unformatted field values, since hidden images are automatically removed from formatted field values. The same can be used with regular file fields, but we don't currently have a UI/interface for hiding or unhiding items from regular (non-image) file fields. Likely we'll add one soon, but I figured it's likely to get more use with image fields than file fields, so figured we'd start there. More next week. Thanks for reading and have a great weekend!

I have no idea how Tailwind works but when I need something like this I usually set a CSS variable and add them with the style attribute where needed. Something like: <?php namespace ProcessWire; ?> <div style="--color: <?= $page->color ?>"><!-- My content --></div> When I need something more complex, say a CSS animation depending on some of the page parameters (e.g. children count) then I output in a <style> element within my template.

Something I've wanted in ProcessWire for a long time is full version support for pages. It's one of those things I've been trying to build since ProcessWire 1.0, but never totally got there. Versioning text and number fields (and similar types) is straightforward. But field types in ProcessWire are plugin modules, making any type of data storage possible. That just doesn't mix well with being version friendly, particularly when getting into repeaters and other complex types. ProDrafts got close, but full version support was dropped from it before the first version was released. It had just become too much to manage, and I wanted it to focus just on doing drafts, and doing them as well as we could. ProDrafts supports repeaters too, though nested repeaters became too complex to officially support, so there are still some inherent limitations. I tried again to get full version support with a module called PageSnapshots developed a couple years ago, and spent weeks developing it. But by the time I got it fully working with all the core Fieldtypes (including repeaters), I wasn't happy with it. It was functional but had become too complex for comfort. So it was never released. This happens with about 1/2 of the code I write – it gets thrown out or rewritten. It's part of the process. What I learned from all this is that it's not practical for any single module to effectively support versions across all Fieldtypes in ProcessWire. Instead, the Fieldtypes themselves have to manage versions of their own data, at least in the more complicated cases (repeaters, ProFields and such). The storage systems behind Fieldtypes are sometimes unique to the type, and version management needs to stay internal [to the Fieldtype] in those cases. Repeaters are a good example, as they literally use other pages as storage, in addition to the field_* tables. For the above reasons, I've been working on a core interface for Fieldtypes to provide their own version support. Alongside that, I've been working on something that vaguely resembles the Snapshots module's API. But rather than trying to manage versions for page field data itself, it delegates to the Fieldtypes when appropriate. If a Fieldtype implements the version interface, it calls upon that Fieldtype to save, get, restore and delete versions of its own data. It breaks the complexity down into smaller chunks, to the point where it's no longer "complexity", and thus reasonable and manageable. It's a work in progress and I've not committed any of it to the core yet, but some of this is functional already. So far it's going more smoothly than past attempts due to the different approach. My hope is to have core version support so that modules like ProDrafts and others can eventually use that API to handle their versioning needs rather than trying to do it all themselves. I also hope this will enable us to effectively version the repeater types (including nested). I'm not there yet, but it's in sight. If it all works out as intended, the plan is to have a page versions API, as part of the $pages API. I'll follow up more as work continues. Thanks for reading and have a great weekend!