I am an author of short stories. I like using google docs and I like the idea of when I update a story these changes propagate to the sites I publish on. This system works fine in the latter versions of chrome and IE. http://plumplucker.com/
This doesn't work in IOS and only when using Opera on android - At present I need to create PDFs to work on an iPhone or an iPad which defeats my purpose of instant updating.
But right now I am trying to get Firefox to display the contents of the embeded iFrames, but FF 9.01 only shows the outline of the iframe containing a blank page. This is btw how ios displays the same page.
Here is my test page http://plumplucker.com/test3.html
In FF this page will load an iframe of my site, but it will not display the stories. I also tried having docs on google apps in case that would act differently - but no difference.
I have tried
Any one have a clue?
Just wanted to say that I have given up on inserting google doc iframes into my webpages hoping that they will render correctly on all platforms and browsers. That proved to be wishful thinking.
Instead I have constructed an app that builds static pages from the Google doc url's. First I let this happen on the fly every time a user selected a story for viewing, but there was quite a lag with this method and with afterthought I saw no reason not to create static pages. This I do for all my texts even if I have only changed a few details in one of them. I publish PDSs at the same time with TCPDF.
Related
I had all filed PDF on Google Chrome, that I accessed from a site. The site lets you fill like
https://www.courts.ca.gov/documents/fl150.pdf
Unfortunately, I hit back from MacBook pro touch pad.
Is there a way to retrieve the filled one from the Chrome cache? I know the time window.
According to this similar Super User question, Google Chrome Help thread, and Adobe Support Community post, the PDF Viewer does not automatically save the data.
Other browsers provide a warning such as This page is asking you to confirm that you want to leave — information you’ve entered may not be saved.
I converted my website to an APK and it installs fine - the problem is that when trying to scroll up or down - the page sticks and the page refreshes to a page not available - the live site works perfect.
Try to use momentum scrolling. I don't know exactly what can cause your issue, but
Android 3+ and iOS 5+ implemented a new property called overflow-scrolling that enables momentum scrolling. And it works beautifully.
Look here: http://www.mobify.com/blog/beginners-guide-to-perceived-performance/
Hope that helps.
I was using a service from GoNative that packages mobile web sites into APKS - kind of a wrapper to allow mobile sites to function like apps. One of the configuration options was to use "web pool" services that cached pages to allow for faster processing - I deleted that feature and the site/app works fine.
I'm using WP Mobile Detector with W3 Total Cache and a responsive layout (media queries), and I have a few issues:
When I view the site locally (localhost) on a Blackberry, it looks good; the zoom/viewport is correct, media queries have trigger correctly etc. However, when I view the live site on the Blackberry, the viewport has zoomed out. In the context of a responsive layout, locally I see two columns, but on live I see all six columns (i.e. the Blackberry thinks it is a full browser - quite annoying!).
I thought I would deactivate W3 Total Cache to see if that was having any effect: yes, it was. When the cache is off, the viewport/zoom is good and all is well. Problem solved? Not quite...
With the cache off, I navigate to the live site and while the sub-pages of the site - e.g. www.SITE.com/about, www.SITE.com/contact - are responding with the mobile theme, when I click a link back to home (or type it into the address bar) - i.e. www.SITE.com/ - I'm no longer delivered the mobile theme, just the normal 'desktop' theme. If I go back to a sub-page I see the mobile theme again. What's going on there then.
When viewed on the Blackberry (for example), if I click the 'View Full Site' link (which triggers a Javascript function to modify the cookie) it doesn't show the full site (i.e. normal theme), it just refreshes and shows the mobile theme. However, when viewed in Firefox on the desktop (via a User Agent Switcher) the link DOES modify the cookie and switches back to the normal desktop theme.
Thoughts/Questions
W3TC does work with WPMD (mobile theme delivers minified JS/CSS), but maybe I haven't configured something correctly. The following two links were very useful and I have implemented the changes suggested:
--- http://snipplr.com/view/47970/wp-mobile-detector--w3-total-cache-integration/
--- http://journal.code4lib.org/articles/6223
Is this a known [Blackberry HotSpot/Internet Browser] issue? I have added the requisite meta tags in the document head to indicate viewport data, and the HandheldFriendly meta data which I understand is mainly for Blackberry purposes. As I said, it looks ok with the cache switched off, excepting the home page issue.
I should say it works nicely in Firefox with the User Agent Switcher extension set to iPhone 3, and I have none of the Blackberry issues.
WPMD works by setting a cookie. This appears to be working, else I wouldn't have seen the mobile theme at all.
Does the Blackberry have a problem with the Javscript function? Not easy to tell from the phone itself - might need to drop in a JS error monitor (I was looking at one the other day).
Who'd have thought mobile dev would be so tricky!
UPDATE 1
It's a few weeks since first posting, and I will soon be following Joshua and Frederick's advice to uninstall and then reinstall the [latest version of] W3TC and I'll post my results.
I found that different browsers (both desktop and mobile) treat javascript redirect statements differently. For example:
setTimeout(function(){window.location.reload();},10)
window.location.reload();
location.reload();
The three lines above effectively perform the same action (slightly different implementations, depending on your needs), but I had varying success across browsers using each one - Chrome worked with one, Firefox another, etc.. Unfortunately, I still could not get the Blackberry browser to perform a proper automatic refresh via Javascript.
What else...so, switching between desktop and mobile using a desktop PC/browser has proven interesting. Let's say we're on the desktop version, and we switch to the mobile version of the page. We're OK so far, but then we switch back to the desktop version of the page. Still OK, but if we quickly click a link on the desktop page to go to another [desktop] page then we may find ourselves looking at the mobile version instead of the desktop version.
So, what happened there? As the page was still loading when we clicked another link, did we interrupt something? Presumably not, as the cookie would have been set and sent in the previous request from the mobile version of the page to say, e.g., "show-desktop-version = true". If we do hit F5 or the browser's 'Refresh' button (or, in fact, a link to any other page) then we do see the correct mobile or desktop version (respectively).
Another interesting thing: say we're on our mobile version (using desktop browser), and we're looking at site.com/mypage, and on the page is a link to 'View Full Site' (VFS). We click VFS once and it refreshes but we're still seeing the mobile version. So we click again - same result. So we click again, and again, and again, and again, and - oh, OK this time it switched to the full site. This cycle/process seems to occur once, and then not for a while, and then happens again.
UPDATE 2
Regarding the mobile-desktop theme switching problems, please disregard my notes in 'Update 1'. One of my switcher links (from desktop theme to mobile), e.g....
View Mobile Site
...was using the query parameter (as you can see). I had used this technique to test whether a mobile browser was preventing a proper refresh as the link pointed to the same/current URL. The switcher link should have actually looked like this,
View Mobile Site
...with just a hash to allow the link to be clickable, while allowing the Javascript function to do its magic (update cookie, reload page).
Problem resolved.
(W3TC + WPMD compatibility still an issue for me - will post updates).
I am the developer of the WP Mobile Detector.
The issues you describe are exactly what happens when the W3 Total Cache is installed. For whatever reason, sometimes it is necessary to deactivate and delete the W3 Total Cache.
Two customers that I can remember reported issues even when the W3 Total Cache was disabled. Once it was removed, it fixed the problem. They then re-uploaded W3 Total Cache, made the changes at the link you posted, and seemed to be fine.
For whatever reason these issues seem to be more prevelant with newer versions of the W3 Total Cache. I need to get with Frederick (the creator of W3 Total Cache) and make sure the plugins play nice together.
Make sure to clear your cache on the BlackBerry device as well.
Without evaluating the plugin there are some things to consider here. First W3TC attempts by default to set a cookie to properly determine which page cache to use for user agent groups for smartphones and less-smart phones; it keeps unique caches for each because of the popularity of mobile theme plugins prior to popularity of responsive web design and progressive enhancement.
The user agent groups can be disabled or used to redirect visitors to another page or theme. The next release also removes the need for the cookie when user agent groups are set. A future release will also allow cookies to be used to unique cache user requests as well.
I've got a simple little web app that's aggregating a couple views from some ethernet enabled cameras around my house. This is basically a little dashboard, so that I can easily tell what's going on around the house. I've got it refreshing the images every so often by appending new Date().getTime() to the base URI.
Everything works happy days, except for one little issue. If I leave the dashboard up on my iPad for awhile, it runs out of memory and crashes back to the home screen. I know that its because Mobile Safari is caching each of these images in RAM and it eventually ends up with far too many of them.
Since these images are being hosted on embedded devices; I really have no ability to modify the caching headers directly. I would like to stay away from making a wrapper on my server side as well.
My question is; can anyone think of a way to prevent Mobile Safari from caching these images so aggressively that it crashes?
You might try to reuse your img tags and/or set the src attribute to an empty string before removing an image. It's probably not an aggressive cache that's crashing mobile safari, but how the browser doesn't deal well with releasing image references when image tags get deleted.
You might find more useful information here:
http://www.vargatron.com/2010/08/ipad-html5-js-memory-management/
This question is part user experience, part engineering.
I am trying to find a nice, clean way to have a user communicate with my web page while they are on another web page. I have web services that will accept HTTP POST/GET, so AJAX and other asynchronous niceties are welcome - don't worry about the details of their communication, they can easily be modified to fit a solution.
The problem I'm running into lies within the user interaction. Ex., say the user is viewing a web page and they want to send my system the web site's URL. I would like it if they could do it while still looking at that page, and without too many "crazy clicks" - currently they have to go back over to my page and enter the information (as you can imagine this has tested horribly).
I have ruled out browser tool bars (easy to do in FF, but a lot of my users use IE) and local applications (they won't want to install Java or Adobe Air apps).
Have you ever solved a problem like this before, or do you have an idea of how I could solve it? Should I be looking at separate solutions for FF and IE (ex., a tool bar for FF and something else for IE)? Don't worry about Safari and Chrome, though a solution that supports them too would be nifty.
Thanks.
p.s. The user would have an account on my system already.
Have you thought about something like the Digg Bar?
Users can access it through a bookmarklet, or you can do a url prefix like http://yoursite.com/<other_site_url>. When users click links, the bar stays active.
What if you wrote a system tray application. Something similar to Pixel Ruler
This could sit in their tray, and it would know you're website. That would eliminate browser toolbars, and could conceivably work on several browsers. You could probably even set it up as an install if they visit your website.
Then you could expose a webservice on your site that this control would pass back info to (like the user's name, current website, etc)
I don't know about the details of your application, but the only solution I can imagine is that you have a page split into two frames, with your toolbar at the top. stumbleupon.com does this, but it makes sense because they're providing the web content.
Simply, your users would have to visit your site before they could do their own browsing. Is that reasonable for your project? That sounds like it could be a user experience disaster of its own. Also, if most of your users are using IE, I'm going to assume that they're not the most web savvy users out there.