rgilman

Great!

There may be a simpler way to do it, but the following code works in Widget Logic:
$cartNotEmpty = false; if(edd_get_cart_contents()) $cartNotEmpty = true; return $cartNotEmpty;

edd_get_cart_contents() by itself doesn’t work.

The widget doesn’t show up without a page refresh. Ajax for this would be nice, but I can live with this as is. I mainly want the widget to follow the user if they go to other pages before checkout.

Thanks for your quick reply.

It looks like this fix didn’t get into EDD 1.4.4.3.

Fix works! Thanks for tracking it down! Wonderful!

I tried a clean install of WP 3.5.1 and then added EDD 1.0.1.1 and got the same behavior.

I added EDD 1.4.4.2 to a local MAMP system runing WP 3.4 and got the same behavior.

When it works for you, what OS and version and browser are you using?

What settings do you have in EDD?

Have you tried a clean install of WP and then a fresh add of EDD?

I’d really like to use EDD and I’d like to get this issue cleared before I do more development on setting up my download system.

Thanks for your help (and for creating/maintaining this awesome plugin in the first place!)

Good to hear it is working fine for the others. I’ll be delighted to find out whatever is my particular issue.

The second server was on a different host with a different flavor of linux.

I’m thinking of installing an older version and then upgrading. How far back could I go and still have it work on WP 3.5.1?

I just tried a fresh install of WP 3.5.1 on a second server, Twenty Twelve theme, and EDD 1.4.4.1 as the only active plugin. I get the same result. With EDD active, nothing happens with the fullscreen button (in Visual or Text mode). With it deactivated, the button works.

Every one that I have tested.

I also just ran the activate/deactivate test on Windows 7 with IE via VMFusion. Same result.

Please note that this a development site without public access. If you need access, we can sort that out offline.

——————–

### Begin System Info ###

## Please include this information when posting support requests ##

Multi-site: No

SITE_URL: https://new.context.org
HOME_URL: https://new.context.org

EDD Version: 1.4.4.1
WordPress Version: 3.5.1

Ajax Enabled: Yes
jQuery Validation: No
Guest Checkout Enabled: Yes

Checkout: Valid

Taxes Enabled: No
Local Taxes Only: No
Taxes After Discounts: No

Platform: Apple
Browser Name: Safari
Browser Version: 6.0.2
User Agent String: Mozilla/5.0 (Macintosh; Intel Ma
c OS X 10_8_2) AppleWebKit/536.2
6.17 (KHTML, like Gecko) Version
/6.0.2 Safari/536.26.17

PHP Version: 5.3.3-7+squeeze14
MySQL Version: 5.1.63-0+squeeze1
Web Server Info: Apache/2.2.16 (Debian)

PHP Memory Limit: 256M
PHP Post Max Size: 8M
PHP Time Limit: 30

WP_DEBUG: Disabled

WP Table Prefix: Length: 5 Status: Acceptable

Show On Front: posts
Page On Front: #0
Page For Posts: #0

Session: Enabled
Session Name: PHPSESSID
Cookie Path: /
Save Path: /tmp
Use Cookies: On
Use Only Cookies: On

UPLOAD_MAX_FILESIZE: 2MB
POST_MAX_SIZE: 8MB
WordPress Memory Limit: 40MB
DISPLAY ERRORS: N/A
FSOCKOPEN: Your server supports fsockopen.

ACTIVE PLUGINS:

Easy Digital Downloads: 1.4.4.1

CURRENT THEME:

hybrid-ci:

### End System Info ###

The button is still there but does nothing when clicked. I have tried this in Firefox, Safari and Chrome (all on Mac OX 10.8 on a MacBook Pro and a Mac Pro) with the same result: Activate EDD and the button stops working. Deactivate EDD and the button works again.

I’ve looked in the firebug console and found no reported errors.

I would be happy to attempt any debugging ideas you might suggest.

I noticed it on an ordinary (not Downloads) page. I have tried turning off all other plugins and switching to Twenty Eleven and I still get the same behavior.

I have done some more debugging and think I now have the core problem that was causing Sphinx to fail when wp-config.php was one level up from the site root.

There is a problem in the php in sphinx.conf. This code is modeled on the code in wp-load.php where it looks like this:

/** Define ABSPATH as this file's directory */
define( 'ABSPATH', dirname(__FILE__) . '/' );

error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );

if ( file_exists( ABSPATH . 'wp-config.php') ) {

	/** The config file resides in ABSPATH */
	require_once( ABSPATH . 'wp-config.php' );

} elseif ( file_exists( dirname(ABSPATH) . '/wp-config.php' ) && ! file_exists( dirname(ABSPATH) . '/wp-settings.php' ) ) {

	/** The config file resides one level above ABSPATH but is not part of another install */
	require_once( dirname(ABSPATH) . '/wp-config.php' );

}

In the sphinx.conf template (in wordpress-sphinx-plugin/rep/) the start of the corresponding code looks like this:

#!{path_to_php} -q
<?php
error_reporting(0);
$path_to_config = "{path_to_wp_config_php}";
if ( file_exists( $path_to_config . '/wp-config.php') ) {
...

So ABSPATH gets replaced by $path_to_config. Unfortunately, wp-config.php needs ABSPATH once it is loaded in because at the end of wp-config.php is:

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
	define('ABSPATH', dirname(__FILE__) . '/');

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

If wp-config.php is one level up and ABSPATH hasn’t been defined, then the ‘IF’ defines ABSPATH based on where wp-config.php is. There is no wp-settings.php one level up so the ‘require_once’ fails.

A simple solution that works for me is to add “define(‘ABSPATH’…” to sphinx.conf:

#!{path_to_php} -q
<?php
error_reporting(0);
$path_to_config = "{path_to_wp_config_php}";
define('ABSPATH', $path_to_config . '/');
if ( file_exists( $path_to_config . '/wp-config.php') ) {
...

You could likely make the code tighter by eliminating $path_to_config and using ABSPATH in its place (and adjusting for the trailing ‘/’).

You only need to make this change if you want to put wp-config.php one level up, or want to have the flexibility to do so in the future. It would be good to make the change in the template (wordpress-sphinx-plugin/rep/). If you have already activated the plugin and run the wizard, you should also find sphinx.conf in your sphinx directory (likely in uploads) and make the change there.

BTW, for debugging this issue it was a great help to turn on the error_reporting used in wp-load.php. I then ran a sphinx command from the command line and got a lot more helpful information than just ‘error executing ‘/usr/bin/php -q’ status = 255 in /home/…/sphinx/sphinx.conf line 1 col 1′.

Hope this helps

Good news. I have Sphinx working on the mirror site. I had put wp-config.php one level up (for security reasons) on the mirror but not on the main site. My WP install is at the site root, so that meant that wp-config.php was above/outside the site root and it seems that apache/php wouldn’t read the file (at least not through sphinx.conf).

With wp-config.php back down at the site root with 640 permissions and the apache user as part of the group, it works.

The fact that the error cites line 1 col 1 wasn’t helpful in my case. I had no problem with the path to php or the form of the #!/usr/bin/php -q. These are certainly worth checking, but from my experience you also need to check that apache/php can actually read wp-config.php.

I would love to know a modification that could be made to sphinx.conf (or whatever the solutions) that would allow wp-config.php to be placed above the site root. WordPress manages to read the file when it is above the site root, so there must be a way.

Hope my experience can be helpful to others.