AAD Web Team

We've found the same thing on PW 3.0.148 with any custom image fields, when the images are inside a repeater. After drag-and-dropping the images in, on the first save after that, any custom field text (e.g. caption, photographer) is simply lost. In a subsequent save, the text is saved fine. Every time a new image is dragged in, the page must be saved before adding text to the custom fields for that image. Otherwise text entered for the new image is lost (text previously entered for other images in the same repeater is fine). This seems to have been logged as a bug on 23 January: https://github.com/processwire/processwire-issues/issues/1070

Thanks @Robin S – that's an excellent explanation. I didn't previously know about the difference between PageFinder and in-memory selectors. It'd probably be good if allowable date formats were explained on the selectors documentation page. (I'm not sure what the best process for suggesting documentation updates is.)

The selectors documentation has the example, when working with a Datetime field of: featured_from<=today Does this mean we can use any format compatible with PHPs strtotime function? I tried: my_date>=5 weeks ago …and it seemed to work. What about when using Unix timestamps? The strtotime documentation suggests you'd need: my_date>=@1526265087 … but we just had: my_date>=1526265087 …and it seemed ok. Anyway, given this all seems to work we can just keep doing it, but I wanted to check that this is a 'supported' way to use dates in selectors, so I know we can rely on it.

EDIT: I'm still curious whether this is possible, but given this template has very low usage on our site I've decided to change it to a Verified URL field instead of a Page Reference. Problem solved! Hi, I have a 'redirect' template which consists of basically just a Page Reference field (it was designed for our in-page 'visual' navigation and works perfectly there). However, in our left navigation I'd also like it to point to the URL of the referenced page rather than the URL of the page that has the redirect template applied. I tried 'xitem_tpl' => '<a href="{target_page->url}">{title}</a>', but it doesn't appear to accept the target_page->url syntax (it just points to the URL of the current page instead). Is there a way to achieve this? I'd prefer not to have to hide that template type from the left navigation if at all possible. Thanks! Margaret

What's the best practice for using an external database – say, a MySQL database that lives on the same server as the ProcessWire database, but is separate from it? I had a look at $database in the API, but it looks as if it understandably just refers to the current ProcessWire database.

Thanks @teppo!

Hi again @bernhard and @wbmnfktr, It should now be fixed. Well, I think there's still some kind of bug in the way Chrome for Android behaves, but I was able to completely turn off the 'touch' option for the modal menu instance of Fancybox. Swiping is not needed for the menu so that has fixed the issue, and it doesn't seem to have had any other adverse effects from what I can see so far. ?

I'm just resurrecting this old thread to let you know that our SCARCOMNAP 2020 conference site built in PW is being discontinued. It is being replaced with a site hosted by the conference organiser, so no longer in ProcessWire. The URL will redirect, so I wouldn't want there to be any confusion for people who happen to visit it from here (or the Showcase while it's still listed there). I'm not sure how to remove a site from the Showcase... is this notification sufficient? Thanks!

Thanks @wbmnfktr, I'll certainly have to have a play around with those options (I've left them all at their defaults). However, I would've thought the resulting behaviour should be the same across browsers. In this case, it's only a problem with the Android version of Chrome. In all other browsers that I've tested it behaves as it should, where the menu only closes if you tap the close button or outside the blue menu area.

This is an odd one. It seems to only happen in the Android version of Chrome. If you keep your finger on the menu while scrolling it works, but as soon as you touch the blue background and scroll, the modal closes. In my testing, it doesn't happen in Firefox on the same type of phone, nor does it happen in Chrome or Safari on iOS. I'm not sure if this is a bug with Fancybox or a bug with Chrome for Android - either way I'm not sure how to go about fixing it or even where to report the bug. I'll keep Googling to see if I can find anyone else with the same issue.

Hi @bernhard, I think I've now fixed the issue with the menu that you were experiencing with your phone. Would you mind taking another look? Thanks!

