We are open to any suggestions on how to resolve this issue.
Currently the %FULLTEXT% takes everything that you have in the body of your actual (result) post. Everything including the like buttons, ads, as well as shortcodes and other plugin gererated content.
The last part is the most important. There are a lot of people who use shortcodes and there is a bunch of different plugins that process the post. Some people have something like [{*acricle-id-117*}] in the post body, but they want our plugin to re-post the actual article, not this code.
If we switch the %FULLTEXT% tag to take only the text that you typed, all people who use shortcodes and plugins won’t be able to use the plugin.
Would it be possible for one of your developers to take a look at the now defunct Tumblrize plugin to see how that was handled? It worked beautifully. If you don’t have access to that source code, I would be happy to copy it for you and send it along.
Another suggestion that would make SNAP close to perfect is to allow updates to posts to also update the Tumblr post. As it is written now, the only option is to repost, which duplicates the post in Tumblr. If we make a change to the original WP, it would be nice to have it update the Tumblr version that was passed along, or at least give an option to update it at the bottom of the WP post screen.
Thanks for this quick reply! I know there are a lot of former Tumblrize users who are going to be switching to SNAP now, and they’ll probably all be asking the same thing. 🙂
The problem with Tumblrize of course is that it no longer works. And IMHO, SNAP is better with Tumblr except for no option for default tags (which I resolve by manual code edit) and the edit aspect, which isn’t that important to me frankly, but isn’t unreasonable.
But just wanted to point out that he already explained why %FULLTEXT% is doing what it is, which Tumblrize didn’t do because it didn’t do it. It’s because before posting, SNAP runs the post through the_content filter, so plug-ins that automatically add/change stuff before posting can manipulate the post. I have this issue myself with an auto-more plug-in, so I again have to edit the SNAP code to not call the_content.
What would be a good compromise is if SNAP introduced something like %RAWTEXT% which would show the fulltext without running it through the_content filter. Should be very easy for them to do.
I haven’t tried this out to be honest, but it should work. If you look around line 431 in NextScripts_SNAP.php and look for the line that begins:
if (preg_match('%SITENAME%', $msg))
and add the following above it:
if (preg_match('%RAWTEXT%', $msg)) { $postContent = $post->post_content; $msg = str_ireplace("%RAWTEXT%", $postContent, $msg);}
and save it, then go into your preferences for SNAP and change references from %FULLTEXT% to %RAWTEXT%, it should go ahead and post messages without processing them, so you can see the difference.
Of course this will break if you later update the plug-in, so you’d have to re-edit with the new changes or hopefully they’ve added it in by then.
@stitchkingdom: If I understood what was said the first time, I might understand when you said it again here, but I didn’t and I don’t. Sorry to be dense, but getting into the source stuff just isn’t where my talents lie. When I can find things that work, and put ’em to work and let them do what they’re supposed to do, then I can get to work. This is frustrating me to pieces.
If anyone has a suggestion about how to edit the code myself, please lay it in detail out here and I will ask my husband to try to make sense of it in the code. WP is not his specialty either, but he is a programmer and may be able to follow instructions to get the workaround done.
Otherwise, I may have to post images with just a title, which would eliminate people searching on content.
Sigh.
@stitchkingdom: Oh, we crossed paths in the night, I just saw your suggestion. I will show it to hubby and see if that means anything to him. Thank you, thank you, thank you!
Janet
I’m not sure why, but after I added the line of code, I got a weird error when attempting to post (refresh made the post go through), so do try it, but be prepared to remove it if the error pops up. It’s such a simple line, not sure why it causes problems, but when I took a brief look at it, the resulting error was just complicated.
for the record, this is the exact change I made, replacing the FULLTEXT line itself:
if (preg_match('%FULLTEXT%', $msg)) { $postContent = $post->post_content; $msg = str_ireplace("%FULLTEXT%", $postContent, $msg);}
this works without error and avoids putting the post through the_content to allow other plugins to affect it.
@stitchkingdom: Thank you for that additional information. I will pass that along to my husband. I’ve been stuck on another problem all day today and haven’t had a spare minute to devote to this one, which I really, really would like to solve. I’ll let you know what we find. 🙂
Janet’s Husband: IT WORKED! I plugged that line in and it worked. I commented out the existing line with //##.
Janet: Thank you so much for giving that information. MUCH nicer to let it post and not have to bother with it afterwards! You’re brilliant! 🙂
glad to hear it. hopefully the fact that at least 2 of us would at least like the option to avoid putting the messages through the filters will be reflected in a future update.
I agree. I wish we could find out if this fix solves the problem of the ads showing up, as well. Do you know whether it does, or not? I don’t happen to have any ads on my posts, so I can’t test that aspect.
it probably will. any plug-in that automatically adds things to the body of the post (even before or after the actual content) will be affected by it.
Just to let you know. Version 2.2 will have a support for the %RAWTEXT%. Thanks stitchkingdom.
Outstanding! Thank you, NextScripts! Thank you, Stitchkingdom!
[Sorry…moved this post to a more appropriate thread that I just found…]
