WWDay3

It seems to be one of my plugins that I cannot do without. So, is there a way for me to cleanly go back to the prior version?

My host recently put in an .htaccess file (where I can’t see it) that is blocking gets to wp-cron.php. They said I am using way more CPU than I should, and that my script was “calling itself” over and over (I had to explain it’s not “my script”). Apparently wp-cron was going into a hard loop or something similar and really causing havoc.

I checked, and that table is not missing from my install, so I doubt it’s the problem.

Can wp-cron be modified to not fire on every page load, but perhaps just on certain pages or at certain times?

Hmmm – for me to provide a link to a page that produces the 404 error (which, of course, nobody has ever seen :)), I would also have to provide a link (logon) to my admin that the symptoms could be verified. Hmmm, I think I’ve been the victim of a canned response.

Uh, never mind.

Using the array syntax as listed above, how does one do a ‘not equal’ operation? Also, is post_title available in the query array? Better yet – is there a place where I can look all of these questions up?

Rats. I made the changes and they worked just fine. Then I activated AStickyPostOrderer, and the same message came up. So, I guess that plugin is to blame. Not sure if it’s possible to create a workaround

You’re saying id I passing the data via array values, instead of a url “string”, it will resolve the issue? OK, I’ll try it and report back.

Huh. It just started happening on another blog. Right after I installed AStickyPostOrderer. Once I deactivated that plugin, the query started working again.

The only problem is – I cam not formatting it. I am using this code

$q = posts_per_page=999&orderby=post_date&order=asc&post_type=post&cat=3

and then

$query = new WP_Query;
$wpdb->show_errors();
$posts = $query->query($q);

It works fine on other installs, but on this install it has the error.

Wht the heck is the wp_croer stuff?

I added the line suggested. I get this:

WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘) WHERE 1=1 AND wp_term_taxonomy.taxonomy = ‘category’ AND wp_term_taxonomy.te’ at line 1]

SELECT SQL_CALC_FOUND_ROWS wp_posts.* , wp_croer_posts.post_rank IS NULL AS isnull FROM wp_posts INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) INNER JOIN wp_term_taxonomy ON (wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id) LEFT JOIN wp_croer_posts ON (wp_posts.ID = wp_croer_posts.post_id AND wp_croer_posts.cat_id = ) WHERE 1=1 AND wp_term_taxonomy.taxonomy = 'category' AND wp_term_taxonomy.term_id IN ('3') AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'future' OR wp_posts.post_status = 'draft' OR wp_posts.post_status = 'pending' OR wp_posts.post_status = 'private') GROUP BY wp_posts.ID ORDER BY isnull ASC, wp_croer_posts.post_rank ASC, wp_posts.post_date asc LIMIT 0, 99999

I have no idea what I should be looking for.

I hesitate automatically writing to the database. I’ve had plugins in the past that automatically wrote wp-pages, and in a couple of cases I wound up with duplicates. I wouldn’t want to overwrite an existing page or create a dup if the slug already existed.

I did experiment, and was able to get static pages to work without too much trouble. I simply looked for the slug in the 404.php file, and depending on which slug it is, I include the appropriate page. My worry – that the 404 page would return a 404 error code – was ill founded. Apparently the WP developers decided to return a 200 code since they were trapping the 404 condition anyway.

Advantages – simple, tightly bound, and I was able to use a contact form that looks better (IMO) than most of the plugin contact forms. Plus, as I was coding I realized that if someone just hated my privacy policy or terms or whatever, they could just create a page with the same slug and it would be intercepted before getting to mine.

Disadvantages – not “WordPressy”, not turn-off-able in its present form (e.g. – if someone never wanted to be contacted they would still have to touch the footer code).

So, even though it works out-of-the-box right now, I don’t think it’s the final solution. I probably still need an options page of some sort.

I experienced the same problem when I upgraded from WP2.7 to WP2.8.2. I “solved” it by commenting out line 487. So far, I have not been able to locate the _weak_escape method. I wonder if it even exists…

Bump

I found it! WP_CONTENT_DIR suits my purposes.

Hello?

Where do I actually report a bug to the developers?