Permalinks affecting beta plugin

[imported_Ryan]

I’ve bumped my Sitepoint topic in the hope of someone being able to help … http://www.sitepoint.com/forums/showthread.php?t=546624

And I’ve created a demo of the problem in action … https://geek.hellyer.kiwi/demo/test/temp/wpd … nbug1.html

It works fine with my own style.php file, but not at all with RobRush’s.

EDIT: I’ve opened a support topic on the WordPress.org forums about it now too … http://wordpress.org/support/topic/175052?replies=1

[imported_Ryan]

[quote:2hah5yp9]Then found however that the support for suckerfish2() and beyond was missing[/quote:2hah5yp9]

I’ve added these old functions back in as requested. I haven’t tested them though so let me know if they don’t work for some reason.

https://geek.hellyer.kiwi/forum/index.php?to … 799#msg799

[imported_Ryan]

Have any of you been having this permalinks/style.php issue with the stable version of the plugin? If it is affecting one, it should (in theory) be affecting the beta plugin as well as the style.php file for both versions is identical.

[kmruss]

Ryan, after thinking about this for a minute, YES – I DID have the problem with 1.64 – ONLY after I changed from the regular permalink style to NUMERIC permalinks (which was required by podcaster plugin for stats tracking).  The MAIN reason I swapped to 2.2 beta was your new admin suckerfish cp option to DISABLE the admin cp CSS – and use your own in your theme’s own stylesheet (style.css).  I found out about the problem and solution (and the new option to disable admin cp CSS) in this thread ironically.

Once I used that option to disable admin cp CSS – I just copied and pasted the CSS into my theme’s style.css – and it worked again (just like from 1.64 BEFORE I changed the permalink style to numeric).

Thanks for all your following up – hopefully we’ll hear something from one of those forums.

As requested, here is my post of information from what we discussed via the contact option about who my webhost is and the problem with permalinks in the beta – thanks:

[quote:16ji2xpw]
My webhost is 1&1 – very pleased with them.  I have my own
computer consulting business email/website through them too – as well
as several clients.

I’ll be glad to work with you and help ‘testing/debugging’ on this problem.

Also, how I have the pages on our website with your plugin:  We create a ‘main page’ in WordPress – then create an additional page and put that as the ‘Page Parent’ under options for that page in WP.  Example:  Media .. then ‘Audio Gallery/Podcasts’ has it’s parent page set to ‘Media’.

This allows them to be under the different top-level sections (About
Us, Media, etc.) that we set.

Maybe you can tell me a better way to do this – as this was a quick
implementation that worked and we just stuck with it.

The only problem/complaint I have is that those ‘top-level’ pages
(like Media, About Us) actually link to a page – so we went in an
added ADDITIONAL links to the sub-pages under that.  Just click one
and you’ll see what I main.  Ideally, probably doesn’t need to do
that.  Most drop-down menus I’ve seen just let you HIGHLIGHT ‘Media’
.. and click whatever sub-menu is underneath.
[/quote:16ji2xpw]

And your reply (from Ryan):
[quote:16ji2xpw]
You definitely have the exact same problem the others are having. This is very strange. I’ll bug a few experts to see if they can figure out what the cause is as I am totally stumped – I don’t understand it at all.

There is no way to design an automated WordPress plugin which doesn’t link to pages via the top menu items – or at least not without serious difficulty. This problem is related to the fundamental way the WordPress pagination system works. There is an easy solution as long as you don’t mind hard coding your menu into place. Hard coding your menu is not a problem if you aren’t intending to change it very often.

To hard code your menu, just view the source for your page, then copy and paste everything from <ul id="suckerfishnav"> through to </ul> and dump that into the "Custom Code" box in the admin panel of the plugin. Remove any of the URL’s in the links from the menu items you don’t want to be clickable. Don’t remove the link, just the URL in the link. The links themselves need to remain or the menu will break.
[/quote:16ji2xpw]

