1.5 and Plugins that create admin pages

[ZappoMan]

I am trying to get a bunch of plugins that used to work just fine, to work in 1.5.1...

These plugins all have a common characteristic that they create admin pages (most of them create submenus)... anyway... mu1.5 seems to not want to render these pages.

I found a link on the codex that said that if your plugin followed the instructions here:

http://codex.wordpress.org/Adding_Administration_Menus

That they should work in 2.5... but alas... I copied the sample code from the codex and it fails in the same way.

Has anyone else already solved this?

I can't possibly be the only one to see this...

[Luke]

Nope, you're not.

But it isn't the code for the menu, I believe. Can I take a stab that these are mu-plugins?


If so, it has something to do with how the files are read in now, and at times certain files just don't get parsed.

I couldn't tell you why, but I had a couple files that were loaded if a check for wp-admin was true. One worked, the other two did not. In testing, I put all three if checks under one, in one file.

Worked a snap from there.

Needless to say, you're not alone on this one. It's happened quite a lot, although many folks don't realize it.

[ZappoMan]

Interesting...

Yes, these are mu-plugins...

I am pretty certain the plugins are loaded and parsed... if I put "die('yo!');" in the files at various locations I am seeing control flow reach that point.

But I did notice that it appeared as if the the pagehook names didn't seem to match up correctly in the code that loads the menu and the code that handles the menu item. That's why I suspect it's related to menus.

I am glad to hear others are seeing this too... clearly it needs to be fixed for me to be able to upgrade. DAMN, and I was hoping it would be painless! Silly me.

[Luke]

Can you try something, since this is a test install?

In 1.3, find where it loads the files from mu-plugins, it's in wp-settings I think.

Copy that, and replace what's in 1.5 (should be about the same spot).

See if it makes a difference. It did for me when I was testing, and seeing similar symptoms.

Then again, it may not help and could be another issue, but if that is the case then a ton of plugins wouldn't be working across all kinds of installations.

[ZappoMan]

I am making some progress on this...it's definitley related to menus, plugins, and hooks...

Also, I just realized that one of my problems is related to some HACKS I made to remap the admin URLS to something other than wp-admin.

I'm an idiot to have forgotten about that. I was using an unhacked version of wpmu but my .htaccess was redirecting /wp-admin/ to /home/ and there are lots of places where wpmu depends on the URL being /wp-admin/

At least some of my problems relates to this.

I'll let you know what I figure out onced I've learned more about it.

I really want to get to the latest code... and I want to reduce the number of core hacks I have (hopefully to zero!).

[ZappoMan]

So... it looks like I have admin pages working now in 1.5

It seems as if my main issue was related to remapping /wp-admin/.

Now I need to go back and clean up all my debugging randomness and see if I can rebuild this cleanly.

[Luke]

Wow... I could spit off hundreds of backwoods trailer jokes about right now...



FYI though: Keep note of the info above, as it is a problem on occasion. And one that will make you chase your ass for hours on end, too.

[ZappoMan]

On the backwoods trailer note:

Bring it on... I love a good trailer trash joke. My grandparents on both sides were share-croppers and coal mine workers... I've slept my share of nights in "shacks" and trailers.

On the technical note:

Well in the process of debugging this, I've definitely noticed that the menu code has changed significantly (partly to do the fancy 3 part menus, and partly due to what appears to be general code refactoring)

I can certainly see where plugins that abused the menu globals will get wigged out by the new code.

In fact, I was also playing around with the "planetozh" Admin Drop Down Menus, which are pretty slick in my opinion, and that code appears to have bugs in handling of mu-plugin based pages. They were fixed when I fixed the code to do wp-admin remapping.

[Luke]

On the backwoods trailer note:

Bring it on... I love a good trailer trash joke. My grandparents on both sides were share-croppers and coal mine workers... I've slept my share of nights in "shacks" and trailers.

Well you don't have to take all the fun out of it... :{



On the dropdown note, I didn't like that plugin, really. I can't recall what it was specifically though.

I had been using the one from Yellow Swordfish, heavily modified, but nothing like it out there now. Even the updated one there is all goofy. At least to me. We'll see how long I can tolerate 2.5 without it. My guess... not too long at all.

[ron_r]

I've been writing and/or modifying plugins for MU. If the plugin has any amount of code for the backend, I add a check for wp-admin and only reference the backend code if the check is true. The same can be done with extensive frontend code.

[Luke]

As long as you break it out into multiple files, of course, and only load what you need when you need it.

[ZappoMan]

Yes, I do this for all my my plugins...

Note: I use a custom mu-plugin loader (plugin) that supports loading files from subdirectories, and does something similar to plugins where it only loads php files with Plugin Name:, and it has a cached list of those files... so assume that layer exists.

My design pattern is for minimal loading is...

wp-content/mu-plugins/myplugin/myplugin-min.php -- This file contains the "Plugin Name:" comment and the bare minimum code necessary to call add_filter() or add_hook() etc... filter call back functions are stubs that are usually about 3 lines long and do an include_once() of the actual implementation file, and a call to the actual implementation function. Sometimes they get routed through a singleton object that implements the functionality as a class, so that "global variables" are nicely contained.

wp-content/mu-plugins/myplugin/myplugin.php -- This is the full implementation of the guts of the plugin. But it doesn't contain "Plugin Name:" at the top of the file so it doesn't get automatically included.

Inside of myplugin-min.php I will sometimes check for is_admin() and then include a third file myplugin-admin.php that will include implementations for admin specific features.

By using is_admin() I can avoid caring about the URL/PATH...

My changes to remap /wp-admin/ to /home/ are actually pretty small. They mostly occur in wp-admin/menu-header.php and wp-includes/vars.php. Although many plugins will often reference the /wp-admin/ url directly... If I totally wanted to hide /wp-admin/ from the user I'd need to change all those as well... I don't plan to do that in my 1.5.x code drop.

[Luke]

I've always been of the mind that wp-admin, wp-content, and wp-includes should be constants defined in the config file.

Not that security through obscurity is good, but ever little bit helps.

The more you can hide from the kiddies, the better.

[drmike]

Agreed.  Ditto on displaying version number as a nono.

I just want to get rid of the 'wp-' bit.  I just know that's how some folks find our (few remaining) installs of wp.  Some of them are getting hit very hard by kiddie scripters looking for recent security problems.  Lots of fun.

You wouldn't believe all the spam we're still seeing with that security problem with the upload directory  that got fixed a few versions ago.

[Luke]

The bad thing, and potentially one reason that may be used to keep from something like that is plugins.

How many out there hard code paths?