CakePHP Images with special chars in name are not displayed - php

I'm using CakePHP 2.0.4, PHP 5.3.1, Apache 2.2.14.
For example: the filename is F#7m7~1.gif. It really exists, the path and filename are correct.
Before print HTML tag, I encode it by using urlencode() and the tag goes like:
<img src="/chord/img/chords/F%2523m7~1.gif" alt="F#m7">
But the image is not loading. ('Chord' is a CakePHP Plugin)
I also tried to load it directly on the browser, http://myapp.localhost/chord/img/chords/F%2523m7~1.gif but what I get is: "Missing Controller Error: Chord.ImgController could not be found."
Everything works fine with the file as A~1.gif, but it brokes with filenames such as F#m~1.gif, B(7)~1.gif etc.
Everthing was working ok in pure PHP coded version. Now, it's not working at CakePHP.
Is there anybody have a clue?

You seem to be double-encoding it, the right urlencode for F#7m7~1.gif is F%237m7~1.gif, not F%2523m7~1.gif. Just remove one of them.
The Missing Controller error is just because there is no such file on your server, so Cake thinks you're trying to call an ImgController, within the Chord plugin. Try http://myapp.localhost/chord/img/chords/F%237m7~1.gif, it should work.
Anyway, as #GordonM pointed out, it's best to stick with normal characters for filenames.

Related

How to remove %2F generated by url() in Laravel 5.4

I need to get the name of my image and to add img folder before the name of the figure. I use url() function like below
{{ url('img', 'articles/mypic.jpg') }}
The issue is that I don't get
http://127.0.0.1:8000/img/articles/mypic.jpg
but I get %2F instead of /
http://127.0.0.1:8000/img/articles%2Fmypic.jpg
it works fine in localhost, but does not work properly on my server. I need to reconfigure apache to make it work, and I would like to avoid reconfiguring Apache. Could I avoid encoding / into %2F?
You can use urldecode, but you needn't to decode it for browser will process it well without decode.
php > echo urldecode("http://127.0.0.1:8000/img/articles%2Fmypic.jpg");
http://127.0.0.1:8000/img/articles/mypic.jpg

PHP - $_SERVER['QUERY_STRING'] has "&"

In my php script, I'm trying to get the query string ($_SERVER['QUERY_STRING']), append it to another url, and then make a redirect.
If I use the query string without any processing, the new url shows "& amp;" for all the "&'s." Therefore the new url won't work.
I print out the $_SERVER['QUERY_STRING'] and view the page source. It does use "& amp;" for all the "&'s." It doesn't make sense to me and I wonder why. Is it just my server's configuration or PHP's default?
UPDATE: I tested it on MODX CMS using snippet. If running on a regular PHP script, there is no such issue. I guess the problem is with MODX. Any idea?
Just an idea:
If you use TinyMCE to edit stuff, it changes all &'s to &'s - that has been driving me crazy for a lot of times. That happens in snippet calls and can be debugged if you either deactivate the rich text editor for a resource or "quick edit" a resource.
Also good practice: put snippet calls into a chunk. You can call that chunk without risking the syntax of the snippet call.

Typo3 getTypoLink_URL creates wrong link after language change

I hope I can manage to explain this problem...
I have an T3-extension that handles shared content.
In this shared content, we have links (page-ids) that are defined and converted into something like /en/clients/contact, using
$cObj = t3lib_div::makeInstance('tslib_cObj');
$href = $cObj->getTypoLink_URL($linkValue); // $linkValue is an integer (e.g. 153)
This works fine - until I change the language on the page. Then, the last used URL kinda «sticks» and the language indicator isn't present in the URL anymore.
Means:
call the german page -> works
change to english -> works
change back to german -> the english link is presented.
So the above link turns out like clients/contact (the leading slash is gone as well).
Oddly enough, I have a local installation of the same page where the problem doesn't occur. It's just on the page that's online.
I tried to find differences in the configuration, but there aren't any.
The only difference I could find so far is, that I use Typo3 v4.5.35 for the local installation and v4.7.17 for the online installation.
Any ideas???
This was very odd... but, I found a solution.
Instead of using $cObj->getTypoLink_URL($linkValue); I'm using this:
$configurations['additionalParams'] = "&L=".(int)t3lib_div::_GP('L');
$configurations['returnLast'] = 'url'; // get it as URL
$configurations['parameter'] = $linkValue;
$href = $cObject->typolink(NULL, $configurations);
It seems that when I created the $cObj, the L-Parameter got lost somewhere, somewhen. By adding it manually, the Link works as expected.

Accessing Object in PHP

I've some strange issues with some php code.
if ($user->userType=='admin'){
If I use the above command, the php engine just stop interpreting and display the code in plain text on my browser. On the other hand if I use the below method it works:
if ($user['userType']=='admin'){
Again here also:
$_SESSION['currentUser']->id
If I use the above code it just displays the rest of code as plain text:
id); // fail user }else{ $authentication="failed"; $noAuthPresentation="loginForm"; }
Why this is happening? It's a big project and I don't want to change every line where there is an occurrence of ->.
Do I need to change some setting somewhere? I'm using WAMP server with php 5.5.12.
Any help ? Thanks!
You're mixing up types, user is an array, and not an object. Something in your php config is doing something strange to your error display it seems. Right click on the page that has the errors, and view source if possible.
Does login.php contain html and php code by chance?

Wordpress XMLRPC API post (html) error parse error not well formed

I am using Wordpress's XMLRPC API and the IXR_Library php class for WP API. wp.newPost is working normally if I use plain text or just simple text in body/content of the post but when I am posting a autocreated full html/shortcode content, it always gives me this error
Array ( [faultCode] => -32700 [faultString] => parse error. not well formed )
The content I am trying to post is a post content I normally use within WP with shortcodes but I want to post it via php using API since I am trying to automate my blogging.
You can check the body/content I am trying to post below
http://pastebin.com/U94XVZGT
Thats the content thats shown in XML debug mode (probably seems already html encoded)
Below is the full XML call and response returned via debugging, have removed user/pass from it
http://pastebin.com/26Nyx97K
I would really appreciate any possible help, I have already tried php's htmlentities and htmlspecialchar functions to encode my body and even tried str_replace to replace[ ] brackets in thought that they might be causing it
Again, its certainly due to the content code as I tried just a Hello World plain content and it worked ------------------------------------------------------------
A Update, earlier I was getting the html content from a textarea using $_POST, just now I tried to use same content in same variable but used ' ' single quotes instead around the content body and now posting works but I get a error
Warning: strpos(): Empty delimiter in wp-includes/class-wp-xmlrpc-server.php on line 4338
So if I use $body=$_POST['body']; it doesnt works and gives main error but directly using $body=' htmlcontent inside '; works but gives above strpos error
Please try adding the xml package:
sudo apt-get install php-xml
, this has resolved my problem.
TO anyone else having this problem, I fixed it. At end of it seemed the problem was due to wrong character encoding, I needed to Pass UTF8 but the content was being passed in some other char encoding (windows one) making some text and other languages not parseable, I modified my code to make it UTF 8 and now it works
I've changed my password to contain no symbols and it solved the issue.
I'm still not sure what broke everything initially but you might as well try changing it and trying again and see if that works for you.
To anyone else having this problem, it might also relate to WordPress bug #18310.
There is a patch for WordPress available at http://core.trac.wordpress.org/attachment/ticket/18310/18310-3.diff
See the WordPress bug report on their trac install at http://core.trac.wordpress.org/ticket/18310

Categories