jason_lane

Dan,

I encountered what appears to be the same problem; on my sites (a dev site on my local machine, and a live site) the plugin wasn’t switching to the desktop version when the switcher link was clicked. I think I narrowed it down to 2 things:

1. When the plugin sets a cookie to indicate the preference to view the desktop site, the cookie data wasn’t being set properly. I had a look in the plugin code, and I can see that the last parameter of the setcookie() function is trying to set the correct domain name for the cookie (on line 964 of mobile-smart.php). However, on my two sites, the domain that was being set was invalid, for 2 different reasons:

a) The plugin tries to strip ‘https://www’ from the front of the blog’s home url, to leave a bare domain (eg. example.com). However, I usually use naked domains on my sites, so there’s no ‘www’ in the blog url, and therefor the plugin code doesn’t strip the ‘http’ part from the url (eg. https://example.com). I don’t believe that’s a valid domain for a cookie.

b) My dev site uses a multisite WP install, with subfolders. So the blog url would be something like ‘https://example.com/blogname/’ AFAIK, the domain paramater for setcookie() must be just the domain part, without subfolders.

For me, the easy fix was to just remove the whole domain parameter from the setcookie() function call. I’m not an expert with cookies, but from what I can tell, the domain parameter is optional, and if it’s left out, the current domain is assumed. So, by simply removing the domain parameter, the theme switching link seems to be working on my sites. Or at least, except for issue number 2….

2. I’m not completely sure about this one, as I haven’t had time to have a proper dig into the code, but the issue is that the plugin doesn’t switch themes after the first click of the switcher link. The theme only switches after I do a refresh or navigate elsewhere. The mobile theme in this case is a child theme of the desktop theme. You mentioned some people have reported problems with child themes, and I think this might be the same issue. I’ve had a look at the code, but I’ve found some strange things that appear to be going on, and I’d need more time to figure this one out.

Dave, I still disagree with you that the Codex is actually wrong here. At best, you could say that it is presenting one (commonly) recommended way of doing things.

A closing PHP tag, while perhaps not completely necessary, is pretty much universally suggested. In strict programming terms, an opening tag should always have a matching closing tag. PHP is not always so strict, and leaving off the closing tag will probably still work in most cases, but a lot of programmers, such as myself, just don’t like the idea of having unbalanced tags.

Also, FWIW, a closing PHP tag used correctly should never break your site. I have a Twenty Eleven child theme working with a closing tag in my functions.php file (as I do on all of my functions.php files). Did you already check that you had no white space after your closing tag?

Thanks for clarifying. I guess it’s not actually needed, but just the recommended way to do it, as pretty much every PHP tutorial I’ve seen would tell you. Anyway, I’m sure we agree that the Codex isn’t wrong to say this, and most likely the OP had something after the closing tag that was causing the error.

The Codex isn’t wrong. There should be closing PHP tag at the end of the file. Furthermore, that closing tag has to be the very last line of the file. If you have any blank lines after the closing tag, that can break things, too.

Sorry, I haven’t used any of the tabbed content plugins myself, so I can’t give you any recommendation or any more specific instructions.

Tony, what I would suggest at this point is to first get the tabs working without icons. There’s a fair bit involved in properly implementing tabbed content (eg. Javascript stuff). You said you’ve tried a bunch of plugins, and I assume you meant plugins for adding tabs to posts/pages (there are several). You should choose one that you like, and that will give you the underlying tab functionality that you want. Preferably choose one that allows you to insert custom CSS, although it’s not totally necessary. Once you have the page setup with your tabbed content, you can then add the icons fairly easily with CSS (either through the plugin or as you’ve already done above). Assuming that the tabs have a CSS class of “tab” and if a particular tab has an ID of “tab_baseball” (hopefully the plugin allows you to specify an ID), then a simple example of CSS could look like:

.tab {
   padding-left: 32px; // This will apply to all tabs with class of "tab"
}

#tab_baseball {
   background: url('path/to/icon.png') 0 0 no-repeat;
}

There are more advanced ways to do this with CSS, but that’s a simple example that should work.

Kenia, it could be a Javascript issue, and it could be that one of your Firefox plugins is somehow conflicting with the Mailchimp form. You could try using Firebug to try to debug the problem.

It’s definitely possible, but how easy it would be might depend on several factors.

Firstly, are you trying to do this without modifying or adding any code to the theme or plugins? ie. Are you purely a “user” or are you capable of doing some coding yourself? If you can’t find a plugin or theme that does what you want, then you’re gonna have to write some code or get somebody to do it for you.

If you want a starting point, I’d say that what you want is probably some CSS to add the icons to the tabs. This is assuming that you’ve at least successfully got the tabs to work. Adding icons to tabs would be very easy for most web developers (Hint: CSS background property). But then there’s the added complexity of how to choose which icons go onto which tab. Are these icons going to be pretty much fixed, or do you want the icons to be selected by the user when editing the content?

There are a lot more questions I could ask, but really what I’m saying is that in order to give you a better answer, I’d need to know a lot more detail about what exactly you want to accomplish, and what your skill level is.

Hope this helps a little.

Or could it just be that this particular plugin was using wp_tiny_mce() incorrectly in the first place, but in such a way that (by pure luck) it still managed to work?

Ipstenu, no, I didn’t have debugging turned on. Tried again now with debugging on, and it does indeed give the deprecated warning.

Any insight into why the two functions behave so differently? Seems to me that any plugins using wp_tiny_mce() may encounter the same issue in 3.3

P3air, I just tried the WooCommerce plugin for the first time today, and I was able to get a functioning store up and running without the need for any of the Woo themes or paid addons. It seems to have a good amount of functionality built in. What, in particular, do you find lacking from the core plugin? I’m not asking rhetorically, BTW. I’m eager to hear your experiences, as they may influence my decision to use the plugin. I’ve only done very preliminary testing so far.

joatblog (Kenia?), it seemed to work fine for me. I got the success message on the screen, and received the confirmation email. What browser were you using? I was using Chrome on OSX.

Cool blog concept, BTW!

Yeah, it does seem odd. I haven’t had time to really dig into the code, but it seems to me that the older wp_tiny_mce() function worked more like a “preloader” in that it would queue and/or load certain files needed by the editor, but not actually initialize the editor. The plugin would then initialize it later on, conditionally.

Evidently, the wp_editor() function works very differently. It may seem wrong to replace a deprecated function by one that works so differently, but I believe wp_tiny_mce() was never a documented function, and therefore not subject to the same expectations?

The plugin is using a regex to modify the links produced by wp_list_pages(). Part of the regex pattern looks for title="([^\"]+)" however in WP 3.3b2 the title attribute has been left out of the links (in the Walker_Page class), and therefore the plugin’s regex is not able to match.

Is the omission of the title attribute intentional in 3.3b2?

I can confirm the issue, and I had a look at the plugin’s code. It is calling wp_tiny_mce(), which has apparently been deprecated in 3.3b (in favor of wp_editor(), which seems to work quite differently). The plugin writer(s) will need to rewrite the plugin for 3.3 compatibility.