hartley_h

Ah, I didn’t see that because you have to select “All Plugin Options” next to “Plugin Settings to Display” and then save before you can see that option.

Unfortunately, that setting is grayed out in the free version, only being available to those willing to pay $45 for the pro (i.e., non-nag-ware) version. I changed the setting in lib/config.php instead, but of course I’ll have to repeat that every time there is an update.

Yes, the elseif line should also have ==

I think I’ve identified one of two problems with the 2.6 code. There are two places where “Use WP Caption for LBP Caption” affects what happens. One of those works, the other does not (although there are errors in both). If you check “Auto-Lightbox Text Links” then it uses the first instance of code, which seems to work. If “Auto-Lightbox Text Links” is unchecked, it runs the second instance of code which does not work. That’s the work around

As for the bug in the code…

The first set of code works but only accidentally, as it turns out. Don’t know if the plugin author will see this, but on lines 117 and 120 in classes/filters.class.php there are single equal signs (i.e. assignment operator) where there should be double equal signs (equality operator). For instance:

if ($e->next_sibling()->class = 'wp-caption-text') {

should be

if ($e->next_sibling()->class == 'wp-caption-text') {

etc. Since both statements return true but since the second one assigns the proper value (at least for me), the code works but, as I said, only accidentally.

This mistake is repeated on lines 202 and 203. That second set of lines doesn’t seem to work for me, even after fixing that, but I haven’t quite figured out why.

I made some progress here. I do not now think this is a bug in the JW-Player-for-Wordpress plugin. I’m not entirely sure, though.

In jwplayermodule.php starting at line 69 for constants are set: JWPLAYER_PLUGIN_DIR, JWPLAYER_PLUGIN_url, JWPLAYER_FILES_DIR, AND JWPLAYER_FILES_URL. These all are created by concatenating some root directory variable or constant with plugin_basename(dirname(__FILE__)) and that’s where the problem seems to be.

The documentation says:

If your plugin file is located at /home/www/wp-content/plugins/myplugin/myplugin.php, and you call:

$x = plugin_basename(__FILE__);

$x will equal “myplugin/myplugin.php”.

But adding a print statement to jwplayermodule.php shows that it is returning the entire path of the file, not just the last directory and the file name. Naturally that causes problems. I have found a second plugin (Lightbox-Plus) which uses plugin_basename() in the same way and exhibits the same problem.

I have modified jwplayermodule.php so that it works now, but I don’t want to have to do that every time an update is released.

Since this is not a commonly reported problem, I have to assume that the plugin_basename() function is working properly for the vast majority of users. I suspect, but do not know, that the problem I am having is related to the use of the VirtualMultiBlog (VMB https://striderweb.com/nerdaphernalia/features/virtual-multiblog/) configuration along with the fact that I have values set for WP_PLUGIN_DIR, WP_PLUGIN_URL, WP_CONTENT_DIR, and WP_CONTENT_URL on a blog by blog basis.

Can anyone else confirm that plugin_basename() is working in a standard configuration? Can anyone who uses VMB confirm that this plug-in fails when setting those constants? I have posted a question on the VMB site, so perhaps someone there will be able to help.

Sorry to be so long getting back to this. I’ve tried deactivating and then moving all plugins out of the plugins directory (except health-check, of course). No change — there remains no notification on activation of the plugin.

Putting some print statements in the health-check.php file, it appears that in function action_plugins_loaded(), get_transient(‘health-check-version-test’) is returning false so add_action(‘admin_notices’…) is not running. Is that intended?

I have two installations of wordpress on the same machine. One installation hosts a single blog while the other uses Virtual MultiBlog to manage about a dozen blogs. My prior tests were on the multiblog installation. I just upgraded the other installation and the health-check plugin works there. The obvious suspicion, therefore, is that the changes made for virtual multibloging somehow interfere with this plugin. FWIW, I just updated the virtual multiblog additions to the most recent version with no change to the results here.

So, I don’t know for sure that this is the problem and I certainly don’t know what the solution is, but it appears this is a conflict with virtual multiblog.

Correct, like docwhat, I do not see any message under the one that says the plugin has been activated.

My PHP version is 5.1.6 so I know what it should be showing me, in any case. Since CentOS 5 will most likely not get PHP 5.2, I won’t be able to go beyond WP 3.1 until I can upgrade to CentOS 6, which won’t even be released until late this fall or early next year at the earliest. Stable platforms are great unless the software that runs on them moves too much faster than they do. Oh well.

I just updated an installation from 2.0.7 to 2.6.1. Lots of changes to get used to. I’m sure I will but I personally miss the old “save and return to wherever you were” button (which was called simply “save”. I used the “save and continue editing” as well so I’m glad it’s still here (and now called “save”).

My blog is fairly private and I edit published content. I’d nice to be able to click the edit button on the blog page, make the change, save and be taken right back to where I was. It’s not the extra click (on “go back”) that I mind as much as it’s another trip to the server which slows things down.

If there is an option to “save and return to the blog page you were on” and I’ve missed it, please advise.

From my conversation with Sonja:

Sonja Sharp: I have checked your issue and was able to duplicate the issue.
Sonja Sharp: You need to upgrade the WordPress for the account.
Henry Hartley: I will but the underlying issue is a bug in MySQL. I cannot upgrade MySQL, only you can.
Sonja Sharp: The MySQL for the account is upgraded.
Sonja Sharp: You need to just upgrade the WordPress.

At least she was able to duplicate the issue, even if they refuse to do anything about it.

This is a MySQL bug. Although the “System Settings” page on iPowerWeb claims that they are running MySQL Version 5.0.45, they are in fact running 5.0.51a. Until they patch or upgrade their version of MySQL, this will be a problem.

In all likelihood, the solution is to increase the limits in /etc/php.ini from the defaults (post_max_size and upload_max_filesize). If you cannot edit php.ini, you need to add something like this to the upload script (inline-uploading.php, I think) (with whatever values you think appropriate):

ini_set ( “post_max_size”, “16M” )
ini_set ( “upload_max_filesize”, “16M” )

Update: October 7, 2004
The new version (1.2.1) has been released. If you upgrade, even if you follow the instructions, it will break https installations. You need to edit login.php and replace https:// with https:// in two places (lines 153 and 155). Otherwise it will “update” your database with the WRONG form when you log in. It would REALLY be nice if this were a parameter that we could set in wp-config.php.

Now I feel stupid. I saw that link but thought it was to a page I’d read. It wasn’t and it included the solution to my problem. In retrospect, it was obvious that anywhere “https://” was hard coded it would need to be changed to “https://”. I might suggest that in some future version, those pieces be pulled out and put in wp-config.php so that they can be changed in one place. Anyway, things seem to be working now. Thanks.

WordPress 1.2, Apache 2.0, PHP 4.3.8, MySQL 3.23.58, FedoraCore1, https instead of http (in case that matters)
I’ve just experienced this on a new install (using Firefox, Mozilla or IE). I go to the login screen, enter the information and I get redirected back to the login screen. No error message or anything. If I type in an invalid password, same thing. No error message. I register as a new user, that works fine. When I try to log on with that, however, no dice. I look in the wp_user table and the new user is there. I added a print statement to wp-login.php to show me the sql statement created on line 89. I then cut and pasted that and ran it on the mysql command line and it returned the expected record (for both admin and the new user I created).
There’s reference above to “that firefox thing” and “rogue ‘firefox.exe'” problems but I’m not sure what that means. Can someone elaborate?

When you say you checked the configuration file, did you check to see if there were ANY spaces or blank lines after the closing ?> tag? The > at the end of that tag MUST be the final character (including white-space. It’s easy to miss but that’s what your problem is (or there is white-space before the opening <?php at the top. Or you’ve got a print or echo statement in there somewhere.