jakramer
Forum Replies Created
-
Thanks so much! We’re excited that we will be able to use your plugin going forward!
Yes, the version you linked above is working for us. Thanks so much for the quick response!
Thanks for looking into this. We would love to walk away from the classic block, but unfortunately not an option for this use case. We’ve found a different approach that will work with classic though, so we’ll go that way.
Hi,
Thanks for the response. This is exactly the issue. I can do what you suggest above, and have, but then if I ever edit the page again, the content gets re-encoded, which basically means the page can never be edited after it has been created.
What I need is for the plugin to correctly identify whether the content needs to be encoded/decoded in the context of the classic block.I did find that if I comment out the encoding step in this function:
// The callback function for SyntaxHighlighter::encode_shortcode_contents() function encode_shortcode_contents_callback( $atts, $code = '', $tag = false ) { $this->encoded = true; // Commenting out the following line fixes bug with classic block (but probably breaks things for other cases) //$code = str_replace( array_keys( $this->specialchars ), array_values( $this->specialchars ), htmlspecialchars( $code ) ); return '[' . $tag . $this->atts2string( $atts ) . "]{$code}[/$tag]"; }I am then able to edit the content within the classic block without the characters being re-encoded every time, but the display in the visual editor doesn’t show the characters correctly.
Given that additional context, can you give me any pointers on where to look for the conditions under which that encode function is called, so that I can carve out an exception to make classic editor work correctly (rather than just commenting it out completely)?
Thanks!
Sounds good. Thank you.
Forum: Plugins
In reply to: [Password Protect Wordpress] PHP7 IssueThis sounds pretty shady, but I searched all files for Error and found /lava/_classes/h2o/errors.php tries to define ParseError. I renamed the class ppwParseError, assuming I’d search for instances of ParseError and replace them with the new class name, but I couldn’t find anywhere the class was actually used.
This solved my problem in test. I can’t think of any issues this might introduce (since the class doesn’t seem to be used), but I’ll test some more before moving it to production, just the same.
Forum: Plugins
In reply to: [Custom Contact Forms] cross origin errors with MU and mapped domainsThanks. I’ll go test this out!
Forum: Plugins
In reply to: [Custom Contact Forms] cross origin errors with MU and mapped domainsHere is one example. The same problem occurs for all forms on sites with mapped domains.
Thanks!