BrendonKoz

Heading out for the weekend, but I found your question interesting and, I'd imagine, potentially solvable - but I didn't find anything quickly. I was experimenting with the following, as a start (where "field-image" is the custom field template assigned to my image field, and "summary" is the field within that template I am searching within): $test = $pages->find('template=field-image,image.summary%=the'); As an alternative option, would you be able to adjust your solution to use (far shorter) tags for the linking/association aspect of your problem?

@Mark_invisu - due to your report, I created an issue report in ProcessWire's Issues github repository for Ryan to see. He's made core changes to related files in an effort to rectify that, but since he's not experiencing the error, was looking to see if the changes he's made alleviates the fatal error you are seeing (with relation to the Exceptions). If you're able to test this and report back, that would be awesome. Thanks!!

Ohh. Sorry; you said that first but I didn't quite catch it. Thank you for reiterating!! 🙏

I'd normally agree with the concern of losing the error code, but from what I could tell, I think the alphanumeric error code as reported by the database itself is retained in the errorMessage property anyway - at least for PDOException objects. I don't like to make assumptions though, which is why I figure Ryan would be the best person to determine how he might want to handle that in the end. 🙂 Nice! Yes, I like that solution (to get further in the error discovery) better than mine. 👍

Interestingly, this seems to be a known issue for developers that extend PHP's base Exception class and potentially use and/or end up extending the PDOException class when dealing with database-related exceptions. This is likely to be the case here, and is a known oddity within PHP, and requires some sort of workaround. @ryan may want to take a look at the core Exception classes to determine how to handle the expected int value being returned as an alphanumeric (string) value. That said, you should be safe to temporarily adjust the core file's code to forcibly typecast the return value to an integer in order to get past the above PHP error - which is only being shown because there's another error elsewhere that might give us more information towards solving your other problem. (FieldtypeMulti.php line 254) throw new WireDatabaseQueryException($e->getMessage(), (int) $e->getCode(), $e); If after adjusting the line above you still get an error with Exception code values not being an integer, you could adjust wire/core/Exceptions.php at line 40 $this->code = (int) $code; That would catch any class extended from WireException and make sure the property has a proper integer value assigned. NOTE: As your support's colleague mentions, modifying the core code is not recommended. For scenarios like this you can always change it temporarily so you can continue your debugging. Change it back once you're done so that you remain on-par with the official branch of the software.

Ah, sorry to mix the two things together. The download issue was backstory on why I was looking in the console and happened to see the error found within the session cookie string. The actual question related to Tracy was how I might be able to expose that error message (from the session cookie) in a log, if at all. I was thinking it was remnant files/folders from prior module versions that were upgraded, but if they're intended to be there, then I have no need or desire to remove them. Thanks for the quick clarification there!

I just noticed today, while trying to inspect headers (sent from our host server to see why a "download" attribute on a file link wasn't renaming a file), that there was a TracyDebugger message embedded within the session string (when logged in as an admin), but after enabling all available error logging in the module (and making sure I was using the latest version), I'm still not seeing any log of the error (I'm hopeful a textual log would provide more detail). I can see it's line 14, but since Tracy has better insight into my file structure, I wasn't sure which file... I don't get this error message on my development server. P.S. - Is it safe to delete tracy-2.x folders in the module folder, and if so, which ones?

Because ProcessWire is so configurable, content can come from many different places, such as: The page tree Language translation files Site template files 3rd party services / APIs / Webpages An external database/application This is entirely dependent upon how that section of the website was built, and since all we can see here is a photo representation, we can only guide you through an overview of your options. This isn't a situation unique to ProcessWire - other CMSs, such as WordPress, would also suffer similar issues, depending on how plugins were used, and how the plugin authors implemented their modules. As for your specific question: "Is it possible that I am not seeing the whole tree?" That depends on your account's access level. It also depends on whether there are sections hidden within the Admin node in the tree. Is there any additional information that you can provide in relation to this page, and the "following text" that you wish to edit?

I (very thankfully) haven't experienced this issue. I've not attempted running PW on Digital Ocean as of yet though. Out of curiosity, are you using droplets and if so are they of the same type on the hosts you've experienced this with? Curious (and concerned) if you've yet discovered a culprit and/or resolution.

Yeah, I've tried both scenarios (one without the file extension, and one with). I've tried multiple browsers, incognito/private windows. I haven't tried a different PC altogether (which I now will). It's such a simple thing, for it to not work is kind of weird. I checked my htaccess files and all uses of header() just in case, too. I'll try to see if I can capture the headers sent by my webhost, if they're any different.

Has anyone had this not work for them? This works fine on my development machine, but not once it's on the production server...

I know that I could disable url segments and create an htaccess rule to handle the scenario myself, and in fact I have come up with a workaround that solves the issue that I was having (though without child page name matching). It wasn't so much that I needed this to work, I was questioning why or if it could work, and if I just misunderstood the documentation. 🙂 Thanks!

That's likely the part that I was getting caught up on, and what is happening. I was a little confused when I could query it successfully from a location that wasn't from the template that enabled the URL segment; I originally thought it wouldn't work at all...and the fact that I was able to actually process the request from the PHP template file related to the parent (car-maker), it made me question the docs' in that it prioritized children that existed in the system (as that would seemingly immediately render a 404, and not even show processing from the parent -- i.e.: if I try accessing car-maker/mazda, the car-maker template is being processed, at least initially). Thanks, @Robin S!

I've run into a bit of a confusing mess. I have a particular section on our site that, for various reasons, I chose to display dynamically by pulling the child page content and displaying it on the parent page. Think of it like the following: Car Maker (page ID: 2185): General Motors Mazda Ferrari Byd So General Motors' information is only accessed by viewing the "Car Maker" page, and passing an appropriate url segment value...in this case, the child's page ID. (The children do not have their own PHP, file-based template.) I wondered though, in this case: Why can't I match either the ID or the name? So I tried it. It works when querying in Tracy's console. $maker = pages()->get(2185); $maker->child('id|name="mazda"')->title; It does not work on the "Car Maker" template itself. ProcessWire returns an instance of NullPage. I'm not entirely sure why Tracy is able to discover the page, while the PHP file template associated to the PW template with URL segments applied cannot... Thoughts? I do have a workaround to bypass this issue, though my preference would be to allow this to work instead of using my workaround behavior. 🤷

I agree with bernhard that testing with a simple, undeveloped installation with only a multi-images field configured would be a good test. If your host uses mod_security and has made any customizations to it, that could potentially be an issue too. (I use Dreamhost and there are multiple issues with its configuration of mod_security and ProcessWire.) Are you running Apache or NGINX? Were there any JavaScript console errors during the interactive process? (I know you mentioned to error during the upload, but unsure what errors your had checked; system logs or JS console or both.)