Leaderboard

View website: ID Studio Web Agency We have been working on the ID Studio website for quiet some time using ProcessWire extensively for ourseleves and 90% of all our clients. This post will highlight some features we have implmented and also show off some of the hidden functionality. A quick overview is as follows: Custom web design of course 🙂 Front-end uses Canvas and Three.JS The core objective for us is to get users engaged, reviewing the showcase and services, then getting in touch The showcase and blog have alot of content We hide the ID Lab and About section in the footer but there if folks want to dive in and have the time Development features include: We use the form builder system with some custom modifications 3D tools and management Linking 3D elements to HTML elements Repeater matrix for content panels and lots more, best way is to see it on the video overview below ID-Overview.mp4

I'm loving config migrations more and more 🥰 They reduce complexity and increase stability and performance. Win-Win! Wherever you want. Nothing changed here. You can put it in /site/migrate.php, you can put it in your /site/modules/Site/Site.module.php module's migrate() method, etc... I have to correct myself here @Jonathan Lahijani Today I had to create the following page reference field: <?php return [ 'type' => 'page', 'parent_id' => '/tags/', // ... ]; The "parent_id" setting caused a problem, because the /tags page did not exist when this was run, so the migration failed. I went ahead and implemented a way to properly, reliably and easily create new pages with your config migrations: MAY I INTRODUCE: Config Migration Hooks 😍 😎 🚀 Please check out the dedicated docs page, which are at the moment only on the dev branch and will soon be merged to main and then be also available on my website: https://github.com/baumrock/RockMigrations/tree/dev/docs/config-migrations-hooks

Maybe just check if the field is empty. $page->sales_details !="" or $page->sales_details !=''

Happy new year everyone! I've been working on adding multiple tab support for the console panel. It works in conjunction with the snippets panel so you can load up multiple snippets, or create any number of temporary (unsaved) tabs of code. Each tab has its own execution history stack and the last result for each tab is also maintained so you can flip between tabs to see the differences between results. It automatically names tabs like a typical code editor does: Untitled-1 initially, and then using the first line of code. Of course when you save the tab to a snippet, the tab name will be that of the snippet filename saved to disk. I'll push it live soon, but if anyone sees this and would like to test and provide feedback beforehand, please take a look at this branch: https://github.com/adrianbj/TracyDebugger/tree/console-tabs Thanks!

The plan was to merge dev to the main branch today, but I’m still working through a couple of GitHub issues that I’d like to resolve or finish the conversation before finalizing the 3.0.244 main version. One example is this issue report where it was pointed out that there are some issues with UTF-8 page names. ProcessWire uses PHP’s IDN functions to manage conversion to and from the non UTF-8 version of the URL. PHP 7.4 changed the default arguments of the idn_* functions to settings that made them not work 100% for page names in a few cases, which I didn’t realize before this week. But this is not an issue that I can just fix and be done with it… There may already be page names in any given installation that are affected by the post PHP 7.4 behavior. If I were to just fix the issue, then some affected pages might no longer match when accessed directly by URL. So this had to be a carefully considered fix. What I ended up doing is fix it for any new PW installations that occur after this weekend. PW keeps track of its installation date, so can do this by way of its $config->installedAfter(“2025-01-05”) function. Existing installations will keep the imperfect behavior. Presumably it doesn’t affect that many installations since it only came to light last week and PHP 7.4 was released roughly 5 years ago. Nevertheless, existing installations that want the “fixed” behavior can get it by specifying this in /site/config.php: $config->pageNameWhitelist = 'v3' . $config->pageNameWhitelist; That essentially says to use version 3 of the page name conversion. Version 2 will also work fine, but may be slightly slower since it uses a dedicated Punycode library. And version 1 is the one that worked correctly until PHP 7.4, and still works mosts most of the time, but can produce imperfect results in some cases. Installations prior to 5 Jan 2025 use v1 by default and installations after 5 Jan 2025 use v3 by default. Chances are few (if any) will want to specify the version manually like above, but the option is there, just in case. That’s one example of why I’m waiting another few days before the dev branch merge to main. Another is that Adrian mentioned double-clicking on the “Move to Trash” button [in the page editor] makes it permanently delete the page rather than trash it. While I can’t duplicate that, despite multiple attempts, I just want to make sure there’s not something that needs fixing there. But unless any major new issues turn up, by this time next week we’ll merge to main and bump the version to 3.0.244. Thanks and Happy New Year!

Hi all, I won't always post here when I update Tracy, but I will when I think the update is an important bug fix that you really should update to. There was a bug in the new 2.8 branch of core Tracy package that was sometimes causing recursion and really slow load times and sometimes memory exceeding errors. This has been fixed and is available in 4.21.41 of Tracy released today.

No, everything is good. A really useful set of features, thanks!

ah great good news! thanks will give it a try!

It's long overdue for a refresh of a personal website. At least it was built on the fantastic ProcessWire! Pats website awkwardly. I gave this poor thing a makeover before it got mistaken for a museum exhibit. I hope for positive comments, but I would rather listen to what the critics say to improve. It is not yet tweaked to the details (I am on the heroin run for the proper images for service pages), but it is something I can brag about. Here is the link: Digital Marketing Montenegro

I also had the same issue, and your trick worked for me. Thank you.

@adrian, thanks, the history is working for me now. I think this is caused by a combination of the button height being in fractional pixels and the scaleX(-1) transform on the right arrow. This causes Chrome to round the two arrow buttons to different numbers of whole pixels. There would be a several different ways to solve this, but perhaps the easiest thing would be to use the FontAwesome right arrow character for second arrow button rather than flipping a left arrow character. You'd also then tweak the margin and border on that button seeing as it would no longer be flipped. Leaving the coloured border on all sides and adjusting to margin-left: -12px looks good to me.

@Robin S - just occurred to me that my fix for the history issue won't work if you upgrade your already upgraded version, so if you do that, please delete these localStorage items manually so that they will be automatically re-created in the right format. https://github.com/adrianbj/TracyDebugger/commit/9d7d42501ead93460d27cda4829eed780239c2aa

Thanks @Robin S for the testing, much appreciated. 1) Sorry, I thought I had dealt with all upgrade issues but missed that one 2) Yeah, that is the intended behaviour - I was treating it as a way of loading up the saved version in a separate tab without losing any potential changes to the currently open version. I know it's different to how VSCode (and probably other editors) work though, so maybe I should reconsider. Anyone else have thoughts? 3) This was also an upgrade issue - the structure of the history stack needed updating but wasn't being overwritten if it already existed. 4) I am not seeing this pixel issue - any chance you could help narrow that down: Latest commit should fix 1 & 3 Thanks again.

