Robin S

Hi @tpr, I've been having intermittent problems when using the save hotkey. I get the overlay but the form is not submitted. It's been happening on remote sites and on localhost, but I'm not sure exactly what version of AOS I first noticed the issue with. There are no errors in the browser console when the issue occurs. Browser is Chrome on Windows. Tricky one to debug because it only happens intermittently - just thought I'd mention it in case others have been experiencing it too. I'm wondering if the behaviour of the save hotkey could be a little less restricting so if an issue like this does occur the interface is not locked and the save button is still accessible. Currently I have to use my browser dev tools to remove the height and width from the added pseudo-element and allow pointer events.

The inputfield could be approached a similar way to Profields Table, which does support large amounts of data through limiting and pagination. It was the introduction of pagination within Table that prompted my GitHub request. But although an inputfield solution is important it is the API side that is of greater importance. Currently you cannot do anything with the value of a Page Reference field without loading all the pages into memory. So if you have a Page Reference field with 2000 items and you do... $item = $page->my_page_reference->first(); ...or... $item = $page->my_page_reference->findOne("name=foo"); ...then boom, you have 2000 pages loaded to memory. It's not like $pages->find() or $page->children() where you can be selective or limit what is loaded. Compare with $page->children(): parent-child is one kind of basic relationship between pages. Page Reference is the other kind of basic relationship between pages. Both of these relationships should be able to scale up, but currently only parent-child does. This discussion probably warrants it's own topic.

Matching by tempate name in a PageReference field is working for me: $items = $pages->find("test_page_reference.template.name=basic-page"); Could it be that you have no template named "events-detail" or no pages using that template selected? Incidentally, how did you dump the selector to get the selector string that PW converts to? Looks like a useful debugging trick.

Thanks, good to know.

Does that cause a problem though if you are doing a numerical comparison on the version? For example, in the "requires" item of getModuleInfo() or in the upgrade() method?

I think you should be able do this... $result = $pages->find("template=listing, (field1=data, field2=data), (children.field1=data, children.field2=data)"); ...but it's giving me buggy results when using child fields in the selector (works as expected for name and ID). Will do some more testing later and look at filing a GitHub issue. Alternatively consider including the variation pages in a field within the listing page (i.e. Repeater, PageTable or Page Reference field) so you can match their containing page in the selector.

Did you push this yet? Not seeing any new commit in the repo. I think there might be some other issue with the module regarding the modules directory, because the directory is showing v0.0.3 but SelectizeImageTags.info.php is v0.0.7. Maybe the getModuleInfo() in the main module file is still being read despite being commented out? Absolutely - the key/value tags is a big benefit and was about to recommend it to someone because of this when I struck the install issue. I just thought there was some discussion about the module being impacted by the core changes, but I might be misremembering or those things are now resolved.

The PDF thing isn't the main issue - that just happened to be the source of the website content in my example. The crux of it is: you have a website which consists of HTML and Javascript and images. Mobile devices have all the technology built in to render and browse this content. So why should it be so difficult to bundle those files up into some distributable format and view it offline on the device? If someone brings a tool to market that does this they can make a stack o' cash.

An example would be if you want to use a Page Reference field to store "likes", where each user that has liked a page is added to the field. For a large site with thousands of users this becomes a problem. There would be plenty of other examples for sites with very large numbers of pages. Pages (in the broad sense of being some grouped data) are of course central to the PW philosophy. And Page Reference fields are the primary way to make connections between pages. So it's important that this be able to scale up for PW to be seen as a credible candidate for large projects.

Hi @Macrura I'm not able to install SelectizeImageTags in PW 3.0.83. Edit: I can install it if I download and manually copy the directory to /site/modules/ This came up a while back... ...were you able to get to the bottom of what was causing it? Also, if I am able to install the module is it still working given the changes to image tagging in the core? I remember you discussing this with Ryan when the core changes were made and just wondering where things stand.

The selectable pages for a Page Reference field can come from anywhere in the tree - this could be hugely nested and several levels of parents may not be included in the selectable pages. So I don't think it would be possible to reliably and accurately display the tree structure for a list of checkboxes. Pagination is not supported in any type of Page Reference inputfield or in the value that is returned by a Page Reference field. It would be fantastic if it was, because the current state of affairs limits the extent to which Page Reference fields can scale up. It's one of the big limiting factors for PW in my opinion. There is an open GitHub request that you could add support to if you like. The way you are using the Page Reference field is not typical I think so perhaps not likely to become supported in the core. More typical would be to use a Page Reference field on the website pages to select a call-to-action page. You could possibly add Connect Page Fields to have the relationship work both ways and get an overview from the call-to-action page. Note also that you can use a custom label format for your inputfield to include the name of the parent page(s) if you want to get a sense of how nested the selectable pages are. Using a hook to set the label would give you greater control. Lastly, it's not outside the realm of possibility to create your own custom inputfield, using InputfieldCheckboxes as a starting point.

Sounds amazing! It would be good to get some guidance/opinions on what is the optimal way to prepare release notes. I'd rather not have to duplicate the same information in release notes, tags, changelog and detailed commit notes, but don't really want to be "told off" by the module for not doing it either.

DPS looks interesting and I will check that out. Though it still seems like work will be duplicated if the client also needs to deliver the content via a website. That is a great suggestion! I had completely overlooked EPUB format. I don't know a lot but an EPUB is essentially HTML right? So potentially quite easy to go from static HTML files (could even grab them from ProCache?) to EPUB. I think Calibre can do it but there are perhaps more professional tools. This also looks promising: https://epub.press/

