[fx.php_list] Re: Character conundrum with #

  • From: Troy Meyers <tcmeyers@xxxxxxxxxxxxxx>
  • To: FX.php List <fx.php_list@xxxxxxxxxxxxx>
  • Date: Mon, 30 Apr 2018 10:46:04 -0700

Rodney,

The solution was to a very esoteric problem, but the way I got there might be 
more interesting.

I felt like I have blinders on since the PHP that does the put-data-in-field 
request is an AJAX handler and doesn't have a "page" to print diagnostic stuff 
on. That PHP file is accessed when I use the jQuery $.getScript() function, 
which sends data as a GET and expects back JavaScript as an answer, which is 
executed on the user's browser to modify the page. So, to see what was being 
sent to the AJAX handler and when FX in the handler was sending to the WPE, I 
added these few output lines in the AJAX handler, and elsewhere made 
$showFXquery TRUE:

                if ($showFXquery) {
                        // Do diagnostic to showincoming and the FX query to WPE
                        // Output code to show a JS alert to show this in the 
calling page
                        $qweryString = $_SERVER['QUERY_STRING'];
                        echo "alert('query string is \\r".$qweryString."');\r";
                        echo "alert('FX URL sent to WPE:\\r".$dgWriteFXresult 
['URL']."');\r";
                }

This simply interrupts the normal flow when the user clicks the Save button (or 
whatever) an puts up two dialogs, first showing the GET data sent to the AJAX 
handler, and then the entire URL sent to the WPE.

By looking at those, I could actually see that the problem did NOT originate at 
the point where FX was getting set up with parameters, but in the incoming GET 
data, and thus from the JS of the actual user's web page.

The problem was that the JS that was being executed did NOT have the 
encodeURIComponent() in all the places I thought it had. And that was because 
an older version of the pagename.js file was being served up... because this 
site still uses BlackBelt which interprets some very old pages written in CDML. 
Obviously I've got to get rid of that, but the way the .haccess file was set 
up, any requested file besides ones ending in .php were being sent to the 
BlackBelt directory instead. That included .js files, so the AJAX file in the 
legacy BlackBelt directory was being supplied, not the one I thought.

So, the fix was to add this line (and another for .css files) to the top level 
.htaccess file:

# Troy added this next one to try to make the CSS and javascripts folders/items 
from needing to be doubled in BBT
RewriteRule ^[^.]+\.js.*$ - [L]    # any files ending in .js
RewriteRule ^[^.]+\.css.*$ - [L]    # any files ending in .css

Beyond that point everything else was being redirected to the BBT directory, 
and the old files in there.

Troy



And your solution was ...?

Yours,

Rodney Schmidt

_____________________________________________________________________
     FX.php Official Web Site -- http://fx.iviking.org/
FX.php Official Mailing List -- //www.freelists.org/list/fx.php_list
     (Subscribe, unsubscribe, and more at the mailing list site!)

                  FX.php_List@xxxxxxxxxxxxxxxx

Other related posts: