WordPress.org

1. tliebig
   Member
   Posted 7 years ago #
   

   Hello,

   I have my blog set up at http://www.htwm.de/~tliebig/testblog/ and the ~ in the address causes all included files to be not working.

   That is, the css file is not referenced as
   <link rel="stylesheet" href="http://141.55.199.72/~tliebig/testblog/wp-content/themes/default/style.css" type="text/css" media="screen" />

   but rather as
   <link rel="stylesheet" href="http://141.55.199.72/%7Etliebig/testblog/wp-content/themes/default/style.css" type="text/css" media="screen" />

   causing the path to be broken, which breaks the entire theme. Any ideas what I can do about the path? Login does not work as it points to Login

   Is there any place where I can repair the URL handling of WP?

2. ifelse
   Member
   Posted 7 years ago #
   

   I'd be tempted to hardcode the link to the css file. Open up wp-content/themes/default/header.php and change
   <link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />
   to
   <link rel="stylesheet" href="~tliebig/testblog/wp-content/themes/default/style.css" type="text/css" media="screen" />

3. Cypher
   Member
   Posted 7 years ago #
   

   I would think that hardcoding the stylesheet_url will get the OP past the first problem, but as the underlying code will continue to encode the URL, they'll have more problems as they get farther.

   The real solution for this case would be isolate the location in WP where the encoding is done and prevent it from happening.

   I took a quick glance at the code but didn't find anything specific yet, but perhaps people a little more familiar with WP code layout/structure will point you in the right direction.

   Regards

4. techwench
   Member
   Posted 7 years ago #
   

   This is caused by the wptexturize function. You'll have to remove the texturize filter from wp_head.

   You could try creating plugin with the following code, save it as untexturize-wp-head.php (make sure you don't have any whitespace before and after php tags), upload to plugins directory and activate:

   <?php
/*
Plugin Name: Untexturize wp_head
Version: 0.1
Author: Me
Description: Untexturize wp-head
*/

remove_filter('wp_head', 'wptexturize');
?>

5. tliebig
   Member
   Posted 7 years ago #
   

   Hey Techwench,

   thanks for your Plugin, but I had to dig deeper:

   as I said, I was not even able to login, as it gave me a server timeout. What fixed the problem was to correct the database siteurl:
   I had to change the database field 'wp-options.siturl' from 'http://141.55.199.72/çtliebig/testblog' to 'http://www.htwm.de/~tliebig/testblog' by hand via PhpMyAdmin.

   That is, somewhere in the installation process, the SITEURL value is incorrectly encoded and the incorrect string is entered in the database. Is there any fix for that? Can someone point me in the right direction where to fix the wrong encoding of the siteurl string during installation?

   thanks,
   torsten

6. tliebig
   Member
   Posted 7 years ago #
   

   So much for encoding, nightmare of every developer:

   The first value should read like in the first posting where it shows the broken string. Instead this form changed it to a question mark.

   So, put it in words:
   the wrong siteurl value in the database reads 'IP - slash - percent_symbol - capital E - number seven - tliebig'
   while it should read 'www.htwm.de - slash - tilde - tliebig'

   The question remains: where is the siteurl value wrongly encoded during installation?

7. tliebig
   Member
   Posted 7 years ago #
   

   Findings:

   1. the URL is stored in the database, under wp-options.siturl
   2. it is stored there during installation and probaby never changed thereafter.
   3. during installation, this url is created through the following code in wp-admin/upgrade-schema.php line 154:
   $guessurl = preg_replace('|/wp-admin/.*|i', '', 'http://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']);
   4. My server encodes REQUEST_URI, using phpinfo() I also get the ~ instead of the tilde
   5. this encoding only applies to REQUEST_URI, PHP_SELF and the like all do show the tilde as they are supposed to do

   and unfortunately
   6. changing this line is not an option since I want to employ WordPress for my university and give users the options to install their own blog with just a couple of clicks. Updating to newer WPs should not break the entire system.

   currently trying to contact the Admin and see if he can correct the problem.

8. manstraw
   Member
   Posted 7 years ago #
   

   I just viewed your site. It looks fine. Did you resolve this?

9. tliebig
   Member
   Posted 7 years ago #
   

   Sort of. Replaced $_SERVER['HTTP_HOST'] with $_SERVER['SERVER_NAME'] and $_SERVER['REQUEST_URI'] with $_SERVER['PHP_SELF'].

   Just need to remember than when updating WordPress, I need to update that specific line as well. Our university's server setup is a little *ahem* different as to what one would expect out in the free wild. Well, challenges are something to grow on, I guess =)

Topic Closed

This topic has been closed to new replies.