Thanks for all the replies! In my scenario (which I'm investigating mostly out of curiosity as the client is not pressing me for a solution to this) there would not be a budget for an entirely new app development. The desire is to present an existing website via an app wrapper. It seems like there are a bunch of SaaS providers who offer this (the ones I found all looked kinda dodgy) but with the catches being: 1. An internet connection is required, because the app user is essentially just browsing your live website inside a wrapper. What I'm looking for is something that could crawl a website and then save the content for offline browsing. For Android there is this: Offline Browser - which looks pretty good, but it's for general-purpose browsing. I'd like something that can be packaged up and distributed for just for one website. 2. You have to pay an ongoing subscription for the provider to do basically nothing. 3. If the provider goes bust (and several I looked at did not inspire confidence) your app goes bust too. Thanks, will look into that. Seems like development would be faster than some other options, but I think it would still be a fairly costly addon for the client to pay my development time. In this project there were a lot of images so would definitely go beyond 50mb. Also still not sure if the service worker can crawl the entire site without users actually browsing to those pages. Cool idea, but in my example the end users are forestry roading engineers working in different locations across the country so probably not viable to give each their own Raspberry Pi. Would also need a pretty rugged housing. That's not the objective - it's actually sort of the opposite of the objective. The source format is PDF but the problem is that the PDF layout is for a large-format printed book. It does not adapt well to small screens. Also I think the client is enthusiastic about the prospect of making easy document edits via the PW backend. I think there is a gap in the market here (anyone looking for a startup idea?). Off the top of my head I can think of half a dozen previous projects where I think the client would have liked to be able to deliver basic static website content offline to mobile devices. Worldwide there would be a big audience for this. What's needed is the same sort of native wrapper idea the SaaS providers are selling, but with the crawl-and-store features of the Offline Browser app. And sold as a one-off purchase because I think buyers know there is not a lot of ongoing service being provided that justifies a subscription, and would like the confidence that the app keeps working if the provider goes bust. It sucks that Apple are so restricting about the delivery of iOS apps, but I suppose there are security concerns and a lot a malicious agents out there.

I recently worked on a project where I adapted an engineering manual (from the print-ready PDF) to a responsive online document. Over time more documents will be adapted. It wasn't part of the original brief, but after the work was completed the client asked if there was some way the online document could be viewed offline on a mobile device, in situations where there is no internet coverage. It seems like there should be solutions to this but I'm not up to speed on what is possible in this regard. A few questions if anyone can help... 1. Has anyone used a website-to-app conversion tool or service that they recommend? Is this a good way to go or best avoided? I Googled it and found a few options but they were either fairly pricey (e.g. Mobiloud) or pretty limited (e.g. AppStrand). I don't need much in the way of features and there isn't much interactivity required - basically just static text and images. 2. Is it possible to distribute an app outside of the Apple App Store and Google Play? In my scenario this would be a non-commercial app with virtually no appeal to the wider public so I suspect that Apple and Google would not accept it into their stores. Is it possible to provide an installable app via a private website? 3. Besides an app, are there other options that would allow a website to be browsed offline on a mobile device? There is software like HTTrack that will crawl a website and save it for offline browsing on a desktop computer, but I'm pretty sure this won't be a solution for mobile devices as they don't have a proper file system. I've know vaguely of service workers but not sure if that's a good solution either. Would a service worker allow an entire website to be browsed offline or only pages the user has previously visited? TIA for any tips or experiences.

@rafaoski, do you know about the Site Profile Exporter module? You can make your own profile (or edit an existing one) and add in whatever technologies you want, then export it and use it for new PW installs. I'm not sure why any of the things you are requesting need to be connected with the PW core as everyone's preferences are different. When it comes to profiles that are bundled with the core I'd like the number to reduce (to, like, 1 maximum) because for me I never use them and it's just unnecessary megabytes that have to be downloaded and unpacked with every new core release. Currently nearly half the size of the PW downloadable core is made up of site profiles that for some users (most?) will just be immediately deleted. I'd rather see each "official" profile in it's own GitHub repo where they can be downloaded only if needed.

The below works for me with AJAX updates. In /site/init.php: $wire->addHookAfter('InputfieldPageTable::renderTable', function(HookEvent $event) { $out = $event->return; // Add checks here for specific PageTable fields, specific templates, etc. // Your table header replacements $replacements = [ 'Title' => 'Foo', 'Headline' => 'Bar', ]; foreach($replacements as $find => $replace) { $out = str_replace("<th>$find</th>", "<th>$replace</th>", $out); } $event->return = $out; });

Maybe the arrows could float right next to the Save button? Besides not moving so much between pages, on the default theme it would also have the benefit of less confusion with the breadcrumb separators (which look quite similar).

Thanks for the speedy implementation!

Could you just pass null as the title argument in that case? Or is that just as much hassle? Looks great to me.

Maybe remove the space between the label and the dump output? Ryan does that sort of thing all through the core so I figure it's not too hacky.

Hi @adrian, What do you think about adding a way to label dumps in the console, similar to what is possible with barDump? So you could do: d($foo, 'Foo'); d($bar, 'Bar'); This would help to identify which dump is which.

Not working in what way? Your files are listed but in the wrong order? It looks like it should work.

That reminds me of when I first came to ProcessWire. My impression was that PW was really powerful so I expected it to be difficult to use and so I thought "I'll only use PW for really complex sites that need it". But as soon as I had built my first site I knew I was never going to use anything but PW from that point on, even for basic brochure sites. Once you have understood the basics then development with PW is super fast. For developing custom sites (i.e. excluding off-the-shelf themes tied to a specific CMS, and who wants to work on those anyway?) I think PW is the fastest, most intuitive and most elegant framework out there.

The templates folder is at /site/templates/, so it's still within /site/. I don't recommend changing any of the security restrictions in the PW htaccess file.