Closed daveseah closed 8 years ago
I'm uncertain whether the magical 99999999 page id is a reliable way to detect whether a page is being generated by StCR. It seems very hacky.
Actually you shouldn't use that, because you will limit your permalink structure to id.
Perhaps there is a reliable global flag or instance variable I can check if StCR is actively generating a virtual page?
There is an option that store the Virtual Management Page status, so you might add this to your code:
function mdwp_MarkdownPost($text) {
/* DSHACK */
global $post, $wp_subscribe_reloaded;
$virtual_page_flag = isset( $wp_subscribe_reloaded ) ? get_option( 'subscribe_reloaded_manager_page_enabled' ) : false;
// Do what you need with the $virtual_page_flag
$slug = get_post( $post )->post_name;
if ($slug=='http://davidseah.com/?page_id=9999999') return $text;
/* END DSHACK */
// ... rest of function continues...
Regards.!!
Thanks for the quick reply!
Actually you shouldn't use that, because you will limit your permalink structure to id.
Interestingly, my permalink structure is set to "month and name" (/%year%/%monthnum%/%postname%/
) and the post_name
property still seems to report the page_id=9999999
instead of the management URL I had specified, so it appears to work on my installation mysteriously! Is the virtual page generator code supposed to populate post_name
property, or am I trying to access it too early?
In your suggested code, it looks like $virtual_page_flag
is set if (1) the plugin instance is available and (2) the virtual management page option on the Management Page is enabled. I don't think that tells me if the blog is actively rendering the Management Page, which is the condition for which I disable Markdown processing. I had originally thought that I could just check for the slug name as it's specified on the Management Page Options admin panel, as I assumed it would be uniquely defined.
Oh, looking at function subscribe_reloaded_manage()
on line 462 of wp_subscribe_reloaded.php
, I see that post_name
is being set to get_bloginfo( 'url' ) . '/?page_id=9999999'
. Perhaps this should be using the option for the management url instead.
Good to see that your are looking at the code, if its helpful on the line https://github.com/stcr/subscribe-to-comments-reloaded/blob/master/subscribe-to-comments-reloaded/wp_subscribe_reloaded.php#L47 you could see the filter the_post
modify to add that new post created.
So far I have no plans to modify that value so I guess you can rely on you logic if ($slug=='http://davidseah.com/?page_id=9999999')
. I am still trying to get the full picture of your need :smile:
Ok, I'll keep it the same for now...thanks! I just thought that the value of post_name
that you set matched what usually is in that field for the $post
object. I think we can mark this issue resolved...thanks!
The full picture is that I need to disable Markdown processing, as provided by a particular plugin, for the StCR management page. Otherwise the management page's <form>
UI markup is wrapped inside <pre><code>
and does not function. Every other post/page/custom-posttype, however, needs to be Markdown-filtered. The need I have is entirely due to my use of PHP Markdown Extra and how it inserts itself into the complicated WP ftext ilter chain, but I'm stuck with it until I can make major server changes.
Cool ! Thank you for letting me know. I hope that you achieve your objective one of this days. On Feb 23, 2016 6:05 PM, "Dave Seah" notifications@github.com wrote:
Ok, I'll keep it the same for now...thanks! I just thought that the value of post_name that you set matched what usually is in that field for the $post object. I think we can mark this issue resolved...thanks!
The full picture is that I need to disable Markdown processing, as provided by a particular plugin, for the StCR management page. Otherwise the management page's
This is specific to my website's use of the "classic" Wordpress plugin PHP Markdown Extra and its interaction with StCR's management page generation. I have worked around the problem on my blog but am reporting it here in case other people have similar problems, or if there is a better workaround available.
THE ISSUE
Users who tried to engage the subscription management page were presented with a code listing containing the form markup instead of it being rendered as a form. This prevented them from unsubscribing to comments.
I tracked the issue down to the way that StCR injects its form html and how Markdown interprets it. In Markdown, text that is indented by a 4 space or a tab is interpreted as a preformated code block. Line 52 of
templates/user.php
in commit 08d56de uses such an indent, and therefore gets rendered wrapped with<pre><code>
blocks. Markdown allows for inline HTML with the caveat that it is wrapped by non-indented tags, and this is the case in most (but not all) of the HTML snippets that StCR emits.MY WORKAROUND
I originally added some wrapper
<div>
to theuser.php
to see if this was the case, but updating the files of a well-maintained plugin meant I'd have to do it every single time I updated. I don't think StCR is doing anything wrong either in this case; it's my use of using a PROCESS EVERYTHING Markdown plugin (it is necessary in my case) that is the culprit.Since PHP Markdown Extra is no longer maintained anyway, I modified my own copy's
mdwp_MarkdownPost()
function, which is called to filter content text, to check whether the current page seemed to be generated by StCR and return unprocessed text:I'm uncertain whether the magical 99999999 page id is a reliable way to detect whether a page is being generated by StCR. It seems very hacky. Perhaps there is a reliable global flag or instance variable I can check if StCR is actively generating a virtual page?