BrendonKoz

If, by chance, oddities discovered during the creation of the template - (CSS et al), testing, and reports of usage - could be included in a document by the theme authors somewhere for future work (next iteration of a template?), that would be amazing. Absolutely outside the scope, but likely appreciated by others, for sure! 🙂 Some of the issues will be module-specific, but issues with core, or (more) "commonly" used modules (ex: InputfieldIcon) might be worthwhile to be noted there... Just a thought, after reading all of the feedback thus far. The unfortunate thing here is that once you offer a light/dark mode, prior colors that worked in whatever theme was used previously (in the PW backend, this would essentially be a light theme, by default) just might not work -- and they could have been set as a primary color from a prior theme customization, or even as bernhard said, the company's primary color. For my company's primary color, it is a sort of putrid green (#649a44). Even in light mode it doesn't work well, but is terribly difficult to read in dark mode (when I was developing a light/dark mode for the frontend). I had to use color mode saturation/lightness adjustments to make it appear as though I'm using the same color, while in effect they're fairly significantly different colors (but visually, to the eye, looks right-on-target). This isn't something that can be done by simply assigning a single color. Even with CSS color function adjustments (lightness, saturation, lab colors, etc.) it's a bit of a "magic number" game. BTW - related 👉 Safari: How to have the browser pick a contrasting color automatically via CSS (🤞 for other browsers to implement this too) That said, the custom CSS file override option still works just fine. Since this theme does offer customizations though, the determination would mostly be, "Where does it make sense to offer a customization right in the theme, and where should the dev take the extra effort themselves?" Primary color, I opine, would likely be a configuration option that would often need to be customized further for light/dark compatibility, and therefore makes sense to offer the option in the theme. Similarly for the logo image used in the backend. Just because we may think a certain logo image is fine as-is (ex: bernhard's logo), the client might not, but may also demand it. It's definitely something we can adjust, either with admin JS and/or CSS, but if it may be a common request or need due to the light/dark mode offering, it also seems to make sense to offer the option here (imho). Love seeing the work, excitement, and feedback thus far. I haven't had a chance to give this a whirl yet, but appreciate the massive amount of work that's gone into it, and the early testers that are enthusiastically offering their feedback!! This community is so awesome. P.S. - Is there any preferred way that we might offer any sort of assistance with the theme? Too many "cooks in the kitchen" can cause confusion, but I also know the effort was voluntary and it's easy to identify potential issues, harder to fix, and/or find the time to fix.

Yeah, I was unable to get it to work while HTMLPurifier was enabled. Having it officially supported in PW would make things easier, for sure. 👍

Do you know where your host's support was originally able to get the server and/or PHP error logs that originally showed the issue with the core ProcessWire file's exception? You mention no errors are showing up in the logs, but the logs from the ProcessWire admin/backend may not be able to store the error message if it's happening at a lower level in the stack. The browser dev tools can be helpful to some degree, but it's not the only place to look, nor is the PW admin. If you're not seeing any useful error logs in those two places, have you looked (or been able to look?) at the server logs, whether those are NGINX/Apache, or PHP (runtime) logs? It seems you may be getting different responses depending on the host you're on (you mentioned both a 501 and 504 timeout errors), so having any sort of definitive logs to look at, if they exist somewhere, would be awesome.

Yup. From https://processwire.com/store/pro-dev-tools/api-explorer/ Could check and see what methods are hookable to potentially generate markdown instead of HTML. Current licensing seems to indicate that using it is solely for the purpose of the license holder though, so generating Markdown from it would be usable by the developer, but not shareable. Until or unless Ryan can consider if he would also not mind generating Markdown with the official docs, it may be a more practical option for those looking to do it now.

Interestingly, since I think something in my example should work, I noticed that in my Setup > Templates admin page, my field-image template is reporting that it contains zero pages. I'm not sure if that should be the case since I do use images that have custom fields assigned. Maybe that's why I'm not getting any matches? I'm unsure. I would think Robin's module does something similar to the built-in core functionality, but if that works for you, I'm glad to hear it!

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.)

