silfani

Also, every other admin page works fine, i.e., returns you to the same page without a 404 error.

This is happening to me too. On this particular server (of an university) the site url is also set to an unreachable address (webprod instead of www) and I have to fix it manually through phpmyadmin into the database. This clears up most problems except what is described above. I wonder if this has ever been addressed or any tips suggested to work around this problem.

King Framework screwed up my widgets. Others no longer work nor can I drag or drop. Anyone else encounter this problem? As of now, my blog is fried.

Actually the King’s Framework seems to have devestated my widget control. Neither can I drag or drop, nor is the full complement of widgets showing up including other widgets that were working fine earlier.

But even when I deleted it, my widgets were still screwed. I even reinstalled the widget plugin to no avail.

Check here https://www.ads-software.com/support/topic/111419

This is seems a like a common enough problem for some server set ups that it should be included in the install section.

I’ve been having the same problems.

I also get the wrong address for the blog due to some redirection issues, i.e., webprod.server.com/~blogsite

Very frustrating.

I’ve been looking for a plugin implementation for this, whereas every page or even post would have two parts: the main content, and the sidebar content that may not necessarily have to be a sidebar as opposed to a floating box.

Same problem here. I have a google news rss feed, and it seems as if the widget is stripping the last bit, &output=rss, from the address.

At first I thought it was because I was switching between themes, but it persists as a problem. I am also having conflict issues between photopress and widgets.

GOT IT!

It’s ugly but it works. To get rid of the redundant subdomain, just subtract that part of the $index and $qstr strings that is giving the problems.

To see what they originally were getting, I ran a trace script on the $_SERVER calls in the get_pagenum_link function:


<?php
echo $_SERVER['REQUEST_URI'];
echo $_SERVER['PHP_SELF'];
?>


This gave the orginating file as well as the subdomain. BINGO!

Thus to lines 377 to 398 of template_functions_links.php, I added a substr php command to excise this problematic subdomain:


$qstr = wp_specialchars($_SERVER['REQUEST_URI']);
$qstr = substr ($qstr, 8);
...
$index = $_SERVER['PHP_SELF'];
$index = substr ($index, 6);


The discrepancy in the substr calls are because I am getting %7E in $qstr, two characters more than the regular single ~ in $index.

Thus in general, for $qstr, the number should be the length of subdomain name + 4, and for $index it should be +2.

This seems to have cleared up other 404 errors originating from the login as well as all instances of previous/next entries misdirection.

GOT IT!

It’s ugly but it works. To get rid of the redundant subdomain, just subtract that part of the $index and $qstr strings that is giving the problems.

To see what they originally were getting, I ran a trace script on the $_SERVER calls in the get_pagenum_link function:


<?php
echo $_SERVER['REQUEST_URI'];
echo $_SERVER['PHP_SELF'];
?>


This gave the orginating file as well as the subdomain. BINGO! This is consistent, so need to excise it.

Thus to lines 377 to 398 of template_functions_links.php, I added a substr php command to excise this problematic duplication:


$qstr = wp_specialchars($_SERVER['REQUEST_URI']);
$qstr = substr ($qstr, 8);
...
$index = $_SERVER['PHP_SELF'];
$index = substr ($index, 6);


The discrepancy in the substr calls are because I am getting %7E in $qstr, two characters more than the regular single ~ in $index. However, check what you exactly get by running the trace.php script

Thus in general, for $qstr, the number should be the length of subdomain name + 4, and for $index it should be +2.

This seems to have cleared up other 404 errors originating from the login as well as all instances of previous/next entries misdirection.

GOT IT!

It’s ugly but it works. To get rid of the redundant subdomain, just subtract that part of the $index and $qstr strings that is giving the problems.

To see what they originally were getting, I ran a trace script on the $_SERVER calls in the get_pagenum_link function:


<?php
echo $_SERVER['REQUEST_URI'];
echo $_SERVER['PHP_SELF'];
?>


This gave the orginating file as well as the subdomain. BINGO!

Thus to lines 377 to 398 of template_functions_links.php, I added a substr php command to excise this problematic subdomain:


$qstr = wp_specialchars($_SERVER['REQUEST_URI']);
$qstr = substr ($qstr, 8);
...
$index = $_SERVER['PHP_SELF'];
$index = substr ($index, 6);


The discrepancy in the substr calls are because I am getting %7E in $qstr, two characters more than the regular single ~ in $index.

Thus in general, for $qstr, the number should be the length of subdomain name + 4, and for $index it should be +2.

This seems to have cleared up other 404 errors originating from the login as well as all instances of previous/next entries misdirection.

Yes here here. What’s the PHP work around? This problem seems to be occuring in subdomains set up as such: domain.com/username or domain.com/~username, where the username is being duplicated…

Actually, I think this login thing is consistent with the Previous/Next Entries problem. The url is not resolving correctly (duplication of subdomain) which seems to be a server problem.

Ack!

Actually, I found that my subdomain wordpress installation is working fine, but my tilda’d site isn’t — so it’s definitely something to do with the server redirection… Hmmm..

Made this brutal mistake when trying to find a solution to the previous entries problem. I was lucky in that I could manually login using the direct url.

I got simplified, non-styled login and admin pages, but was able to change the URI back from options.

That was a close one, again!