I know this is an old issue, however somehow I'm running into this issue also on a local installation. How it came to light, localy has_parent selector gave empty results, which should'nt have happend. Testing showed that has_parent only would give direct parent page as result. When I took a look at the pages_parents table it shows only 6 entries. However the original database import had 343800 entries. So I wonder what is / could be causing these entries to disapear. How and if it can it be rebuild. And is there a relation between has_parent selector and the table pages_parents? The instance of ProcessWire is running PW 3.0.200 with PHP 7.4.33

DaCha is a water sports center in Egypt and a hotel. https://surfdacha.com/en/ Multi-language. The backend implements the management of customer reservations and bookings. Naturally, the website is made on ProcessWire. UiKit 3 layout Modules: LoginRegisterPro, Cookie Management Banner, Map Marker, FrontendForms, Markup Sitemap XML, Video embed for YouTube (and Vimeo), Tracy Debugger. The backend implements the management of customer reservations and bookings.

@joe_g That's right, it doesn't look like there's any reason to provide #maincontent for your situation. When populating markup regions, specify just the region you want to replace, append, prepend, or delete; not a structure of markup regions. Though you did have that case above where you were trying to a direct child to it: <div class="p-8"> outside of your _main.php, so in that case you would, or you could do a <div class="p-8" pw-append="maincontent">...</div> or <div id="maincontent"><div class="p-8">...</div></div>. I recommend adding <!--PW-REGION-DEBUG--> somewhere in your _main.php markup (like at the bottom), and that'll be automatically replaced with some markup that tells you everything your Markup Regions are doing and when it can't find where to place something, etc. Most of my sites have something like this below, and it's handy to look at when you aren't sure why something isn't working, etc. <?php if($config->debug && $user->name === 'ryan'): <div class"uk-container uk-margin"> <!--PW-REGION-DEBUG--> </div> <?php endif; ?> Another tip is that if you ever find Markup Regions are having trouble finding the closing tag for some specific element, you can tell it specially by marking it with a hint comment <!--#maincontent-->. Though I also just find it visually helpful, so I tend to do it whether for markup regions or not. <div id="maincontent"> ... </div><!--#maincontent-->

Just happend on PW 3.0.163. Fixed by rebuildAll method available since 3.0.156 $pages->parents()->rebuildAll();