I have a TYPO3 4.5.37 website which works perfect on my local windows enviorement, but after uploading it to a Linux environment I get a broken front-end (the back-end is functioning normally) see:
What I already tried;
Converted all database tables to a utf8_general_ci collation
[BE][forceCharset] = utf-8
[SYS][setDBinit] = SET NAMES utf8;
When I drop my database (so there is no connection) the problem with the output is still there so I think this has nothing to do with the database.
The website outputs the front-end with TemplaVoila, I updated TemplaVoila from 1.6.x to 1.9.2 but this didn't work.
On the same server are a lot of other working TYPO3 sites hosted so this has probably nothing to do with the server settings.
I'm running out of options now. So I hope somebody can help me out here.
I found the problem. The compressionLevel was set to '1' in the install tool, when turned off the problem with the encoding on the front-end disappeared.
[FE][compressionLevel]
Determines output compression of BE output. Makes output smaller but
slows down the page generation depending on the compression level.
Requires a) zlib in your PHP installation and b) special rewrite rules
for .css.gzip and .js.gzip (please see _.htacces for an example).
Range 1-9, where 1 is least compression and 9 is greatest compression.
'true' as value will set the compression based on the PHP default
settings (usually 5). Suggested and most optimal value is 5.
Related
I'm strugelling with strange problem. My hosting provider do not offer cpanel with PHP config option (i know, disaster). For the purpouses of my website I had to change PHP version from 5.2 to 5.5. So admin told me i can use htaccess and command: AddHandler php5.5-fastcgi php
And ok - it activates proper PHP version, but what is totally strange -> change totally my mysql database encoding. The output is following - all posts, pages etc. which were previously displayed in my native language (polish) right now do not display polish diacritic symbols. I've tried to change the whole database collation to UTF8_general_CI yet it didnt solve the problem. I use wordpress as cms, but the issue appears also in my own cms, as well as plain php with mysql. Any ideas how to change that? thanks!
I am in the process of migrating an existing Drupal website from another provider to Bluehost.com -- while I think using Bluehost.com is not relevant in this context I thought I'd mention it anyway, in case there are indeed some particularities I'm not aware of.
The site is a Drupal 6 installation and it did work previously I am told on bluehost too so you think it shouldn't be any problems, however, having copied it over I encounter a big problem: all the responses from Drupal are sent with Content-Encoding set to application/x-gzip. This has the implication of all browser presenting a download dialog box rather than rendering the content.
I have actually curl'd the index page and ran it through gunzip and the output is the correct HTML for the site -- just that it somehow ends up being gzip'd and this mangles the content type and confuses the browsers.
Talking to previous maintainers of the site they suggested using PHP 5.4 (they were running it on php 5.5 as I understand and despite all the Drupal suggestions it was running perfectly well I'm told).
I am trying to eliminate now any type of gzip'ing that occurs here so I've got it down to a few layers which could cause it but eliminating those it still doesn't work:
SetEnv no-gzip 1 in .htaccess
zlib.output_compression = Off in php.ini
drupal had the boost module installed and some corresponding settings in .htaccess -- i've removed those from the .htaccess file as well as deleting the boost directory from sites/all/modules
The problem still stands and my files are being sent to the browser compressed. Is there any other way to disable this?
Note that this only happens for pages inside Drupal, having uploaded a simple php page and navigate to that url works fine -- which suggests therefore a drupal (rather than apache/php) problem.
I've noticed a module mimedetect which has a definition for application/x-gzip in there but not sure how could this affect it as removing this didn't render anything useful either.
Any ideas where to look and/or what might cause it?
Happy to provide any other insights that might be useful in diagnosing this.
Ok so having actually reset the database cache and with the settings above this now works. I'm trying to figure out which one of the above actually solved it.
m having a strange problem never faced it before and tried every thing and i mean everything but no luck at all.
What happened was i downloaded the application source code built on joomla 1.7 via ftp from the live server and deployed it on my localhost and configured it correctly. Now what happened is it displaying some sort of raw data all over the browser window, attached is the screenshot.
Please guys its been 5 days since i stuck in this mess any help will be highly appreciated
Thanks in advance
Maybe you have installed an extension, which supports distribution of PHP code as binary code? There exist different extensions to PHP, which support this kind of functionality. Probably the most widespread is Zend Guard. To execute a script which was encrypted by this software your PHP needs to load the free loader extension provided by Zend. If your server has loaded this extension and your localhost does not, the output might be something like you encounter.
Your first step should be to compare the output of phpinfo of both servers. If Zend Guard (or a similar extension) is loaded on your production server and not on your localhost, this might be the problem. Next step should involve taking a look at the PHP files and search for one which contains lots of unreadable characters. If this seems unreasonable to you, you might as well just install Zend Loader and see if it works then, which might be less work.
I have installed WordPress locally on WampServer for testing purposes. I discovered that when I changed the permalinks structure to reflect post title (the title is in my native language 'Urdu'), and requested the following page in browser
http://localhost/blog/طوفان-اور-سیاست-دان/
it returned a 404 error which said
The requested URL /blog/طوÙان-اور-سیاست-دان/ was not found on this server.
I am using WampServer 2.2 and WordPress 3.4.
Since many PCs don't have an Urdu font installed, here is the image of first address for you.
The English translation for urdu part is "Storm-and-politicians" . Urdu, unlike English, is written from right to left.
How can I configure my local web server to accept web adresses in Urdu? Many sites including the Urdu wikipedia use this scheme.
How to learn more about this problem:
Each time you see apache giving you a not-found message, you will find an according entry in the error log of your webserver. It contains more information what happens behind the scenes.
For example you will see a message similar to this one:
File does not exist: C:/.../htdocs/blog/\xd8\xb7\xd9\x88\xd9\x81\xd8\xa7\xd9\x86-\xd8\xa7\xd9\x88\xd8\xb1-\xd8\xb3\xdb\x8c\xd8\xa7\xd8\xb3\xd8\xaa-\xd8\xaf\xd8\xa7\xd9\x86
This is useful because it allows you to see the binary sequence the apache webserver uses to query your file-system for the file.
You can turn this into a PHP string to decipher it:
echo "\xd8\xb7\xd9\x88\xd9\x81\xd8\xa7\xd9\x86-\xd8\xa7\xd9\x88\xd8\xb1-\xd8\xb3\xdb\x8c\xd8\xa7\xd8\xb3\xd8\xaa-\xd8\xaf\xd8\xa7\xd9\x86";
Depending in which encoding you view this output, it can look like the following:
UTF-8 : طوفان-اور-سیاست-دان
Ansi : ÏÀ┘ê┘üϺ┘å-Ϻ┘êÏ▒-Ï│█îϺÏ│Ϭ-ϻϺ┘å
ISO-8859-1: طوÙان-اور-سیاست-دان
Apart from having this looking differently, the question is why does the webserver not find this file?
As you write you use wordpress, you probably just have missed to enable these type of URLs, in Wordpress jargon those are called "Pretty" permalinksCodex.
I am running a fairly standard LAMP stack.
The problem is an intermittent rendering of UTF-8 characters correctly. About 50% of the time the non-ASCII UTF-8 characters render correctly (e.g. with appropriate diacritical marks), but about 50% of the time I get the '?' rendition instead. If I reload the page, sometimes it corrects the problem and sometimes it does not. It happens with all browsers on all platforms, which suggests a MYSQL or Apache problem but I have not been able to figure it out.
The data base itself is in UTF-8 format and I have never seen the problem while browsing the database in phpMyAdmin.
I issue a SET NAMES utf-8 command upon opening the data base (and have tried changing that to a SET CHARSET utf-8 command) with no luck.
What's confusing me is that it is intermittent, happening in streaks, e.g. it will happen on 30 pages in a row (even if they are just reloads), and then clear up for 10 pages, and then happen again for a few pages, etc.
You can try to see the problem by hitting the 'list' button here: http://latin-words.com/list_vocab.php though it may take many reloads to either make it happen or make it go away
Server Configuration:
Ubuntu: 9.10
Mysql: 5.1.37
PHP 5.2.10
Apache 2.2.12
Any hints would be greatly appreciated?
edit:
For searchers sake, from the comments, the problem was actually an issue doing a SET NAMES utf-8; (incorrect) instead of an SET NAMES utf8; (correct) That doesn't mean my much more obscure reason posted below cannot also be the reason ;)
Sounds like a problem with locales & iconv, try to determine what locale is used in the webserver process the moment all is well, and the moment it doesn't work anymore (try $currentlocale = setlocale(LC_ALL,NULL); or $currentlocale = setlocale(LC_CTYPE ,NULL); to get the used locale).