I'm testing this module to see what it can do; I haven't before used PageTable in any way prior. I used the image in the module's directory entry as an example of how to configure the naming of things, so I created the default field of "ptn" from the module config, then created a PHP template file (in the root template directory - I wasn't originally clear on where it needed to go) with a filename of "ce-header.php" (with fields "title" and "number_01" which would be used to denote the heading level such as h1, h2, etc.); I created a template within PW with the same name. Upon loading the field to add the content element (page) template, it said it couldn't find the template, but told me where the file should be placed. ✅ So that structure is now as shown below: When trying to use the field template, I was uncertain of how to go about referring to the properties (fields) held within the PW template in the PHP field PTN template file. I ultimately discovered that I could access it via the following ... but is that the correct way? <h<?=$page->ptn->['ce-header'}->number_01 ?>><?= $page->ptn->{'ce-header']->title ?></h1> PHP property names with hyphens have to be escaped with the syntax as shown above ( {'property-name'} ) but that's due to using the image as shown on the module description page as an example; this could easily be changed on my end. But is that truly the way I should be referring to the property in the PHP field template file?

Hey @TomPich, I don't know if you gave it a try, but I just did. Although I was able to get the button to work after manually modifying InputfieldTinyMCEConfig.php, I wasn't able to get it to actually work using the default interface of a Textarea field's Input config for TinyMCE fields. As the Accordion plugin is not an external plugin, there doesn't seem to be a simple way to use the UI of the field's Input config settings to enable the accordion. I played around a bit, and did get it to work, but after saving the injected "accordion" (details/summary elements), the HTML of those elements got stripped via HTMLPurifier, so there's another problem. Turning off HTMLPurifier allowed it to work, though I'm not sure if you'd want to do that. There's another recent topic where someone is attempting to adjust HTMLPurifier a bit. Currently, it seems that to get the Accordion plugin to work until/unless the core TinyMCE module is updated to include it, you'd currently have to migrate your customized settings via the field's UI into a custom JSON that overrides what you have set via the field UI. Example "Custom Settings JSON" (PW default + accordion): { "plugins": ["anchor", "code", "link", "lists", "pwimage", "pwlink", "table", "accordion"], "toolbar": ["styles bold italic pwlink pwimage blockquote hr bullist numlist table anchor code accordion"] } After playing around with the accordion interface, I don't find it quite as intuitive as some other elements, but it does work.

I was curious so just tested the default configuration of using the TinyMCE field with the media plugin enabled, and I was able to get it to save a YouTube and/or Vimeo video within the editor (and view it successfully on the frontend) without adjusting HTMLPurifier. However, if I re-save the exact same page, after saving it once, the content then disappears. Something must be changing just enough that's causing it to get wiped, though I haven't dug down to see what. I think most have taken advantage of either hannacodes, Ryan's Textformatter Video Embed, or one of the two Oembed modules for this. It's not quite as convenient as simply using something that exists natively within the TinyMCE editor, but it may be a viable workaround if a better solution can't immediately be found. 😞

Have you already added the plugin into the InputfieldTinyMCE's External Plugin Files section, and then configured both the module and the field to use it? I'm just wondering if the module, and then field config would take care of your manual database edit.

I think there may be an error in the try/catch block when the FileIndexer attempts to index a file, and fails. That line points to $file_indexer['method'] as shown below: <?php // Attempt to read file data using file indexer try { $text = $file_indexer->getText($file); } catch (\Exception $e) { $this->log->error(sprintf( 'SearchEngineFileIndexer::%s error for file at %s: %s', $file_indexer['method'], $file_info['filename'], $e->getMessage() )); return null; } In a cursory search, I was unable to find a method property or name that reported the current indexing method type. I don't want to suggest a fix without knowing what the intended error log value was. In this instance, the file also failed to properly upload/save. I don't know if it's because of a server configuration or if the search indexing ended up being a blocking behavior. I suspect it's the fault of the server, but identifying the error is difficult since this was the only error reported.