Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thanks Kafkaesqui.

    I managed to find a post on PowWeb’s forum that indicated that php_flag doesn’t work on PowWeb. (Apparently, this has something to do with PHP run as SuExed (sp?) on PowWeb for security/something reasons. Can’t find the post with the details anymore…) The solution is to set the flag in a php.ini file.

    I grabbed a script from tips-scripts.com/?tip=php_ini#tip which gets the default php.ini, copies it locally and sets register_globals to Off (all of this in case PowWeb changes the default file).

    I also set up a cron job to run the script every day.

    Pretty proud of myself, considering: a) it was the first time I executed a PHP script for a specific purpose; b) I knew nothing about php.ini; c) I had never used a cron job before; d) I’m basically a complete newbie at the administration of a web site.

    Any idea why adding a .htaccess to my site’s root (where WordPress is installed, BTW) results in all web accesses giving a 500 Internal Server Error? The only thing in the .htaccess file is the instruction to turn off register_globals.

    My host is PowWeb.

    I guess I’ll change the wp-settings.php file but still, I wonder why the above happens.

    Thread Starter berlueur

    (@berlueur)

    OK, replying to my own question here.

    Not much love was given to my post… but, not to worry, I found out how things worked on my own.

    So, for the benefit of others who might be in the same newbic position I was in (who knows? there really might be some…), here goes.

    The normal practice is to define the theme’s encoding in the “header.php” file. It is done in the usual manner, i.e.:

    <meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

    with the added twist that the content type and charset are retrieved by appropriate PHP functions, which obediently return the settings defined by the user (though I believe the “html_type” is not settable through the standard admin interface).

    So, after verifying that the theme’s designer has correctly placed this bit of code in the theme’s “header.php” file (or after having added it himself/herself if it was missing), the theme localizer can then translate all the theme’s files with his/her choice of encoding, in accordance with the encoding setting of his/her blog (ideally UTF-8), cradled by the unassailable comfort of knowing that his beloved idiosyncratic characters will be treated with respect and devotion all around the world.

Viewing 3 replies - 1 through 3 (of 3 total)