muzzer

@Robin S Yes that is correct. But it gets more bizarre. This is the code which loops through the page images and is causing the problem (BTW it is all template data being lost, not just slashUrls): foreach($room->smRoomImages as $image) { $options = array( 'quality' => 80, 'upscaling' => false ); $thumb1 = $image->size( 250,180, $options ); $html .= "<img src='$thumb1->url' width='46%' height='' />"; } I excluded the three lines in the loop and the problem resolved so I assumed it was the size() method causing the issue - but it is actually the next line in the loop - if I remove just the $thumb1->url from next line (leaving the img src attr empty as follows:) the issue vanishes. foreach($room->smRoomImages as $image) { $options = array( 'quality' => 80, 'upscaling' => false ); $thumb1 = $image->size( 250,180, $options ); $html .= "<img src='' width='46%' height='' />"; } I realise this sounds just ridiculous but it is totally consistent - I've run this dozens of times with the described result with and without the "$thumb1->url". I can't replicate this on v2.7. I'm not sure what debugger you've screenshotted there - I'm just reloading the template page in the admin and seeing the changes reflected there. I'm not familiar with the workings of FileCompiler as yet as this is the first time using v3, but am wondering if something is going astray there, is that possible?

Done, https://github.com/processwire/processwire-issues/issues/1298

OK I'm posting the simple workaround to this for anyone who may run into it in the future. Basically it is a missing page image which is causing this odd behaviour, feel free to try to replicate; I've got an image field on the page in question, image has been uploaded to the page via the API. Now somehow the image file has been deleted but the image info is still there in the PW page. When I access the image using the PW API it returns filesize 0 (no image file), debug data as follows: When I attempt the $image->size() function on image it causes the template to lose it's data and return to PW default template settings. This is not a one off, I can replicate repeatedly. The workaround (which I should not have to do really?) is to check the filesize before attempting a resize: Perhaps it could be considered good practice to check the filesize prior to operations on the image but not doing so should not result in the template blanking it's settings. I'm guessing this situation of a missing image is either very rare or I've run into something odd on my particular instance as I can't find any mention of others encountering this issue. The exact same code and database under v2.7 runs fine for this page,

OK, I see I've actually run into this issue a long time ago and forgotten about it, even posted about it but no resolution. It appears all the template settings are returned to default, not just trailing slashes (that is just what make it show in this case as it creates a redirect loop). In this case it happened upon loading the PW backend (admin) but it's also now reverting the template to default settings when some other pages using the template are loaded. At no point do I alter the template via the API and I'm at a loss as to why this would happen. Is there any point in the core when a template settings would be defaulted which I could be tripping somehow? This is phpMyadmin data for the PW template record before the page is loaded... and after:

Just upgrading site from 2.7 to 3.0.165. The site has templates which have the setting "Should page URLs end with a slash" set to No. On replacing the /wire folder, index.php and .htaccess to PW3 files all was working fine with the site UNTIL I loaded up the PW backend. Something happened here - I suspect on loading the backend several checks are performed and settings altered where necessary for freshly upgraded systems. Anyways, this setting mentioned above has now been set to Yes for all templates, causing rewriting issues. Easily fixed by setting back to "No" but why is this happening on upgrade, is this an upgrade bug? Anyone else seen this?

Thanks @horst, so it sounds like upgrading PW to v3 would be simpler than fighting PHP7.4 in v2.7. I had a feeling this would be the answer, thanks for your help :-)

Hi, I have existing sites running Processwire v2.7 on php7.1. I'm looking at upgrading the server to latest Ubuntu (20.04) which would include php7.4. Are there any known issues running Processwire 2.7 sites on php7.4? I'm NOT wanting to upgrade these sites to v3. TIA :-)

OK, this is getting weirder. I've narrowed it down to WHAT is causing this bad behaviour but not WHY it's happening. The ajax call (which results in the PW template fields resetting) is returning html which includes among a lot of other stuff the $image->url of an image which has been removed from the file system but is still on the PW page. $html .= '<img src="' . $thumb1->url . '" width="46%" height="" />'; $image1->url is returning correct path /site/assets/files/89034/images1.250x180.jpg but the image file does not exist. If I remove this line from the returned ajax ill is fine, but as soon as I add it back in the template fields all reset. I've discovered it's not solely the slashUrls field that is reverting but ALL the fields on the template are changing back to what I assume is default PW template settings. I'm totally puzzled as to why accessing a non-existent image in this way would cause this behaviour, any help appreciated ?

I have just upgraded a site from 2.7 to latest v3. I have run into a weird issue where a page template setting for slashUrls changes from No to Yes immediately after an ajax call, causing the second ajax call on the page to use the wrong setting. There is no reference to the $template->slashUrls() in any of my code. This happens every time I load the page, it's 100% consistent. I have this running on a second machine under v2.7 and no such weirdness. I'm lost as to why this is happening, what would cause a PW setting change for slashUrls? Anyone have any ideas?

