RobIrizarry

Thank you!

@rohitink – Good article (How To Add Wp-PageNavi To WordPress Twenty Eleven) if you’re editing the parent theme and not creating a child theme. Otherwise, you need to Zeak’s method or you need to override the original theme function as I mention above.

One other thing – In your article, you state if you “wish to Stylize the Plugin you need to Edit Plugin Files”. That’s actually not the case. You can style them in style.css after disabling ‘Use pagenavi-css.css’ in the plugin’s settings. Here’s example CSS from one of my blogs where I do just this:

.wp-pagenavi a, .wp-pagenavi a:link, .wp-pagenavi a:active{padding:2px 4px 2px 4px; font-size:12px; margin:2px; text-decoration:none; border:1px solid #666; color:#000; background-color:#fff}
.wp-pagenavi a:hover{border:1px solid #A90000; font-size:12px; color:#000; background-color:#FFF7D3}
.wp-pagenavi span.pages{padding:2px 4px 2px 4px; font-size:12px; margin:2px 2px 2px 2px; border:1px solid #CCC; color:#666; background-color:#FFF}
.wp-pagenavi span.current{padding:2px 4px 2px 4px; font-size:12px; margin:2px; font-weight:bold; border:1px solid #A90000; color:#666; background-color:#FFF7D3}
.wp-pagenavi span.extend{padding:2px 4px 2px 4px; font-size:12px; margin:2px; border:1px solid #FFF; color:#666; background-color:#FFF}

@zeaks – Thanks! Good stuff. You avoided the issue by simply calling a different function name.

The alternative would be to override the existing function with your own. That way you don’t need an index.php in your child theme just for this. This article does a good job of going over the steps – The Right Way to Override Theme Functions.

Thanks for the feedback.

The two jobs were different in size due to the size of the environments. The smaller zip was on a test environment with only a handful of images. The larger zip was on a prod environment with gobs of images and a number of pdfs. Despite the greater size of the prod environment, the plugin log files indicate that the 1.7.7 version blew through the entire process in less than 1/2 the time.

I’ll pull down the latest plugin version, test again and provide feedback.

Thanks again.

For comparison, I ran a similar job for a different site on the same virtual private server. This site runs WP 3.1.3 and BackWPup ver 1.7.7. The backup contained 3690 files, resulted in an archive of 128mb (vs. only 21mb for the run performed above with the development version) and took 126 (vs. 385) seconds as per the job’s log files. This job barely blipped the cpu which bounced between 20-30% during its run.

That’s dramatically better than the development version’s results indicated above.

The development version worked like a charm. Thank you!

Thank you – I wasn’t aware of a development branch. I’ll give it a try.

Issue resolved, for me at least, by removing the following block from .htaccess which had been introduced to clean up URLs. This same block was preventing Adminer and BackWPUp from working.

#Redirect parameter filled URLs to clean ones
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} .
RewriteCond %{QUERY_STRING} !^(s|p)=.*
RewriteCond %{REQUEST_URI} !.*wp-admin.*
RewriteRule ^(.*)$ /$1? [R=301,L]
</IfModule>

Also experiencing this error although right from the beginning. Looking for guidance…

Tracked the issue down – A conflict with the Maintenance Mode plugin being active. Works perfectly. Thank you!

Issue solved – Maintenance Mode plugin prevented it from kicking off.

Confirming some of the behavior Alkahest is seeing with the Headspace2 3.6.32 – specifically the inability to change Status and Visibility.

I found that disabling the Tags module from Headspace’s Page Modules settings, corrects this. I would suggest going through the modules screens and disabling anything you don’t actually use. At this point, I’m only using the Page Title and Page Description Modules and have not encountered any other issues.

Perfect! Working fine in 3.0alpha. Thanks so much.