bridgemanusa

No responses from yop-poll so I ended up changing plugins to WP-Polls, which works in both our staging and production environments.

bump.. Could anyone at yop-poll please have a look?

Thanks.

Thanks for the reply Edward. I ended up with a workaround that basically uses “brute force” embed to add the page title manually (which basically overrides what WP assigns).

Thanks again.

Solved – I pinged my host again (got a different support tech this time) and explained the situation that something had to have “changed” on the serve that is breaking my jquery enabled pages – and in fact, they upgraded php on my server without my knowing to 5.3.14, which broke it. By subsequently rolling it back to what it was running (5.2.x) it “magically” started working again.

Hopefully this will help someone else.

Anyone?

As a followup, the plugin would have to allow the ability to customize the form fields as well.

So.. I fixed my own issue. Apparently WP does not like the fact (as far as pagination goes) that I am only displaying “posts_per_page = 5” even though my global site config (in the dashboard) is set to 10. Changing the above code snippet to “posts_per_page => 10” eliminated the 404 page from displaying on the last page of the recordset.

Hopefully this can help someone else also.

In the wp_redirection_items table I found two entries, one right after the other that seem to be a result of changing the page parent. Example,

1) news/articles.php -> events/articles.php
2) events/articles.php -> news/articles.php

This elicited a behavior described above where the page just kept cycling back and forth, over and over and was a result of changing the page parent, then changing it back (possibly). Is the wp_redirection_items table part of the WP core or added by the “Redirection” plugin? I have been able to duplicate this more than once. The redirection does NOT show up in the plugin list in the dashboard so the only way to fix it is to delete the entries from the table itself (not ideal).

argh… well nothing was really deleted until the after the permalink was changed (in the dashboard) for the post and then the weirdness started happening. Not sure if it was a coincidence or not.

Thanks for your help! I’ll start a new thread for the “share this” plugin issues in case I cannot figure it out but I have a sneaking suspicion that it is leaving entries in the wp_options table that won’t either :
a) go away or
b) change

Thanks for the quick reply esmi. I found an entry in the “wp_redirection_items” table that basically redirected from “/” to “the url that was BAD” which is why it kept refreshing and going nowhere. I deleted it and the site is now functioning normally however I guess my question is how do values get in that table in the first place? Is there where permalink updates go?

Also, I disabled the “share this” plugin right after the update to the permalink was made (and before I checked to see if it worked in the browser) then upgraded to the newer “share this” plugin so I don’t know if that may have had something to do with it. Now, though, the “share this” plugin does not work. Are there values stored somewhere in the DB for the plugins?

Thanks again.

I give up.

Ok, so maybe I am looking at this the wrong way.

Question: Is it possible (in WP 3.0.1) to have both a Category and Page name be exactly the same without seeing some of the anomalies I am seeing?

Any feedback would be greatly appreciated. Thanks!

Well, I found a solution but not on the WP forum.

This seems to work:

<?php $excludeCats = array(1,5,4);
   if (have_posts()) : while (have_posts()) : the_post();
       if (!in_category($excludeCats)) { ?>
       ...do stuff...
<?php } endwhile; endif; ?>

Hopefully that helps someone else. Thanks for looking.

I think I figured it out.

This page shed some light on the situation:
https://codex.www.ads-software.com/Author_Templates

I assumed (incorrectly) that $curauth was a variable containing the ID of the authour but realized I had to grab the individual value of the ID as follows:

$authID = ($curauth->ID);

then modify my query to call all the posts from Category 8 (and below) posted by the $authID. Here is the modified code (much different than original)

<?php
         if(isset($_GET['author_name'])) :
         $curauth = get_user_by('slug', $author_name);
         else :
         $curauth = get_userdata(intval($author));
         endif;
        $authID = ($curauth->ID);
        $paged = (get_query_var('paged')) ? get_query_var('paged') : 1;
        $args=array(
          'paged' => $paged,
	  'cat' => '8',
	  'posts_per_page' => 5,
	  'author' => $authID,
          );
         $temp = $wp_query;  // assign original query to temp variable for later use
         $wp_query = null;
         $wp_query = new wp_query();
         $wp_query->query($args);
         ?>
<?php while ($wp_query->have_posts()) : $wp_query->the_post(); ?>

(format results below).
Hope that helps someone else also.

Turns out my issue was with IIS on XP. I built a new server (Win2008 R2) and installed and configured IIS7 with PHP5, MySQL and everything necessary for friendly URLs. A long and arduous journey but, solved.