MandyWhite

Did this happen with the most recent version of the plug-in? It was updated two days before you made this post. I experienced your problem with the other version but, if I recall correctly, I never tried the themes. If I did try any of them, I’m pretty sure I would not have picked a Flash based theme. I remember I enabled it and it locked up the whole server. Based on the logs, it went into an endless loop of recursion when the first guest attempted to load the site (viewing it as admin didn’t cause the error to trigger). When it was triggered, it locked up the network and made the entire server unavailable until it was reset. However, the issue is no longer occuring with the current plugin version. I just tried the Flash template too, as well as a few others with different settings, and it worked perfectly, without any errors.

Kudos to the developer for fixing the recursion bug. It’s an awesome plugin for a much needed feature. I only wish I knew of plugins like this back when Netsols servers were hacked and exploited via WordPress a few months ago. Having this feature included by default, would have saved 1,000s of sites from continuing to spread the hacker’s worm if only they could have closed their blogs on Netsol’s shared servers during the file clean-up process.

Sorry, I just read your comment re: the index code. If you can post a link to the template file that has the PHP code the writes the target link (not your menu link but the spot the menu link targets, as in the anchor), I can tell you what you need to put in the menu after #. It’s good to check just in case it’s not the permalink. It’s possible that the anchor has id=”problem_page” or id=”problem-page”. The code could be replacing a space in the title with something else. That’s why I wanted you to check the code that write that actual target for the link in your menu. The two words must match for the page to hit the right target when someone clicks it.

You might not be able to see the link with your target but it’s there in the code. At times, it’s wrapped around a title or image. Your menu #TARGETWORD must match the A tag with ID=TARGETWORD. It must be the same word. It’s obviously doing something different, and it’s not the same. You want to duplicate it to match the page’s target A ID=” link. Actually, if you can view source on a page that’s working, open it in norepad, and search the page for the exact same word. Then find the PHP code that writes the A link’s target, and make sure the format and field match.

Sorry.. that didn’t work b/c I used html. It should be a link with ID=”YOURTARGET”

The # link is an achor. It must have a target on the page, and it must match. What’s being put in the target? It’s normally inside YourTagetHitsHere w/in the page.

If I were you, I would just create an alias on the server using either apache config or your htaccess file to map or redirect the path to a different physical directory. Do you have access to either?

WordPress tacks another full domain name w/https:// onto your upload folder? That’s really strange. I imagine some browsers and search engines wouldn’t like that structure, at all.

I looked at the linked post, and it looks nothing like what you posted.

Did you get the code from a Facebook php example for a sample Facebook app? It doesn’t make a whole lot of sense. Normally, for FBML iframes, Facebook provides examples using FBML which looks like a normal HTML page. They then grab the HTML/FBML page and parse the FBML for display on their server. You’re nesting WP php functions inside of FBML & FB php code. You’re not closing open PHP tags before you open another one.

I don’t see any functions that define your WordPress plug-in’s options, nor do I see any hooks into WordPress. There’s no way it can understand “get_option” if you don’t init WP with valid WP code first. There’s no way WP can know your WP options & variables if you haven’t defined them or registered them with WP first. Not sure how you saved any data into WP’s database with the posted script. It appears to be an iframe that’s located on facebook’s server. Are you trying to frame a page within Facebook? I’m sorry but I don’t even understand what you’re trying to do. If you’re trying to frame your blog to appear on FB’s site, then you probably don’t need a WP plugin for that.

Are you adding ‘&paged=’ when you load the next page’s url? If not, try it.

Was the mailchimp plugin intended for a page or your aside bar?

You’re having a problem because every plugin is including it’s own jQuery script. As a result, the browser can’t differentiate between each plugin’s js call. Some of them are using the exact same function name to submit, so nothing gets submitted because there are 5 different versions of the same script telling the browser that submit does something else.

Is the target using your permalink? If yes, don’t use page title after the #. Use your permalink so it matches that target link. If your permalink includes directory names, then simply using the permalink may not work. There’s no way I can know the target so first, you need to figure out how the target name is determined, and then use the same method in your menu link..

Also, if you’re not preloading the next/prev post, the slide effect is going to be lost because a script will have to query the database via http, retrieve the data, parse/format it, and replace the current page’s content AFTER the user clicks next/prev. The user will likely see their cursor spinning as this occurs, and the user may never see the next page if there’s a problem while the script is trying to pull this data together dynamically.

If you’re hoping for your content to be indexed by Google or any Search engine at all, replacing a page’s main content via http, as you’re suggesting, is the worst thing you can do. The method will make it impossible for a search engine to see your page’s content if the content isn’t simply hidden from humans or the content isn’t retrieved/written as the page is reloaded to a new page. The bot will see a blank page because the content will not be hardcoded in the source. It won’t find the next/prev pages either if you pull a post via http and have it magically replace the current page’s center content without creating the physical html. This approach would create an illusion of content, visible by humans only. Sliders preload to enable the smooth sliding effect. There’s no delay if the content exists in hidden form. This preload method allows users who have javascript turned off to still see all of the posts (no slide show but there’s still content), and it allows search engines & screen readers to see all of the content in the category, as well. If you’re not reloading the page by simply clicking “next/prev” to a new page of content and you’re not sliding hidden content into view, then you’re setting yourself up for a whole bunch of issues, like zero content for any visitor who is not using a modern visual browser with javascript and xml http+ajax enabled.

With all this said, don’t be silly — you don’t want what you think you want. There’s a very good reason for why sliders preload & hide/unhide content.

What you’re describing is exactly how a javascript/ajax slider works. The posts are already loaded and the javascript reveals them by sliding the next post into view and hiding the others. It’s honestly the only efficient method if you want it to slide without a page reload.

If you can settle for simple paging, check the twentyten default template, and use their navigation code (at the top of loop.php). It will add next and previous to each page in a category if the prev/next page/post/image/media/etc. exists.

One other thing – As a semi-workaround, try using taxonomy & post type whenever possible. You can then switch those to permalink on your production site, and maintain some sort of word-based structure on your development site. DW can follow dynamic urls. It just can’t follow the url structure of WP permalinks because it can’t logically resolve the location or directories to physical files. It can follow mod_rewrite, that’s done with your .htaccess file. So, basically, if you give it directions and a starting querystring in the url, it can follow the logic behind the url and pull includes. At least, that’s what I’m doing

Yep, I just discovered this too. Funny how not a single person at Adobe support knows about this issue. Their forum mod, a PHP/CS5 DW expert, had me going in circles (making system changes, user profile permission changes, xampp configuration & location changes, etc.) for a full week, right on their forum, before I discovered the real problem. I wanted to reach through my monitor and punch him. I even moved WP to the root of my C: drive as a vhost, at his recommendation, because he thought the nested folders & security within XAMPP may be the problem with why DW couldn’t find includes. I didn’t think that was the problem but I gave it a shot anyways, and ended up spending several days (with little sleep) trying to fix all the Vista & Apache security blocks that I encountered by moving the WP folder outside of XAMPP. On the bright side, I have successfully setup multiple vhosts outside of XAMPP and they are fully functioning WP sites with their own domain names now. However, I went to their forum because DW couldn’t find dynamic includes. It still couldn’t find them after I switched to vhosting. I even made Apache a local user on my pc with full control and access to the file system, so DW could find the includes. Of course, none of these changes were necessary. There was a very simple explanation for DW being unable to resolve dynamic includes — WP permalinks.

BTW, this *just* happened to me on Adobe’s forum. At this point, they should know that DW doesn’t understand/support WP permalinks.