G'day … I'm not sure if this is an actual problem, or just my lack of understanding about how this is supposed to work. We're using PW 3.0.131 with the ImageExtra 1.0.6 module. I'm using the API to automatically import lots of pages with images into PW from a different web CMS. I'm having trouble updating some of the custom image fields, which don't save unless a core image field is also updated. In code, where $p is a particular page and $img is a particular image on that page, this works: $p->of(false); $img->description = 'foo'; // Standard field $img->photographer = 'bar'; // Our custom field created with ImageExtra $p->save(); // Updates the record in the database. But this doesn't work: $p->of(false); $img->photographer = 'bar'; // Our custom field created with ImageExtra $p->save(); // Makes no difference to the record in the database. This also doesn't work: $p->of(false); $img->photographer = 'bar'; // Our custom field created with ImageExtra $p->save('photographer'); // Makes no difference to the record in the database. In all cases the $p->save method returns true to indicate success. Can anyone help me understand what's going on here? Thanks!

Thanks again for your feedback, and for the phone details @bernhard. Browserstack doesn't include any WIKO phones, but I was able to recreate the issue on a Nexus 5. I'll see what I can do to fix it.

Thanks for the feedback @bernhard. May I ask what type of phone and which browser that is? It was tested extensively across a range of devices and browsers using BrowserStack, but there are so many possible combinations these days it's easy to miss some. Your feedback on the navigation is also appreciated. The content presented across the site is very linear in nature as it is based on Douglas Mawson's book, hence the previous and next links. We'll take another look.

Hi all, I thought that you'd be interested to know we've now launched our third ProcessWire site, called Home of the Blizzard - The Australasian Antarctic Expedition. It's about Douglas Mawson's famous expedition of 1911-1914. As a part of the move to ProcessWire from our previous CMS it has undergone a redesign as well. It has been done completely in-house. https://mawsonshuts.antarctica.gov.au/ It uses Fancybox for the image galleries and modal menu, Plyr for video, and Modernizr (primarily to check for CSS Grid compatibility). It was actually the first PW site we started working on, but then the SCAR COMNAP and Antarctic Jobs sites became priorities so it got pushed back. It's great to have it live at last. The next PW site we launch should be our main site (http://www.antarctica.gov.au)! That's still a work in progress. ?

Thanks @teppo for featuring our site in PW Weekly! ? Now I'm back at work and am not rushing to finish a website, I thought I'd add a little extra information about the setup of the Jobs site. For this particular site a great deal of the content already existed on our main site. It was decided that it was time the jobs had a dedicated site, so some design concepts were done by our multimedia and marketing team, and then we set about building the site in PW! A fair bit of the content is just made up of standard web pages with a body, some images and some document uploads - but the key thing that makes this site a bit different is that the Antarctic jobs listing is seasonal. We have a big recruitment campaign at the end of each year (as we are at the time of writing), ready for the next Antarctic expedition season. The jobs are visible on the site all year round, but only open for application during the recruitment campaign. On the surface this might seem like a simple 'on/off' scenario for all jobs, and therefore controllable with one checkbox and and if/else statement... but then there are exceptions. Not all jobs are necessarily open during the recruitment campaign (as you can see on the jobs listing currently, some say 'Apply now' and some say 'Not open': Jobs in Antarctica), and some display slightly different messages about the way you can register interest while they are closed (these exceptions are handled within functions). We implemented a 'recruitment settings' template/page. On here there is a checkbox for stating whether the overall recruitment campaign is open or closed. (This recruitment settings page is also a place where global job information is stored, such as the 'How to apply' section, and the General information for applications PDF that you can see on this page: job example. This means they only have to be edited in one place.) Then on each job there is a checkbox for whether or not the job is independent of the campaign. The default value is no, but if yes is selected the job can then be marked as open or closed individually. This means editors only have to worry about marking the exceptions. This job status functionality was in place on our old job pages on our main site, but in that CMS (Squiz Matrix) the setup was quite complex and it was something we really had to do on behalf of our recruitment staff. It has been nice to be able to give them a customised and more straightforward experience.

We were fortunately able to make the case for using something different, in order to meet our needs (the favoured CMS here is Drupal). It'd be great if we started a new trend!