Existing PW site version 2.7.2 core running on php7.1. Site is perhaps 7 yrs old and never misses a beat. Can't speak highly enough about this solid version, but.... As new php versions are released (v8 in the next year I think?) and each seems to get quicker I'm looking at upgrading to php7.3 or 7.4 and upgrading the site to PW v3.x. I've been away from the forums since v3 was released so don't know much about it. I guess it's stable as it's been around for ages now, but what I'm wondering is: what are the real advantages of upgrading to v3 for a site which is actively used but with only periodic development. And what are the disadvantages if any? Is there any speed impact (good or bad) in either general site speed under 3.x or admin-use speed/ease of use? any issues with either PW version with newer php versions (>7.1) I should know about? is there any good write-ups/vids about new features etc of v3 compared to v2.7? Thank you

Hey, I have a multi domain setup on Processwire 2.7. It's NOT using the multisite module or anything like that. So how it goes is I have a VPS with the main processwire system and website setup on it. Then I have virtual hosts with thier "secondary domains" which symlink to the PW /site and /wire folders but have their own .htaccess. In the .htaccess of each secondary domain I redirect to a specific folder in processwire directly off the / (home) folder So domain1 (lets call ir domain1.com) is the main domain with processwire setup on it. Domain2 (which we'll call domain2.com) has the symlinked /site and /wire folders (targeting domain1 /site and /wire files/folders). Domain2 also has it's own (not symlinked) .htaccess pointing any domain2 requests to /domain2 page and children on the PW system. Hope that makes sense. I've been using this for years and it works brilliantly and is simple to add domains to, all which use the same PW system and database. So the PW page tree looks something like /home (ie domain1.com) /domain2 (ie domain2.com) /childpage1 (ie domain2.com/childpage1) /childpage2 (ie domain2.com/childpage2) /childpage1 (ie domain1.com/childpage) /admin (ie domain1.com/admin) ...etc Now however I wish to access /admin from domain2 - domain2.com/admin/ But it seems I can't do this because any domain2 requests correspond to the page /domain2 and it's child pages and the admin page is above this in the pages tree, so invisible to domain2 Does anyone know if there Is there any way I can access /admin from domain2.com? Ideas?

Hey @abdus, Thank you! I was not aware you could do anything like this! Love it. BTW the ugly styling in my screenshot was just the default from the snipping app, I never meant you to copy it so accurately! Bonus points for that. @tpr thanks for the AdminOnSteriods suggestion, it looks interesting, will check it out. Cool name too.

Similar (related) question. I have templates with up to 50 fields. I don't work in the Admin much but do use it to lookup values on pages and with my poor memory, and even with pretty good naming convention for my fields (some are similar) I often lose track of field names. Is there any way (short of manually appending the field name to the label) to show both label and field name above the field input. Essentially, is there somewhere an option to automatically append the field name to the field label. Please see screenshot for basic idea: Thx

I have what is building to be what I would consider a large site and am starting to notice a few pages running slower than I would like. I've been looking at various options for speeding them up and it seems the database interactions are probably the part which drag the most. So now I'm trying to understand how PW handles queries and pages objects so I can program more efficiently, so my question is: $bookings = $pages->get('/bookings/')->find('room=roomOne'); foreach($bookings as $booking) $roomData = $booking->find('date=' . $today); In the above snippet is the third line performing the find() on the $bookings pages object in memory or is it querying the database again and using the $bookings ojects to refine the query? I'm trying to reduce the database queries (especially repeat queries) so understanding this would be helpful.

I just had a duh! moment and thought I should share as it may be useful to others, especially PW beginners. I know a lot of you will go "yeah well duh...." and yeah, well I feel like a bit of an idiot but anyways.... I had a page outputting a table detailing data from about 200 records (PW pages). For each record it searched for child pages of a certain template, probably averaging 3 child pages per record and added some data from those pages to each row of the table. Simple stuff. The page was averaging about 12 seconds to load. Anyway, today I got frustrated enough to try to work out why it was so slow. Turns out I realised that the child pages I was searching for were all direct children, so I changed my search method from $pages->get(....)->find(.....) to $pages->get(.....)->children(.....) and blow me down the page load has gone from 12 seconds to a tad over 1 second. Turns out each child page had many child pages of their own (thousand of pages in total) and all these were being searched with the find() method. Stupid mistake, but I think right from the beginning of my learning of PW the find() method was ingrained. So hopefully this helps some newbies and others like me. Check out http://cheatsheet.processwire.com/page/built-in-methods-reference/page-find-selector/ and http://cheatsheet.processwire.com/page/built-in-methods-reference/page-children-selector/ for more info on these methods and others.