wpweaver
Forum Replies Created
-
No, wp_cache_mobile_group does not do what needs to be done. One could add whatever names one wanted, but from how I read the code, that function is driven from $_SERVER[ “HTTP_USER_AGENT” ]. The problem is that for any given user agent value, there will be TWO different views. So it is not possible to create two different caches for a single instance of a mobile device browser – assuming I am reading this line:
return $cache_key . ‘-‘ . wp_cache_mobile_group( $user_agent );
correctly. $user_agent, as far as I can tell, comes only from the HTTP_USER_AGENT value.Instead of using the concept of adding more groups to the list of cached user agent determined browsers to create new caches, it would be very useful to have the opposite – don’t use the cache. Sort of kills the purpose of caching, but at least the sites would display correctly.
That is not what the theme want or needs to do.
It does not, nor should it need to, have a separate .html file for each view. That is not how the pages are built. All the page names are the same for every site, they just don’t get the same content depending on the device being used to view the site.
Or am I misunderstanding, and supercache automatically generates the index-iphone.html, index-android.html, etc? If that is the case, then that really isn’t very clear anywhere.
My impression of reading the code/doc, is that the function specifying my own names in wp_cache_check_mobile is to give an alternate page I know about which is not how the theme works.
After another day of considering this problem, and working with some of my testers, I’ve determined this incompatibility is even more dire that I thought.
Currently, it is possible for Weaver II to need to deliver to simultaneous different visitors FOUR different views of the same page: standard, iPad, smartphone compact view, smartphone full view. The next version will allow up to THIRTEEN different views. Thus, to do this properly, it would take THIRTEEN different caches – iOS devices, Android devices, generic mobile devices, each in two different views.
I strongly believe that while Weaver may be cutting edge on this issue right now, in the near future it will become common for many WordPress themes to support different views views based on specific devices – even if that is just the iPad.
Please trust me – this will become a significant issue, and I think it is essential that your caching plugin provide an easy to use and understand API for themes to help control this vital functionality.
I have some specific proposals, and would greatly appreciate it if you could read my take on the issue here: http://weavertheme.com/weaver-caching-and-mobile-devices/
Let me re-ask the question. Sorry I confused things with my follow up comment.
From what I’ve discovered by some code reading, if ‘wp_super_cache_error_checking’ returns false, then no cached pages will be served, and no new cached pages will be generated. Is that true?
A followup on the mobile device support. If I understand the mobile support code, what happens is this:
1. A mobile device is detected.
2. A new $cache_key is generated in response, resulting in different names for the cached pages
3. A different set of cached pages are generated/delivered to the mobile device.That solution fails with my mobile support because depending on the user’s choice, either a mobile page will be delivered, or an alternate full size page will be delivered to the mobile device. Both of these pages look different than the standard browser view. Extensive research with users indicate this kind of behavior – the ability to switch between a mobile specialize view, and a “pinch/expand” standard view on the mobile device are very important to the end user. It is that behavior that breaks the strategy for mobile devices as I understand it.
I’m sorry, I apparently am not stating the problem clearly enough. I don’t think any of those things you pointed out will help the problem.
Here’s the behavior required.
1. The user visits the site from a non-mobile browser
a. The cached pages are served
b. Pages added to cache in standard fashion2. The user visits the site from a mobile browser
a. The site is served dynamically –
no cached pages are served
b. The pages are not cached (no new cached pages generated)From what I’ve discovered by some code reading, if ‘wp_super_cache_error_checking’ returns false, then no cached pages will be served, and no new cached pages will be generated. Is that true?
That would mean I could potentially add another filter for that that could return false if the device is mobile, thus stopping all cache action.
I hunted all over your site, and could not (and still cannot) find a link to that page.
Well I guess I could spend a whole lot of my time looking all through that, or perhaps you could give me a hint.
What I think must be done is to add a filter that simply stops all caching for the page being requested. Like I would expect that somewhere in your plugin, you must have something like:
if (dont_cache_this_page())
stop_caching();I just need to trigger that swtich based on the fact that the site is being rendered on a mobile browser or not, and of course, that check has to be done dynamically each and every time the page is loaded.
And allowing a separate cache for the mobile version vs. the standard browser version will not work because the mobile view allows the user to switch to the standard view from the mobile browser (think iPhone) – thus adding yet another possible cache: standard, mobile mobile view, mobile standard view.
And although I know you need to work with lots of different themes, Weaver has tens of thousands of installed sites already. Its new approach to mobile view is as far as I know right on the bleeding edge of theme design, so I may be among the first themes hitting this wall.
I’m just assuming from my own experience that you would know just which filter to add that can give your code a cache/don’t cache check.
And given your main cache competitor seem to be ignoring my requests for information about the same problem, I will be able to recommend your cache to all my users if there is a way around this problem.
Forum: Themes and Templates
In reply to: How to avoid random images header ?I can’ find anything in the codex that documents the parameters available with ‘custom-header’. But I was just trying to get my theme (which started with Twenty Eleven code) to both allow random images, but not make that the default behavior. But that needed a default image defined then. Here’s what worked to do that:
// The %s is a placeholder for the theme template directory URI. define( 'HEADER_IMAGE', '%s/images/headers/default-header.jpg' ); ... add_theme_support( 'custom-header'); // , array( 'random-default' => true ) );Killing the ‘random-default’ parameter seems to leave the random option still there, but lets one specify a default header. The header is not checked in the list (there is no radio button selected in this case), but the Header panel still works.
Sorry – don’t know what “sequenced images” are, but thought this might help.
Forum: Plugins
In reply to: [WordPress HTTPS (SSL)] https from style.css url()s?Sorry I misunderstood your question.
And thanks for the answer. When I tested the parse_url, the results looked like they were generated based on the location of the calling file, but upon your new input, and a second look, I see what is going on and I’m sure your solution will work.
It is so difficult to know and understand all the details of where things are in WordPress, and how to access them. I’m sure you must know all the ins and outs of https and how it relates to files, while I’m still figuring out all the aspects of theme building. I appreciate your patience.
Thanks for the help. Perhaps this whole conversation will help others who need to generate https agnostic references into css files.
Forum: Plugins
In reply to: [WordPress HTTPS (SSL)] https from style.css url()s?That doesn’t help. It only gives a url relative to the file calling the function, not relative to where the final generated .css file is.
So can I infer from your answer that an https:// reference embedded in a .css file will cause an error if used on a non-secure page? I would try it myself, but I just don’t have access to a site that can to https.
Forum: Plugins
In reply to: [WordPress HTTPS (SSL)] https from style.css url()s?The CSS URL is being generated dynamically by the theme code, and depends on user settings. For example, the user can specify a custom graphic to use as list bullets, and that custom graphic can be anywhere – usually on the same site, probably within the media library path.
The style.css file is not saved in the “standard” theme directory, but is saved in the /uploads directory. The location, and even the name of the /uploads directory is variable, and on MultiSite versions, will vary depending on which user it is. So even when default theme graphics are included (for gradients, for example), the location of those images are known, but the location of the actual style.css file is not known.
Thus, using relative paths to the style url() graphics is not an option – they have to be a full http:// address.
So I’m assuming that it would be impossible, or impractical to the extreme, to try to filter the url()s within a .css file. Thus, my basic question is: if the url() tags within a style.css file use https:// instead of http://, will they still work when non-secure pages on the site are being displayed?
Apparently, it turns out that when the style code is included in-line in the <head> block (instead of being included from a file), that everything is fine – even though the url()’s in the inline code use http://, they don’t generate an insecure access. This leads me to believe that your plugin is filtering all output and changing all http:// to https:// more or less blindly, which seems like a reasonable approach.
Since my theme has an option to include the css inline rather than via a file, at worst case the user could use that for secure sites. But there are other good reasons to put the dynamically generated style into a file, and it would be preferable to keep that option.
My basic personal inexperience in just what an https:// reference from a .css file will really do is the reason for my question here.
Forum: Themes and Templates
In reply to: 2010 Weaver SupportDifferent browsers handle HTML errors differently. Getting a missing </div> (the usual problem) put the sidebars in the wrong place. Some browsers figure it out anyway, but IE is especially bad.
But whatever, if you have errors in the HTML of the post or page content (or sometimes an error with a plugin), it is likely the rest of the site won’t render correctly.
Forum: Themes and Templates
In reply to: 2010 Weaver SupportThe error is almost certainly an HTML error in one of the Blog posts.
Forum: Themes and Templates
In reply to: Disable "Leave a Reply" in Weaver ThemeThere is an entire article http://wpweaver.info/disabling-comments-and-talkbacks/ on the Weaver site that explains this. This unfortunately seems to be very difficult for many people to figure out.
By the way, this is TOTALLY a WordPress issue, and has nothing to do with Weaver or any other theme. However, it is also very hard for folks to tell where the theme ends, and WordPress begins, especially with a full featured theme like Weaver.
Forum: Themes and Templates
In reply to: How to Edit the "Home" link on the Menu Bar?This is not something that one needs to do with code.
The most obvious solution to this problem is to use the new custom menus that are a standard part of WordPress 3. You can make any menus you want.
But there are other ways to do this, too. In fact, Weaver has a check-box option to not display the Home item on the main menu. When you use this, however, you do need to properly use the Settings->Reading options for page display. You will want to set the front page to be your home landing page.
But there’s no need at all to hunt through php code. Weaver has a really excellent help file, and just a quick glance at its table of contents would have revealed both a specific topic about “Home”, and the information about custom menus.