A couple of months ago we launched our very first PW site, which was just a very small site concerning a conference taking place in 2020. Last week we launched our second site, and it was a much bigger project - https://jobs.antarctica.gov.au/. Our jobs (both in Antarctica and within Australia) were previously a part of our main site at http://www.antarctica.gov.au (which is yet to be redesigned and moved into PW), so we were tasked with creating a brand new site in time for the recruitment season opening in early December. While the timeframe was tight (we only had about a month to build it), it was great to be able to work within PW, and then to introduce our editors to it. They love it in comparison to our old CMS (as do we!).

I've had a dig around in the Wire directory... I've made some changes that have fixed the issue, but obviously that's not ideal as a long-term fix. Anyway, it seems to all relate back to the httpURL method. In ProcessPageEdit.module I've changed this line: $url = $this->page->url(); // was previously $url = $this->page->httpUrl(); This fixes the View > Panel and View > Modal popup options from the Edit screen. In ProcessPageListActions.php I've changed one line in this section: if($page->viewable()) $actions['view'] = array( 'cn' => 'View', 'name' => $this->actionLabels['view'], 'url' => $page->url // was previously 'url' => $page->httpUrl ); This fixes the long-click View button in the page tree. I've also made a change within the ProDrafts module file, once again telling it to use $page->url instead of $page->httpUrl, but I won't go into detail about that here in the general forum. That has fixed the View both option in any case. So this is great as a temporary fix, but I have no idea whether there could be any wider implications... Any thoughts @ryan? I'd hate to break something else. I'm also stumped as to why the httpUrl method is opting to output http instead of https in just these instances.

Thanks for this suggestion. Unfortunately doing this stops our existing http redirect from working (normally if you type in http://scarcomnap2020.antarctica.gov.au you are taken to the https version).

We're using nginx rather than Apache, so we don't actually have an .htaccess file, but I'll get our web manager to double-check the equivalent settings.

Hi, We're having a problem with the long-click 'View' option (in the page tree) that previews a page in a modal window. It's a secure site (https://scarcomnap2020.antarctica.gov.au/), but it seems that when a page is loaded within the modal window it's using http instead of https. This is causing an error due to the mixed content (the Firefox web console says: 'Blocked loading mixed active content “http://scarcomnap2020.antarctica.gov.au/venues/?modal=1”'). The consequence is that nothing loads - just a modal window with a spinning graphic in the middle. The same thing happens if you choose View > Panel or View > Modal Popup from the View menu when editing a page. Additionally, we're having a similar issue within ProDrafts - the option to view the draft or published versions of the page works fine, but when you click the 'Both' option, you end up with a blank split screen. The source code on this blank splitscreen reveals that the http protocol is being used in this case too: <body class='ProcessProDraftsViewBoth'> <iframe id='pwpd-draft' class="pane ui-layout-west" src='http://scarcomnap2020.antarctica.gov.au/venues/?draft=1'></iframe> <iframe id='pwpd-published' class="pane ui-layout-center" src='http://scarcomnap2020.antarctica.gov.au/venues/'></iframe> </body> We're wondering if this choice of the http protocol is something that is hard-coded in somewhere, or if there is a configuration we might have messed up or missed. Any ideas? Everything else appears to be working fine. We're running PW 3.0.98 and ProDrafts 6c. (I noticed the issue because I'm preparing to train our first editor by writing some documentation). Thanks! Margaret

Thanks @dragan for completing the exercise, and for your feedback! All feedback and results are useful, even if they tell us that pages or sections need to be labelled more clearly. Incidentally, the RAAF is the Royal Australian Air Force. That just goes to show how important it is not to assume people are familiar with acronyms - especially when dealing with a global audience!

Hi all, We're going to be moving our main Australian Antarctic Division website to ProcessWire. We're taking the opportunity to completely overhaul the site. We'd be really grateful to anyone who can help us out with the structure of the site by completing this online information architecture exercise. Thanks! Optimal Workshop: Optimal Sort for Australian Antarctic Division Margaret

That sounds like an exciting project @Robin S!