psy

The repeater parent is not the page that calls the repeater item. To get the page that it appears on, you need to use 'getForPage()'

Yep, everything I had working with AppApi and REACT/NextJS broke with the PW 3.0.173 upgrade. Downgrading is a short-term option but limits future PW upgrade benefits

Doing a little happy dance. Has only taken me a week to figure out how to match React/NextJS to work with @Sebi's amazing AppApi module with pages below the top level, ie routing. I'm sure many of you PHP/PW gurus would have figured it out sooner

@Sebi Thanks for the quick response. I'd already gone past that point both in PW and Postman so the connection is good. I'd even written my own method in Examples to get a page by ID. Maybe not as sophisticated as yours but it too worked: <?php namespace ProcessWire; Class Example { public static function test () { return ['test successful']; } public static function getPageById($data) { $data = AppApiHelper::checkAndSanitizeRequiredParameters($data, ['id|int']); $p = wire('pages')->get("id=$data->id"); if(!$p->id) throw new \Exception('Page not found', 404); $response = new \StdClass(); // Hardcode any data you need that does not have an inputfield field in the admin $response->id = $p->id; $response->name = $p->name; $response->path = $p->path; // This retrieves all the admin input fields. Does not (yet) get page images or files, just single entry data $fields = $p->getFields(); foreach ($fields as $fld) { $fldName = $fld->name; $response->$fldName = $p->$fld; } return $response; } } This enabled me to get the page data into the NextJS client and embed in the 'template/component' as variables from any existing PW page. My next exercise was to delve into the NextJS router so that I could retrieve pages via their path and those paths would appear in the URL. Couldn't work it out in my own PW code (no surprises there!). It was then I installed your Twack module and used the Twack routes & TwackAccess.class.php at which point I ran into the issues mentioned above. I'm sure it's my lack of knowledge of REACT/NextJS rather than your code... Doesn't help when their doco doesn't match up with their examples in gitHub. Even so, it would great to use your TwackAccess classes rather than reinventing the wheel.

Excited to be learning REACT/NextJS. It's so 'on-trend'. I can double my hourly rate, take 3x as long to deliver a website with 2/3 of the Google Lighthouse results and who doesn't love the spinner while the component content loads? Doing a well optimised PW site with minimal JS, fast page loads, accessibility, SEO and more built in is so old hat. And even better, with JS frontends, the code maintenance goes on and on. No end to revenue possibilities. FML

I've read the doco, installed the module & Twack and no matter what I try when retrieving a page, all I get back is a successful Promise or worse, an error message about invalid json. Using React/Nextjs and the page is published, viewable & using the basic-page template. The authorisation is single JWT and the client JS code is: export async function PWPageByUrl(path) { // url is correct and returns a result, just not the one I was expecing const res = await fetch(`${process.env.NEXT_PUBLIC_API_URL}/${process.env.NEXT_PUBLIC_API_VERSION}/page/${path}`, { headers: { 'x-api-key': process.env.NEXT_PUBLIC_API_KEY, 'authorization': process.env.NEXT_PUBLIC_TOKEN } } ) const data = await res.json() if (!data) { return { notFound: true, } } return { props: { data }, // will be passed to the page component as props } } On the PW server side as per doco with routes modified for v1, I have: I'm obviously missing something. Help to get it working as expected much appreciated. Thanks

Once you've created your $year_overview PageArray, does the template use custom fields from the pages to generate the output? If so, it may be that the slowness is due to multiple calls back to the db during loops to get the custom fields' data. Try including the custom fields in the initial selector with 'auto-join' or using the new methods released by Ryan. https://processwire.com/blog/posts/find-faster-and-more-efficiently/#boost-performance-with-new-programmatic-autojoin-options

It's a premium module but I believe Repeater Matrix will do exactly what you need. It's one of my 'must haves' on every site I create. It's part of the ProFields pack and I use other features on every site too, like Functional Fields . I'll be using the new Combo field as well. The time it saves me is well worth the investment not to mention the great support in the forum from other ProField users & Ryan himself. https://processwire.com/store/pro-fields/

@Rudy & @Craig Thank you both ?

This is driving me nuts! What I want to do is get 'today' with a name, eg 'Tue', then create an array of week day names going backwards for a week, eg "Tue Mon Sun Sat Fri Thu Wed". My code is where $today is a timestamp for 'today': private static function _onlineWeek ($today, $progams) { $dt = wire('datetime'); $result = []; $dayNames = []; for ($i = 0; $i <= 6; $i++) { $daySeconds = $i * 86400; $dayTS = $today - ($daySeconds); $day = $dt->date('D', $dayTS); $dayNames[] = $day; } $result['labels'] = $dayNames; return $result; } The result is as follows starting with "Thu"???? array(1) { ["labels"]=&gt; array(7) { [0]=&gt; string(3) "Thu" [1]=&gt; string(3) "Wed" [2]=&gt; string(3) "Tue" [3]=&gt; string(3) "Mon" [4]=&gt; string(3) "Sun" [5]=&gt; string(3) "Sat" [6]=&gt; string(3) "Fri" } } Php dates are always a nightmare for me and this just doesn't compute in my brain. What am I doing wrong and suggestions on how to fix gratefully appreciated. Thanks in advance psy

Hi @MoritzLost thanks for your reply. Obviously, I'm new to workbox and really appreciate the feedback ? Probably no reason other than when I did, I got lots of errors in the console. Precaching important pages is an excellent tip, as is auto-generating workbox-config.js in PW then including it in the service worker. This is my first successful attempt with Workbox after many, many failures trying to follow the docs. Just wanted to get it working. I especially struggled with the workbox-config.js generation using the CLI. The 'publish' directory cannot be '/' - which it is in PW and when when I could get it to generateSW with the publish directory as the root, it picked up loads of unnecessary files eg in /modules/, /assets/, etc. Seemed easier to create it manually than unpick the CLI's best guesses. For me, a nicely presented page with a logo & phone number is a better UX than the ugly browser default. At least the user can call if their internet is down.

Around 3yrs ago I got excited about Progressive Web Apps (PWAs) and found a site that magically created an offline experience with a few clicks. It worked until it didn't. Had to backtrack and remove the PWA code on lots of sites due mainly to exceeded offline cache storage causing problems. My JS skills weren't, and still aren't, up to the level of expertise needed to rectify. I still did the manifest.json thing, reduced the network load wherever possible and got some great Google Lighthouse performance results by tweaking PW especially with ProCache. 3yrs is a long time in web life. If 1 dog year = 7 human years, then 1 web year must be 10+ human years. I delved back into PWAs recently and Google Workbox in particular. The biggest hurdle I had to overcome was Google's own Workbox docs. Forget the "Import" statements and the CLI easy PWA method recommended in the docs. They don't (or I could not get them to) work with ProcessWire. They're geared to web apps like React that have a build process that publishes to a directory eg 'app'. ProcessWire doesn't work that way. So here's what worked for me: Create a template. I called mine "offline" that may only have one page, no children and does not have a trailing slash at the end of the URL. Create a page, add fields as necessary, eg 'body' and apply the 'offline' template and save as a child of "Home" Change the page url to 'offline.html' - this is the default page name for Workbox. Easier to change this than fiddle around overriding the Google Workbox defaults. For extra comfort, I made the page name 'Unique' and 'Hidden' from lists and searches. Ensure the workbox service worker javascript is NOT appended to the offline.html page On all other pages append the following to the <body> tag. I'm using Regions so this goes in my <region id="regFooterScripts"> in _main.php <?php if ($page->name != "offline.html") : ?> <script> if ('serviceWorker' in navigator) { let scrUrl = '<?=$pages->get('/')->httpUrl?>sw.js'; window.addEventListener('load', () => { navigator.serviceWorker.register(scrUrl, {scope: '/'}).then(registration => { console.log('Service Worker registered: ', registration) }).catch(registrationError => { console.log('Service Worker registration failed: ', registrationError) }) }) } </script> <?php endif; ?> Next, by hook or by crook, get the workbox library into a directory of your PW project. You can use the CLI 'copyLibraries' feature. See https://developers.google.com/web/tools/workbox/modules/workbox-cli for more info. Do NOT use any of the other CLI features! You can also download the library from gitHub. Didn't go there so please don't ask for help. I used the CLI method & saved the files to site/templates/scripts/workbox. Now you can start building your sw.js file which is saved in root directory. Here's mine using the Google Workbox docs & recipes. The big thing to remember is NOT to "Import" anything despite what the docs say. When you configure workbox to use your local copy of the library, all importing is done for you by using the 'workbox' namespace. importScripts('/site/templates/scripts/workbox/workbox-v6.0.2/workbox-sw.js'); workbox.setConfig({ modulePathPrefix: '/site/templates/scripts/workbox/workbox-v6.0.2/', globIgnores: ['processwire/**.*'] // change according to your PW admin URL }); // Include offline.html in the manifest workbox.precaching.precacheAndRoute([ {url: '/offline.html', revision: null } ]); workbox.routing.registerRoute( ({url}) => url.pathname.startsWith('/processwire/'), // change according to your PW admin URL new workbox.strategies.NetworkOnly() ); workbox.recipes.googleFontsCache(); workbox.recipes.pageCache(); workbox.recipes.staticResourceCache(); workbox.recipes.imageCache(); workbox.recipes.offlineFallback(); These are all the basic workbox features & recipes including offline.html and will probably need updating as time goes by. Up to you to add/modify/delete as you like and outside the scope of this tutorial. Good luck & have fun with Google Workbox PWAs in ProcessWire sites.

You can use padding/margins to tweak but first define your rows and columns so that they overlap where required. In the example below I have a text block partially overlapping an image. On small screens, the text overlaps at the bottom and on larger screens, the text is on the left and overlaps the image on the right.

Kevin Powell has a good tutorial using grid columns and rows to overlap content.

Lighthouse results for home page. Best practices & speed pulled down by annoying chat applet (forgot to mention that js - not my code or choice). Not sure of server spec. Shared hosting account. So, not under 100ms in this scenario but I'm happy when Google is happy ? Thanks for the tip. Will get image from client ?

@flydev ?? ? The home page has no caching. It's pure HTML & CSS including the gallery slider above the footer. CSS is such a powerful beast and HTML now has image lazy loading. The images in the slider, subsets of party packs, list of suburbs & featured customer love change on every page load which is a testament to the power & speed of PW

Thanks @flydev ?? and I'll check what's happening in Safari (the new IE ?) Edit: Scroll bar works on my MAC with Safari 14.0.1 so not sure why it's not working for you

Client happy with Happy Monkey ?

A little more to the back story... Client's biggest target audience is children's parties hence the look. The only time I said an absolute "NO" to client was when client said use "Comic Sans" font. There are some boundaries I will not overstep! Heading font is Google 'Happy Monkey'. ?

This site has been a long time in the making. Back story: Was first developed in PW 2.something many years ago. Around 5yrs ago, it underwent a major upgrade. The look was very 90's and the booking page had around 50 input fields on the one page. See screenshots. Original dev, who did a great job with web technology at the time, went AWOL Business was sold to a new owner New owner engaged me to revamp the site. I laugh & laugh & laugh. If only I knew then what I know now! It was crucial that the years of historical data be kept and accessible Busy period is November to February (Aussie summer). And then came COVID. Victoria was the state hardest hit with C19 in Australia and lockdowns were harsh. Definitely no parties. The possible product configurations, hire rates & rules (all with 'except for this one') had me melt into a puddle at times. Pricing is shown on product pages only when a valid venue postcode & event date entered and can change depending on the surface type (eg concrete attracts a $50 surcharge) One of the biggest things that tripped me up was the previous dev combined data/module logic with presentation HTML. I had to rewrite all the old code to adapt to the new layout. Would have been much easier to have logic & presentation separated. A while ago I chose to stop using CSS frameworks to dig deep into how CSS really works. Much of what I have learnt is in the site frontend code. The site is fully responsive and the only JS used is on the View Booking page when a customer alters the booking item qty. There is NO frontend presentation JS, including the dropdown & mobile menus. Where it stands today: There are still some things to do, including implementing a very sensible change recommended by @ryan. In addition to the frontend, there are a number of new backend/admin reports Victoria is coming out of C19 hell and getting back to normal The site is live and online bookings are rolling in New modules added: ProCache FormBuilder + StripePayment + Page Break CampaignMonitorAPI ProFields - Functional Fields ProFields - Repeater Matrix RockMarkup2 Database Backups Upgrades SeoMaestro TracyDebugger Page View Statistic Big shout out 'Thank you' to all the PW devs who responded when I reached out for help in the forum. Check out the new look www.aaronsamusements.com.au

@PCuser Glad to help. Suggest editing your original post and inserting [solved] to the start of the title ?

@PCuser there many ways to sanitise data using $sanitizer, eg pageName, digits, text, camelCase, etc, which is why you need to let $sanitizer know which method to use. They're all listed in the documentation. ?

@PCuser you need to let Sanitizer know what kind of clean-up to do, eg: $sanitizer->pageName($sportspage->title) will convert the title text to lowercase and replace spaces with hyphens to make it suitable for use in a URL (or HTML id attribute). See what other $sanitizer methods are available at https://processwire.com/api/ref/sanitizer/ PS: Page titles can change and also not be unique. I prefer to use a letter first (HTML ids must start with a letter) then use the page ID, eg s1234. Alternatively, you could use the existing page name rather than the title.

@joe_ma Maybe something like (untested): <?php $content .= '<main class="front">'; // Container for circles $content .= '<ul class="topCircles" role="navigation">'; // nav list // Output of 16 li elements with links at the chosen postions $items = $page->children("limit=16, sort=sort"); // PageArray limited to 16 items. Sorted according to template/page children settings foreach ($items as $item) { if ($item->front_position == $item->index() { $content .= '<a href="' . $item->url . '">' . $item->title . '</a>'; } $content .= '</li>'; } $content .= '</ul> </main>'; // Ende Liste und Container From the PW API Docs: https://processwire.com/api/ref/page/index/

@joe_ma not sure if it's the issue but seems to me you're using a PHP array functions on a ProcessWire PageArray object - different beasts Is not a PHP array. It is a ProcessWire PageArray.