pp19dd

I think your problem is the way you’re implementing the function. You’re returning an object, not a string. It should probably go something like:

//display file needs to be the style variable from admin panel
	//$smarty->display("list.html");

	// Return NOT echo:
//return $smarty;
	return( $smarty->fetch("list.html") );
}

Since this post was on my follow-up list: for the impatient and irritated evil admins out there, check out https://www.ads-software.com/support/topic/278691?replies=13#post-1339235

For some reason I’ve never been able to make this upgrade feature work either. Once, I think, it worked flawlessly for me. Every other time- I’d get a nice little error that would go something like:
Could not copy file: /blah/wp-content/upgrade/wordpress-2.tmp/wordpress/wp-comments-post.php
I’ve tried all the standard tricks; recreating wp-content/upgrade and setting permissions, etc. It would be nice to have this upgrader say why exactly it failed (aren’t detailed error messages actually helpful?)

Anyhow, this trick worked for me. I ssh’d in and ran this (totally cheating, I know):

watch -n0.1 "chmod a+rwx -R /blah/wp-content/upgrade/"

Then I initiated the upgrade and — the upgrade actually worked. It seems like the ftp method of uploading forgets, inadvertently resets, or otherwise assumes way too much in ways of permissions.

DISCLAIMER: don’t follow this trick unless you know what you’re doing. Seriously. This resets all permissions recursively every 0.1 seconds.

All of the previous automatic upgrades worked for me, but this one failed for me as well. This is hosted on a Linux machine and I’m not exactly a dummy. All file permissions checked out. It would help if this thing would say *why* it couldn’t copy a file.

Downloading update from https://www.ads-software.com/wordpress-2.8.3.zip.

Unpacking the update.

Could not copy file:
/wp-content/upgrade/wordpress-2.8.3/wordpress/wp-comments-post.php

Installation Failed

Edit: I spoke too soon. Had to reset permissions manually for the upgrade to work. Security experts, don’t cringe, but this worked for me:

chmod a+rwx -R wp-content

The error message should’ve said “I can’t copy the preceding ZIP file and unzip it, not the file I was meant to copy first on the list, sorry!”

Also, oddly enough, the upgrade process froze on its output side – it seems to have upgraded but forgot to tell me it was done. The browser is still churning without displaying anything.

Edit #2: the above ‘frozen’ process actually finished. Took an epic 10 minute period, but, it announced that the upgrade worked fine.

orbitingsolutions: See https://core.trac.www.ads-software.com/ticket/9864

“Workaround to improve performance:

– comment out line 273 in wp-admin\edit-page-form.php and skip displaying the page parent in the edit screen”

That line number might have referenced 2.7, so, read up on that ticket.

And with further annoyance from me, this appears to be a recognized bug:

ticket # 8632

A fix is scheduled for version 2.8.

On second thought, this does seem to be a bug, if you ignore the public-facing search and focus on the CMS side. To reproduce it: create many subcategories, enough to force pagination. Here is my basic example:

College
– Arundel Community College
– Salisbury University
– .. 30 more colleges
– .. 40 more universities

If you search for a term that would show BOTH parent and subcategories (college), everything shows up fine.

However, if you search for a term that would only force a list of subcategories to show without the parent (such as “university“), the display doesn’t work and shows up with blanks.

I looked through the code and found lines 64-65 in wp-admin/includes/template.php:

if ( $category->parent != $parent )
			continue;

Disabling that snippet makes all of the results appear (albeit in very disorganized fashion). Pagination appears to always be wrong, showing 23 pages regardless of search granularity.

I’ve tested this with:

WordPress 2.7.1.
PHP 5.2.5 / MySQL 5.0.45-community-nt
PHP 5.2.8 / MySQL 5.0.67-community

I have also run into this situation. It appears to be a feature, rather than a defect; however, it is unexplained in documentation. I would like to find either some explanation -or- configuration options to change this behavior. It seems to be part of a search routine because main site search behaves that way.

For example, I have four categories – but – hundreds of subcategories. If I search for “sports”, the main category “/sports/” shows up in search listings; however, if I search for “baseball”, the subcategory “/sports/baseball/” does not. This behavior is identical in the CMS.

I don’t think this is all that unusual – however – we appear to be the rare users of subcategories. Would appreciate anyone shedding light on this.