MarcC

OK. I am going to try to reproduce first. Because it would suck to hand over to you the very simple regex-replace code which now does nothing out of the ordinary, post-the-recent-module-upgrade. 😄 And thanks again for your kind response. 👍

OK, thanks! I see it now, on the front end. I upgraded the module since my investigation, so maybe I was encountering something going on with a previous version. I was testing on the back end, this checkbox wasn't there, and I was getting template-processed output. (Edit: I can check again just in case...)

Ah, I was guessing that the feature might have been enabled by default when I installed the module, or otherwise bumped 😅. But if not default...I kinda doubt I bumped it... I don't see it anywhere now that I'm looking. v4.26.36, somewhere in the Console panel? I do see references to the term "Template resources" in settings and I was able to add the separate $ panel to the front end view. That's a really helpful panel btw.

That's an awesome feature, I'll look into it further. Thank you.

Hi, Related to this thread I started recently, I wanted to follow up and check on the expected behavior for the Tracy Debugger Console. In my template files, there was a preg_replace operation on the $page->body property. The TD Console showed the result of this template operation after executing "echo $page->body". Is this the normal / expected behavior, as opposed to simply showing the field HTML content from the DB? The DB itself showed the unchanged HTML for the body field. Just wanted to check since it will help me understand how to troubleshoot better next time. Thanks!

I would also like to know! Tracy stopped showing the unwanted behavior after the template code was updated. So, I wonder if Tracy is not completely isolated in the case of the console, and in fact attempts to access the body property as it comes out of the template processing. This seems like it could be meant as a convenience. Just an idea though! I guess it would have been nice to know it was doing that. 😄

On further investigation: One of the site's main templates was using a preg_replace function to automatically convert plain email address text into links. The situation has been remedied by removing this until I can look into it further and decide whether to modify the code. No more duplicate prefixes! Hooray. I actually stumbled upon the issue while checking where I was using the separate HTML Purifier class in the template code. So a bit of luck helped in the investigation... Thanks all for your ideas & input!

Hi All, I'm looking for some tips to troubleshoot this issue with mailto links: Issue: All email links in the body field are rendered on the website as "mailto:mailto:" with a duplicate prefix. This duplication is not shown inside the editor's "Source" window. Other fields, like the sidebar field, do not have the issue. I removed the body field's Hanna Code formatter and other text formatters, turned off ProCache, and this did not change anything. I rendered the body field from Tracy Debugger's console and did confirm that the duplication is happening there. I checked the DB itself, and there is no duplication in the HTML inside the DB. I can't see any HTML Textarea plugins that would affect email links. Any tips on troubleshooting this further? The site is currently running 3.0.200. Thanks!

Just as an update to this topic, I tried out the jQuery load change and unfortunately it didn't work. However, some of the other ideas I had led to results in working with back-end code, and the test page is working OK now. I still need to run some more tests but thought I'd update the thread while I remember it.

Ah, so it seems like it may be almost like a race condition with jQuery loading. That's interesting. I'll add that suggestion to my next batch of things to try here, thanks for your input. ? I've given some thought to this kind of thing, and other changes I'd like to make, and I have to say we've come a long way with recent changes already, but I know what you mean there.

Hi all, I have some Hanna Code output for PHP Social Stream which is giving different results when the same code is output in two different fields. Here are the two examples for comparison (Removed as things are working now) You can see that the page at the second link appears without proper CSS styles, which seems related to the jQuery issue. (Please note that the social feed output itself is not yet fully configured, so the feed in the footer will let you scroll forever, etc.) The Hanna Code is the same for both, i.e. there is only one test in the Hanna Code PHP right now, to check if the full class for the vendor code has already been include-ed. Tests are run without caching, and both fields have the same CKEditor filtering, other options, and the same general output logic. Tracy Debugger is active and there are no PHP errors in the logs. But only one of these fields is giving the correct result. I did test in other fields (Body for example), and everything works fine there as well. I thought I'd ask the community for input and would be grateful for any suggestions, thanks for your time.

Oh funny, thanks. That's a pretty clever way to manage the configuration. So in case anyone else is wondering, it seems you can either add a namespace to your template files or just set $config->templateCompile to false in config.php. I do wonder what the implications are for either choice, or how future-proof it is to set this to false instead of adding the namespace.

Hi all, Am I correct in remembering that adding a namespace statement to the top of every template file will prevent the file compilation process from needing to run during a 2.x to 3.x upgrade? I had attempted this same upgrade previously on a site with many pages, but the upgrade seemed to fail. However, afterwards I realized it may have been the delay in compiling files rather than a failure of the upgrade. So I'd like to avoid the compilation process if possible. Thank you for any tips! --Marc

Hi everyone, I'm having an issue where a selector doesn't seem to be working properly with page->closest. Here is the code: // Look for the closest page with any social URLs filled in $page_with_socials = $page->closest("extra_url_1|url_5|extra_url_2|extra_url_3|extra_url_4!=''"); if ( $page_with_socials->id ) { // We found a page with social fields containing some URL content $social_config = $page_with_socials; } else { // Fallback: Use home page social URLs // This is used every time extra_url_1 is empty, even if the other URL fields are filled out $social_config = $homepage; } Instead of checking the various fields, the selector is treated like it only says this: $page_with_socials = $page->closest("extra_url_1!=''"); In other words, it's like the other fields aren't even checked for content. If url_5 is filled in, or not, it doesn't matter. The else-fallback is always used as long as the other field, extra_url_1, is empty. So I'm wondering--do I need to change the way I'm using the pipes in my selector or something? Thanks for any tips.

diogo, these are great ideas. Thank you. I really like the pipe-separated version and it would seem to fit great, so I'll give that a go. Thanks again.