Support Forum
Actually, we would appreciate it if you could try it out. Please note, while Peter has contributed good code in the past, we have not had a chance to test it out ourselves. There is no reason to believe there will be any issue but would recommend a db backup before starting.
Any feedback would be great. We do intend to test and include Peters code in our upgrade script this week for our 5.1.4 release next week.
Visit Cruise Talk Central and Mr Papa's World
Ok gotcha. btw may I know what class or php file handles the rewrite of content that has a links? I've check one post to our database and it's seems the link is correct.
database post content
<a href="http://longlinkhere.com" target="_blank">http://longlinkhere.....xxxxx.zip</a>
but when viewing the post the link becomes
<p>
<a href="http://longlinkhere.com" target="_blank"></a>
<a href="http://longlinkhere.com" rel="nofollow" target="_blank">http://longlinkhere</a>…..xxxxx.zip
</p>
Thanks!
The problem is actually in the WP core routine make_clickable(). We have searched and tried numerous third party algorithms that purposrt to do the same thing as make_clickable() and they all seem to have the same problem whenever there is a full point in the link.
we are hoping, of course, that the WP guys will fix the bug so it just goes away...
By the way - if you do try Peters code note the SQL error he points out later in the thread.
YELLOW
SWORDFISH
|
Hey Peter, thanks for the code!! The regex works nicely... have added it to the upgrade script for 5.1.4 (hopefully released next weekend)...
I had to tweak a few other things to use our api and get it working... for the reference, here is our function:
function sp_fix_shortened_links() { $postCount = spdb_count(SFPOSTS); $limit = 1000; for ($offset = 0; $offset < $postCount; $offset+= $limit) { $posts = spdb_select('set', "SELECT post_id, post_content FROM ".SFPOSTS." ORDER BY post_id ASC LIMIT $offset, $limit"); foreach ($posts as $post) { /* Matches would be: 0 = The entire string 1 = The link in the <a> tag 2 = The rest of the parameters in the <a> tag (nofollow, target, etc.) 3 = The part after the 5 periods So then we want to replace 0 with 1 for each result We are assuming that the links have 5 consecutive periods */ $postContent = stripslashes($post->post_content); preg_match_all("/<a href=\"(.*?)\"(.*?)\.\.\.\.\.(.*?)<\/a>/is", $postContent, $linkMatches); if (!empty($linkMatches[0])) { foreach ($linkMatches[0] as $index => $stringMatch) { $postContent = str_replace($stringMatch, $linkMatches[1][$index], $postContent); } $postContent = esc_sql($postContent); spdb_query("UPDATE ".SFPOSTS." SET post_content = '$postContent' WHERE post_id = $post->post_id"); } } } }
might be worth a quick check to see I didnt screw anything up!
1000 seemed to work faster than 100 on a larger db... had to move the update query outside the foreach for when multiple shortened links in the content...
again, THANKS!
Visit Cruise Talk Central and Mr Papa's World
Great catch for both the different offset and having multiple shortened links.
How necessary is the stripslashes and addslashes? Is that only necessary on certain setups or are they required because of how spdb_query works? I prefer to use $wpdb->prepare and similar functions for sanitizing queries (if necessary), as typically stripslashes/addslashes introduce problems on setups that don't need them.
well wpdb prepare does the same thing... its just hidden from you... could have done an esc_sql() vs addslashes()...
when you pull it from db, you need to remove any escapes (slashes)... and before you put it back in, you have to escape (slashes) it again... not worried about security here since it came from the db, but the escaping handles any single quotes (and few other chars) that might be in the post content...
but the main thing to note is that wpdb prepare will do that too (actually via walker escape by ref)...
Visit Cruise Talk Central and Mr Papa's World
btw, I did change ours to esc_sql() vs addslashes()... pretty much the same thing, but use mysql real escape... updated code above too....
Visit Cruise Talk Central and Mr Papa's World
You're right on the insertion; sorry for confusing the issue there. But on grabbing the data from the database, I don't understand why you would need to strip any slashes, unless they were double encoded. The slashes that are added for escaping purposes should only be for escaping purposes and wouldn't have been stored in the database... does the forum application itself have a need for the slashes to be stored in the database?
1 Guest(s)