wp.Man

not really an option since it will mess up the code in other places where the block is used.

what i’m seeing though is this; if i insert a plain text (general) block on a line by itself, then view the source (with TinyMCE Advanced installed), the opening/closing ‘p’ tags are present. however when previewing/updating the page and then checking the source in the browser, they are both gone.

and then, as previously mentioned, if i insert a block on the same line as existing text, the opening ‘p’ is AWOL when previewing. sometimes the source ends up in the browser source as…
block hello world<p></p>
sometimes just the closing tag is there.

so i’m not really sure what is responsible for stripping the tags.
what do you think?

if i add anything before and after the block – even just a dot – then the tags are not stripped. so, apparently, TinyMCE and/or WP simply doesn’t “see” the blocks and so it strips the tags – this explains why only the opening tag is stripped if the content block is the first object on a line with other text. CKEditor produces the same results (i just tried it).

could you try just putting a plain text block on its own line, as a paragraph, then save/preview the page and look at the source in your browser to see if the tags are there?

this appears to be wordpress/tiinymce issue – god i hate that editor!

TinyMCE Advanced plugin helps a bit, but it’s still not retaining the opening <p>

sorry for the bother

i think i might have misled you benz1 – the output on the rendered page is fine, it’s in the source code where the opening ‘p’ tag gets dumped, so the source looks like…
content block hello world</p>
i’ll do some testing and see if i can’t provide more detail…

ah, that explains the cache problem. thanks for the info!
i re-rated earlier and changed status to “working” by the way.

problem was DB Cache Reloaded Fix – it works with Cart66 1.0.8, but not with 1.1

i sent your last comment to the folks at Cart66, which they were thankful to receive. hopefully they’ll contact you and revise their advice about FSCF if, in fact, it is incorrect which, it appears is the case.
thanks again

hi Mike – thanks for the reply

i’ve been having troubles getting any shopping cart to work well and just posted that here from the Cart66 site figuring you may not have known about it. whether my problems were due to session_start() i do not know. i have seen a couple other plugins mention compatibility with yours also, but i can’t recall if they also mentioned session_start() as being an issue.

5 beautiful, golden stars – works like a champ!
as a side note, i can also wrap “Global Content Blocks” blocks inside this and still validates.

actually i was thinking more along the lines of ‘Boat of the Flying House Graceful Degradation’, but it’s your call!
thanks!

WHOA! sorry, i was WRONG!
i was using 1.3.4
i’ll re-rate the plug, but it would be nice if it could degrade gracefully if JS is disabled ??

hi Baden – i was using 1.3.5 when i wrote that. it validates by itself, but not with File Inliner (which also validates by itself). 1.3.5 will also not validate unless a non-numeric id attribute is specified. click the link i provided.

i understand it is in no way your fault that it doesn’t validate when used with File Inliner – that’s another issue.

another thing i should’ve added is that, if the visiting browser has JS disabled, the content remains collapsed

the answer to my own questions is that it may be/probably is a security risk. according to the BulletProof devs, the “# QUERY STRING EXPLOITS” section of their code needs to be last in .htaccess.

AITpro Admin says:
April 2, 2011 at 10:04 pm

The only thing that is important as far as order goes in the root htaccess file is that the Query String Exploits filters are the last code in the htaccess file. The FilesMatch section of code (very last bit of htaccess code) could go anywhere in the htaccess file, but I just chose to stick it at the end of the file.

hi
i’ve cleared the browser cache several times in testing (firefox) and still seeing the admin bar.
i’m really not worried about it at this point – it’s really a trivial thing.
thanks for your help!

also i forgot to add that if i disable mod_rewrite caching, the code remains in htaccess