I have a concrete5 site, which uses 'designer content' an add on available via their market place.
Our clients site requires the use of macrons for their language.
Now this is fine throughout 99% of the site, whether hard-coded html or via a content block etc. However, when macrons are used inside a block created with 'designer content' the macron is replaced with a "?"...
Can anyone help?
Unfortunately this site wont let me post an image to help you see whats going on due to my 'low reputation'....riiiiight thats helpful.
Thanks in advance!
usually the apparition of question marks "?" instead of certain characters is the sign of a charset coding problem. With C5 you should be using a generic UTF8 encoding however if your database table was set to use a different charset or if your php settings are set to a different charset, then you will get those weird characters.
You should start with your php.ini and set the charset to utf8
If that doesn't fix the problem, check this thread, it has a useful script to use to fix the database
http://www.concrete5.org/community/forums/usage/utf-8-or-unicode-problems-preventing-corrrupt-fonts-on-the-front/#52300
Be aware however that if content was saved while the charset was not correct, you may discover that the content still looks weird and you will have to insert it again AFTER having set the correct charset.
Related
I am setting up a RETS MLS program using phrets and just wondered what the heck the disable follow location means?
$config = new \PHRETS\Configuration;
$config->setLoginUrl('*****************');
$config->setUsername('****');
$config->setPassword('****');
$config->setUserAgent('****');
$config->setRetsVersion('1.7.2');
$config->setOption('disable_follow_location',false);
$config->setOption('use_post_method',true);
$rets = new \PHRETS\Session($config);
There was an old feature in PHP called "safe mode" which, when enabled, would complain if something was using cURL in a way where it would automatically follow server-given redirects. That option was added so that in instances where it wasn't needed (I've never seen it actually used by RETS servers, but it's defined as something RETS clients need to expect), it could be turned off to hide the warning. It should be safe to ignore nowadays with recent versions of PHP.
I'll likely remove that pretty soon just to clean it up.
Please can someone point me in the right direction for what I'm sure is a simple problem, but is causing me to go round in circles.I have three domains
.com
.com.au
.co.nz
I'm trying to keep a single code base for maintenance.
I've done some manual localisation work to change titles, contact details etc based on the url, using request.original_url and stripping out the relevant parts and setting some constants in the application controller (SITE, EMAIL, TELEPHONE etc).
It all works fine, except for my config.action_mailer.smtp_settings in the production.rb.
These obviously should change so the localised email account is used (info#...com or .com.au etc) but
I can't get the constants to be initialised before the environment is loaded. It makes perfect sense why it's not working, but I have no idea how to fix it.
I've tried putting it in initializers, the application.rb and setting it in the production.rb itself. If I move the code anywhere out of the application controller I get a no method error on request.original_url.
Is there a way of pulling out mailer settings so they can be exposed to variables? Or is the production.rb loaded at app start up and after that is unaffected by the end user.
Also, even though the language is remaining the same should I look at i18n for manipulating the site for these features? or is it not worth the effort for the few variables I want to change.
Thanks in advance.
You can just change settings in runtime:
ActionMailer::Base.smtp_settings[:host] = 'yourhostfromrequest'
You could just change the constants in your mailers, since constants in Ruby are mutable.
I use the latest CI version. In config.php:
$config['global_xss_filtering'] = TRUE;
I can't change this.
I need to save adserver tags (will stored in files, not DB), which contains also Javascript. So with this setting I cant save the adservertags, CI or the input filter removes some parts of it.
My first idea was to encode the adservertag with base64 in the client and then on ther server decode it again, what dou you think?
Sounds like a plan.
Except there is no native way to base64 encode on the client. However, a friendly fellow on Stack-O has solved this for you already: https://stackoverflow.com/a/246813/183254 Be sure to share an upvote for them.
My project is based on CodeIgniter, but I guess this question isn't about it at all.
First, I have enabled query strings and a search function. Search string passes to the “searchterm” variable and when I pass it through the form, it works fine and looks like:
http:// local/home/search/?searchterm=testtesttest
Okay, now when I input some cyrillic string in a search form, it works fine as well, the URI would be for example:
http:// local/home/search/?searchterm=привет (in chrome) or
http:// local/home/search/?searchterm=������ (in IE, Opera etc.)
Two above cases work fine, BUT WHEN I enter the CYRILLIC search string directly from the address bar (for example, in Opera or IE) it doesn’t wanna search anything. $_GET[‘searchterm’] is empty, and as for QUERY_STRING, it is something like searchterm=������ (all data from profiler).
I urldecode my string from the controller, but it somehow doesn’t work. I also tried some iconv() cases, from what I’ve googled, but they also didn’t work.
So the question is why all other browsers except chrome doesn’t retrieve CYRILLIC $_GET variable from the address bar if it was entered from there? Passing through the form everything works fine.
Thanks in advance, guys. Hope for your help.
P.S.
I've also found:
%D0%BD%D0%BE%D1%87%D0%B0%D0%BB%D0%BE
this is passed from the form, accept-charset is set to UTF-8. In that case, as I said, everything works fine. And:
%ED%E0%F7%E0%EB%EE
this comes in the address bar when typing the string directly inside the address bar. So I guess every browser changes my cyrillic symbols into something strange... I don't know :(
Don't forget that with Chrome everything works fine! Maybe it's because by default this browser doesn't encode cyrillic symbols in wrong way like other browsers.
I'm guessing part of the issue here is that you are using UTF-8 characters in the URL ... You can setup PHP to use UTF-8 by default from within the php.ini file or by adding ini_set('default_charset', 'UTF-8'); somewhere in your application, (I add it to the root index.php file within CodeIgniter if I can't modify the .ini file).
I tested both Japanese and your example in Firefox and Safari quickly and they both displayed the correct strings. More information about setting up Apache/PHP for UTF-8 can be found in this excellent guide.
In an MVC framework, I have a model with an "identifier" field. This field can be whatever is used by the user as their unique identifier. I then use this identifier field in URLs to access the relevant resources.
/people/<identifier>/
In one such case, the user is using identifiers of the format 00/000. The quick among you will have spotted the problem straight away - how do we know which part is the identifier, and which part the action?
The obvious solution is to use URL escaping (%2F being the relevant code). However, this confuses my apache load balancing proxy as well as the application server on our demo box (running passenger). Although annoyingly this works fine on the local development servers. URLs including %2F seem to cause 404 errors from the server (not the application!).
What i'm looking for is a general approach to solving this problem, while keeping a tidy URL.
The stack which caused this problem is: Ruby 1.8.7, Merb 1.0.12, Apache load balancing to a thin cluster on production, Passenger on the demo server, and working with unproxied thin on development.
The cleanest way would be to prevent the user from entering in a forward slash character in the first place. If it is necessary to support this format, then there is no way around having to use URL escaping.
You could always use a home-grown encoding that replaces / with some other character that is never used in your identify field and then converts it back when reading it from the URL.
For example:
http://yoursite/people/00/000
becomes
http://yoursite/people/00-000