Without further delay..

go to file

./include/common_functions.inc.php

find the function:

 function bugs_BBDecode($text, $formatting = true) 

comment out the first line in the function:

$text = bugs_sanitize_string($text); 

I haven’t tested this with other language packs /localization settings. This works fine with English Language.

1. Same Origin Policy
2. Frame Load incomplete.

No. 1 is easy, if the two Top Level Domain aren’t the same, you cannot read the iframe data. Even for the same domain and different subdomains, one needs to write the following on the top of both client and the server:

 document.domain = "mytopleveldomain.com" 

No. 2

How to determine that the iframe has loaded completely in order to scan data off it ?
Well,

 <code>$(document).ready(function()</code>

will surely tell you if the page has loaded, but it won’t wait for the iframe(s) inside the parent document to finish loading, before returning true.

One may think, this might work:

$(document).ready(function() {

     $('#myIframe').ready(function() {
                // ALL CODE GOES HERE
     });
});

BUT, it doesn’t. The above code will tell you ONLY that the iframe loading has started, but won’t
tell you if its done.

Solution:
Well, the OLD window.onload to the rescue:

window.onload = function () {
    $('#myIframe').ready(function() {
                // ALL CODE GOES HERE
     });
};

http://www.mysite.com/users/images/user123/profile.jpg

Now, on changing this image, sometimes browsers don’t clear cache and thus show the last image. In Order to solve this, use a random number at the end of the image location and you will be able to see that image. as browsers will not cache it.

http://www.mysite.com/users/images/user123/profile.jpg?123

One method that I used is:

$stamp = time();
$imageLocation  = 'http://www.mysite.com/users/images/user123/profile.jpg?'.$stamp
echo $imageLocation

This should work.

Consider this script [parentProcess.php]

$backgroundCall = 'php childProcess.php > /dev/null &';

shell_exec($backgroundCall );

echo "Hello world ! My background job is fired";

// other code , redirects etc

When you call a background file with the ‘ampersand’ in the end, it sure becomes a background file.
But it does not mean that the user will get control back of the browser. If you are using sessions,
the webpage will be busy until the background process finishes execution.

Why is that ?

[There is bug described here and it is still not solved even in the php 5.0+ versions.]

What happens is that the child process which is called by the system() ,exec() or shell_exec() command
holds the file lock on the parent process, thus locking the session file.
Thus, the session file being locked session_start(); function cannot access the file.
This is due to to open file descriptors locking the session file.Your entire session will be locked, so none of the pages of the website can be opened ( which are under session control )
unless you change the browser or delete cookies.

Solution:

There are places on the internet which provide C code and perl code to do that. But PHP has its own
function , which sadly is ignored session_write_close(); This function can be used to trigger the close of session. Thus instructing the session
that there is nothing to write until the next session start. Triggering this before firing background process will not hold locks on
the session file.

$backgroundCall = 'php childProcess.php > /dev/null &';

session_write_close();

shell_exec($backgroundCall );

echo "Hello world ! My background job is fired";

// other code , redirects etc