Also – you mentioned in a further reply that you have apparently provided support for the original suckerfish2() option in a new option in the latest Suckerfish’ admin CP.  Suckerfish2(), which is what we use, is where it takes the PAGES and PAGE CHILDREN (where you set a page to have a page parent .. Media (top-level) > Audio Sermons (page set w-‘Page Parent’ being ‘Media’) > Video Sermons (page set w-‘Page Parent’ being ‘Media’).

Apparently this has to be true – it just looked confusing in the admin cp since it said ‘menu 1’ .. ‘menu 2’ .. so I was thinking it was talking about just the first top-level dropdown .. then the second .. etc.

I’ll post back and say for sure whether this works for us exactly like it did with the other – sounds like it will.

I can see why you provided the option to put the Suckerfish CSS through the admin CP – since it will keep your CSS style even when changing between different themes (don’t have to add CSS to EVERY theme).  So hopefully we can get it figured out.

Thanks – Kevin

[kmruss]

Ryan – one more thing.  I tried your ‘DEMO’ of the BUG above.  Don’t know if this might be something .. but I can DOWNLOAD (right-click and Save Target As) on your FIRST style.php.  The second one (that shows the ‘bug’ and doesn’t work) … I can not download.

It says something like ‘Internet Explorer can not download the file from http://www.routinefly.com&#8217; .. etc.

Is this possibly a weird permissions issue I wonder?

[imported_Ryan]

&quot;kmruss&quot; wrote:

I can DOWNLOAD (right-click and Save Target As) on your FIRST style.php.  The second one (that shows the ‘bug’ and doesn’t work) … I can not download.

Excellent! That may be a very useful thing to know for tracking the bug. I have no idea why that would occur. Particularly since you can download it fine in Firefox 2. Interestingly, you can’t view it in IE7 either, whereas you can in IE7 – very bizarre!

[kmruss]

Yeah – seemed very strange to me.  I assume you meant can’t view in IE7 (which I’m using) – and can view in IE6?

Yes – just confirmed what you said about Firefox (from same connection/ISP).  I can download BOTH CSS (with .PHP extensions) just fine with Firefox 2 – but not with IE7 from the second link (routinefly).  Odd though, since BOTH links seem the same (CSS style sheet with .PHP extension).

Question: What’s our reason for pushing the style sheet as PHP?  Or does the PHP just execute and return it as the CSS?  We should probably look at how it was done in versions earlier than 1.64 – as I don’t think we had a problem then.  HOWEVER, I didn’t try changing permalinks styles with earlier versions.

The saga continues … I’ll let you know if I get more time to try and debug tomorrow.  If you’d like, I can try one of your earlier versions on our webhost – with NUMERIC permalinks – and see if the same bug with IE7 exists?  I have versions 1.0.5 and 1.1.4 beta available here that I can try with?

Just noticed something from looking at those early versions:  Looks like those stylesheets were called directly from the main PHP file (ryans_suckerfish.php) – and not a secondary php file (style.php). 

Could you try creating a ‘test’ version and call it again from the main file – and see if it still has the problem?  It may be some sort of ‘secondary’ file calling that’s throwing it off somehow – and somehow with the combination of NUMERIC permalinks?

Kevin

[imported_Ryan]

[quote:1brbt5mg]Question: What’s our reason for pushing the style sheet as PHP?  [/quote:1brbt5mg]

That’s because the PHP is being pulled from your WordPress database and I need to use PHP to do that. I could save it as a file, but then that requires changing the file permissions for the plugin directory which is just as complicated as telling people to use a separate style sheet.

[quote:1brbt5mg]Or does the PHP just execute and return it as the CSS? [/quote:1brbt5mg]
Yep.

[quote:1brbt5mg]We should probably look at how it was done in versions earlier than 1.64 – as I don’t think we had a problem then.  HOWEVER, I didn’t try changing permalinks styles with earlier versions.[/quote:1brbt5mg]

I can’t remember the exact point at which I changed to a PHP file for the CSS file, but the earlier versions required users to add the CSS manually to a .CSS file. I’m trying to avoid that route to make it easier on noob users. I received a lot of questions from people when I initially released the plugin for this reason.

[quote:1brbt5mg]The saga continues … I’ll let you know if I get more time to try and debug tomorrow.  If you’d like, I can try one of your earlier versions on our webhost – with NUMERIC permalinks – and see if the same bug with IE7 exists?  I have versions 1.0.5 and 1.1.4 beta available here that I can try with?[/quote:1brbt5mg]

That would be extremely helpful! I’ll hunt out some links to likely candidates for you to try. There’s about 50 different versions (including a whole fleet of betas).

[quote:1brbt5mg]Just noticed something from looking at those early versions:  Looks like those stylesheets were called directly from the main PHP file (ryans_suckerfish.php) – and not a secondary php file (style.php). [/quote:1brbt5mg]

As a CSS file though, not from the database.

[quote:1brbt5mg]Could you try creating a ‘test’ version and call it again from the main file – and see if it still has the problem?  It may be some sort of ‘secondary’ file calling that’s throwing it off somehow – and somehow with the combination of NUMERIC permalinks?[/quote:1brbt5mg]

That would have the same affect as using the ‘disable CSS’ option in the admin panel, but wouldn’t have a link to a static CSS file.

[imported_Ryan]

Actually … I take it back. I forgot that a series of the plugins actually fed the PHP directly into <style> tags between the <head> tags. That would likely the solve the problem and could be a good bug fix for users who have trouble.

If I can’t sort a proper solution, I could provide an option in the admin panel for users who find the menu just displays a plain list.

[imported_Ryan]

The most recent version of the plugin which doesn’t use a style.php file is this one … https://ryan.hellyer.kiwi/wp-content/uploa … 5_beta.zip

[kmruss]

Great Ryan – let me get some business stuff out of the way here and I’ll try to test that shortly.

[imported_Ryan]

kmruss – Could you try testing the following style.php code for me? Someone suggested ‘clearing my headers’ first, I have no idea what that means, but got me thinking that maybe something was ary with the way I was setting the headers, so I switched it so that the first thing in the file is the header statement.

[code:cwwu44id]<?php
header(‘Content-type: text/css’);
require(‘../../../wp-blog-header.php’);

echo ‘/*
  CSS generated via the Suckerfish WordPress Plugin ... http://ryanhellyer.net/2008/01/14/suckerfish-wordpress-plugin/

  If you would like a similar dropdown for your own site, then please contact Ryan Hellyer for
  information about getting your own custom designed dropdown menu ... http://ryanhellyer.net/contact/
*/

‘;
echo get_option(‘suckerfish_css’);
?>[/code:cwwu44id]

[kmruss]

Hey Ryan –

Okay – unfortunately that didn’t make a difference.  However, I BELIEVE I know what is causing it now – and just trying to find a way to fix it:

I tested one more time to make sure it was the ‘NUMERIC’ option on the permalinks for WP that was causing the problem.  Sure enough, once I swapped back to ‘default’ regular permalink styles in WP admin (?p=123), the CSS is parsed correctly from the WP admin menu via Suckerfish options.

EDIT: As soon as I swap back to Numeric Permalink Styles (/archive/123), it fails to get parsed at all through both IE7 and Firefox2 (believing all browsers) (strike this: through IE7) – and I believe I know why:

How’s this for interesting: It has something to do with the permalink structure – and it re-writing the URL for ONLY files in the WordPress ROOT folder (which is the same format as it’s ‘/archive/123’).  Any files past root in sub-folders seem fine.

Here is how I know this:  I tried to access the file you call (or require): http://mysite.com/wp-blog-header.php

Got a 404 error in IE7.  Switched permalink styles back to the default (?p=123) and it pulls it fine.  Ironically, I try it via Firefox 2, I seem to parse the wp-blog-header.php fine (blank window) – however, the suckerfish menus don’t display correctly in either IE7 or Firefox2 (CSS from WP Suckerfish Admin CP not parsed).

I believe this MAY be affecting those of us who set our WEBHOST ROOT folder to the WORDPRESS ROOT.  For example:  http://mysite.com/wp-blog-header.php … instead of http://mysite.com/wordpress/wp-blog-header.php – however I’ve not fully confirmed this yet.

Here is where I had to leave off:  You may want to play around with the type of ‘required’ calls that WordPress Devs have done in the wp-blog-header file.  I believe there is something in the way that WordPress Devs call the files – DUE to working around permalink styles.  I tried several of these but couldn’t get them to work – but will try more later:

Examples:
[code:2m1kcgug]
require_once( dirname(__FILE__) . ‘/wp-config.php’);

if ( !file_exists( dirname(__FILE__) . ‘/wp-config.php’) ) {
[/code:2m1kcgug]

Kevin

[imported_Ryan]

Wow! Thanks Kevin. I hadn’t even thought of it being that problem.

I owe you big time ” title=”Smiley” /> Let me know if there is anything I can do in return.

In the mean time I’ll see what extra information/solutions I can find.

[imported_Ryan]

kmruss – What are the file permissions on your wp-blog-header.php file? Mine are set to 0644. I’m wondering if perhaps the file permissions are preventing the style.php file from accessing it.

[Author]

Posts