ucla-oarc-mobile / mwf Goto Github PK

View Code? Open in Web Editor NEW

86.0 86.0 25.0 6.97 MB

UCLA Mobile Web Framework

Home Page: http://mwf.ucla.edu

License: Other

PHP 26.48% Ruby 0.17% JavaScript 69.04% CSS 4.03% HTML 0.11% Gherkin 0.18%

mwf's People

Contributors

Stargazers

Watchers

mwf's Issues

<html> to <html lang="en">

For accessibility reasons, the framework should likely write the <html> tag as <html lang="en">. See:

http://www.456bereastreet.com/archive/200901/specify_each_html_documents_main_natural_language/

I dug around in the code to find the best place to change this so I could submit a change, but came up empty-handed.

iOS Native container: Does not respond to orientation change

I guess this is a feature request and not a bug, but I'm assuming the issue tracker is still the right place for it...

Redirect Script Not Working on Lower End Phone

Today I used a lower end phone to test UCLA Mobile (LG Model No: LG290CM. FCC ID: BEJLX295. Carrier: Tracfone Wireless) and found that the gateway did not redirect. After explicitly visiting m.ucla.edu, UCLA Mobile displayed correctly, but the redirect did not work.

Here is the info from the Device Telemetry page at http://mwf.ucla.edu/framework:

User Agent: LGE-LG290C/1.0[TF2684354600144955890000000012074478405] UP.Browser/6.2.3.8 (GUI) MMP/2.0
IP Address: 207.154.35.241

No info for JS Classifications

PHP Classification:
is_mobile(): true
is_basic(): true
is_standard(): false
is_full(): false

all other JS classifications were blank (assuming it doesn't have javascript) and PHP classifications were false. I'm thinking the redirect issue is because it doesn't have javascript, so this issue probably can be instantly closed. I did think it was interesting that the framework did provide a valid mobile-friendly interface even to this low end of a device!

iOS Native container: Use Safari for external links?

Again, a feature request and not a bug.

getBrowserEngine() Undefined Return

If getBrowserEngine() cannot match an engine, it currently does not return any value.

This should be fixed to either return an empty string in line with all the other functions in mwf.userAgent.

contact link 404

In the README and elsewhere it's used, the contact link throws a 404 error:

http://mwf.ucla.edu/contact

Appcache handler needs to be usable from decorator

Assuming the appcache handler pull request is approved, we need to implement appcaching via the relevant Site decorator.

CSS for Menu Items with Icons or Thumbnail support

I am trying to add a menu item with an icon on it's left to the bottom of a standard text only menu, but the current support for embedding icons or thumbnails within menu items needs a more efficient and simpler solution.

Seems like the front page icon-menu solution is a bit of a hack : adding .menu-front class to the container menu, and hard-wiring various size icons to the background of the menu link items.

Wouldn't it be better to use an <img> tag within the menu item's <a> tag and encapsulate the CSS properties into a .menu-icon/menu-thumbnail class that will correctly shift the text to the right in order to allow space for the icon? This will allow mixed types of menu items within a single menu.

Also is it a feasible solution to require a size restriction on icon and thumbnail images to be used within menu items? See below example:

Icons: 16x16 (px)
Thumbnails: 80x80 (px)

Image class and minifier can use some improved encapsulation and removal of unused/unneeded features

Commit f239396' improves the maintainability of the Image class, in my opinion. I'd love to see it merged.

Only the image minifier uses the Image class, and I don't think any users are likely to be using the Image class directly, so it made refactoring seem do-able at this time.

By the way, unit tests for the Image class are almost done, which is a big part of how I came to do this refactoring in the first place.

Path_Validator::is_safe() broken for local paths?

Bogus bug report deleted by embarrassed reporter.

Decouple PHP Decorators from MWF Core

Content providers should be able to use PHP decorators outside of the service provider. Right now, some of them are too coupled for this to be possible without modification.

iOS Native container: Network activity indicator remains on if page load fails when user is offline

Fixed in commit f3760e3

Android native container: unused imports

There appear to be four imports in MWFWebViewActivity.java that are unused. See c8427ed. Safe to merge that into feature/native?

cookie_domain not dead yet

cookie_domain is in vars.src.php in develop and possibly other branches (and perhaps files)

Dangling @todo in useragent.src.js

Very minor, but there's a dangling @todo in useragent.src.js.

Minimal Selenium tests

We should get some minimal Selenium tests happening, especially now that we're dealing with bugs in DTS that require a browser to replicate (that is to say, they can't easily be surfaced with unit tests). We can build up the Selenium test suite to be more complete over time, writing new tests as defects are discovered in the code and as new features are introduced in the code.

I'll set something up using Ruby. We can keep it pure PHP if we really want to, but my read of the Selenium 2.0 documentation is that Ruby support exceeds PHP support. Since this is code that will run automated tests and not code for the actual framework per se, I think that should be fine.

If anyone feels strongly that we should stick to PHP only for our scripting needs, I'm putting together something minimal and it should not take much effort to port it. I just don't feel like dealing with oddities that might crop up. I also don't want to decide which of the three third-party PHP integration libraries to use.

User HTTP_HOST rather than SERVER_NAME and SERVER_PORT in config.class.php

I don't want to do this unless there is an identifiable bug it fixes, but there is reason to believe (see issue #45) that the current use of SERVER_NAME can contribute to an infinite redirect loop in DTS. (I just tried to emulate it and was surprised that something that causes it in 1.2 doesn't cause it in the develop branch. Will poke more at it later.)

Android native container: menu

Added a menu with forward, back, home, and refresh in d797bf8. Will merge into feature/native unless someone objects. Will let this sit here for some time to let people comment on the commit.

IE Quirks Mode / Standards Mode Mismatch b/t target page and passthru.php results in infinite redirect loop

Yup, that's it. passthru.php outputs an HTML document with no doc type, throwing IE into quirks mode.

If you're target doc also puts IE into quirks mode, you're good.

If you use then it's standards mode and you enter redirect loop nightmare.

If you put that doctype into passthru.php, you get the opposite behavior: Quirks mode pages go into infinite redirect loops and standards mode pages work.

Eric, I don't know enough about why there's that extra classification check in the DTS that's giving us heartburn here--I'm sure there's a good reason for it, but I don't know what that reason is--do I'm kicking this over to you at this point. (Yay, no more emails from me today!)

I'll open an issue in GitHub.

--Rich

From: Trott, Richard
Sent: Monday, December 12, 2011 2:17 PM
To: Bollens, Eric; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: RE: UCI Libraries mobile url for MWF test site

As Mark/Vega/help-me-out-what-do-I-call-you pointed out, it's flapping between standards mode on the content page and quirks mode in passthru.php. So that's probably what's causing the classification to change and thus the infinite redirect loop.

Why do we do the check for change in classification? Without knowing that, I can't be sure that anything I suggest is going to be a good suggestion, but that won't stop me:

It may be tempting to try to do something to force it into one mode or another, but I suspect we should just accept that we can't actually force the browser to reveal the same things all the time. I think we should just believe what it's telling us on the page that we're on, overwrite the cookie there, and reload. (Yeah, it's an extra HTTP request. Oh well. Another argument for appcaching.) The only way that could cause an infinite redirect loop is if the browser reports different things on every request to the same page.

--Rich

From: Trott, Richard
Sent: Monday, December 12, 2011 2:07 PM
To: Bollens, Eric; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: RE: UCI Libraries mobile url for MWF test site

I wonder if this has to do with the browser toggling between standards mode and quirks mode perhaps due to the HTML5 doctype.

From: Trott, Richard
Sent: Monday, December 12, 2011 2:05 PM
To: Bollens, Eric; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: RE: UCI Libraries mobile url for MWF test site

Yes, and that's precisely the issue. I was mistaken when I said it wasn't being set. The value is indeed changing.

standard is false in site.cookie.classification but true in classificationCookie when you hit this line in server.src.js:

  if(!site.cookie.exists(classification.cookieName) || site.cookie.classification != classificationCookie)

If you want to take this to IRC, we can probably get some stuff done faster. (And if you just want to take over at this point and fix it, even better. :-) )

From: Bollens, Eric
Sent: Monday, December 12, 2011 2:01 PM
To: Trott, Richard; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: Re: UCI Libraries mobile url for MWF test site

Hmmm, that's interesting... Let me know what you find with classification.
That's the only one that does more than a cookie existence check - it also
checks to make sure that the classification has not changed in the cookie.

~ Eric

On 12/12/11 1:56 PM, "Trott, Richard" wrote:

I don't think it's #2. I'm stepping through in a debugger and that
should give it plenty of time for the browser to take the cookie. I'm
not ruling it out, but I don't think so if I have to guess.

I do notice that it seems to always be the classification cookie that
fails, and not the other two.

From: Bollens, Eric
Sent: Monday, December 12, 2011 1:51 PM
To: Trott, Richard; Vega; Jim Kreuziger
Cc: Christopher Davis; Sakabu, Edward
Subject: Re: UCI Libraries mobile url for MWF test site

Rich,

The starting point here is mwf.server.mustReload. It is false by default,
but set true whenever mwf.server.setCookie() is called. This implies that
one or more of the mwf.site.cookie.exists() calls in mwf.server.init() is
failing (or that the classification has changed) again and again.

I thus arrive at mwf.site.cookie.exists() as the likely culprit. This is
written out in vars.php based on logic whereby the page checks for the
user_agent, screen and override cookies, and writes them out if they
exist. The exists() function then checks to see if the one provided in a
parameter has been defined on the server.

If mwf.site.cookie.exists() is returning false, that means that the cookie
hasn't stuck to the server yet. This would mean that passthru.php is
proving ineffective in setting the cookie.

Two reasons that passthru.php might fail:

(1) The browser does not accept cookies but the mwf.capability.cookie()
check believes it does.

(2) Javascript on the page is redirecting the user before the browser
processes the cookie write.

I doubt that the issue is (1) given that IE 9 is almost certainly
accepting cookies. However, (2) might be more likely. Imagine, for
instance, if IE 9 doesn't process cookies until a certain elapsed time,
say at onLoad, as opposed to immediately when document.cookie is called. I
think the test, therefore, would be to modify passthru.php to not redirect
until onLoad or onDOMContentLoaded. This will induce a slight delay in the
redirect, but might solve the problem.

Thoughts?

~ Eric

On 12/12/11 1:39 PM, "Trott, Richard" wrote:
D'oh! Port 80 blocked at the campus perimeter.

I can put it on another port, but really, all you have to do is copy and
paste the source from the UCI lib page, uncomment the script and change
the redir target to your script location.

Looks to me like this bit of code is always firing on every page visit:
   else{
       if(this.mustRedirect&&!mwf.override.isRedirecting){
window.location=b.asset.root+"/passthru.php?return="+encodeURIComponent(w
i
ndow.location)
}

Obviously, it should fire (at most) just the first time.....

--Rich

From: Bollens, Eric
Sent: Monday, December 12, 2011 1:37 PM
To: Trott, Richard; Vega; Jim Kreuziger
Cc: Christopher Davis
Subject: Re: UCI Libraries mobile url for MWF test site

Can't seem to access that address Rich...

Any idea what's causing it?

~ Eric

On 12/12/11 1:36 PM, "Trott, Richard" wrote:

Although no rush, since I now have the bug running on my own local
machine.

Eric, if you need an installation that shows the bug, point your IE
browser at http://128.218.15.246/test.php

--Rich

From: Bollens, Eric
Sent: Monday, December 12, 2011 1:33 PM
To: Trott, Richard; Vega; Jim Kreuziger
Cc: Christopher Davis
Subject: Re: UCI Libraries mobile url for MWF test site

Rich is correct. Without that line, the MWF cannot determine what your
device is capable of. All phones will instead get the basic-grade CSS
and
no JS support.

~ Eric

On 12/12/11 1:30 PM, "Trott, Richard" wrote:

You really need to put that line back. Removing it is not the
solution.
There's a bug in there that needs fixing, but you need the JS code that
script tag provides.

From: Vega
Sent: Monday, December 12, 2011 12:46 PM
To: Kreuziger, Jim
Cc: Trott, Richard; Bollens, Eric; Christopher Davis
Subject: Re: UCI Libraries mobile url for MWF test site

The endless redirect seems to stop when I remove the following from the
head section:
<script type="text/javascript" src="http://m.uci.edu/mwf/current/root/assets/js.php?full_libs=transiti o n s +touch_transitions"></script>
Once removed, the page loads but with incorrect styling. In
particular,
IE seems to be ignoring 'text-align: center;', 'display:
inline-block;',
and all three types of gradients (moz-, webkit-, and o-).

Jim: I did test on your wife's Windows phone on Friday as well which
is
what alerted me to the problem. The page loaded (no redirect loop),
but
did not display with correct styling.

Vega

On 12/12/2011 12:33 PM, Kreuziger, Jim wrote:

Nothing has changed on the site. I've looked at the site on Windows
mobile (my wife's phone) and it looked pretty messed up (that's the
technical term ;)). Since I only have access to the phone when I'm
not
at
work, I'm going to fire up my windows VM to see if I can reproduce
any
of
this.

I'll remove the trailing slash on site_url... Ok, that's done. Let
me
know if that makes a difference.

Jim Kreuziger
Director, Web Communications
University Communications
University of California, Irvine
www.uci.edu

On 12/12/11 11:03 AM, "Trott, Richard"
wrote:

Jim, I was able to reproduce this problem on Friday using Internet
Explorer, but today I am unable to do so. Any idea if anything
changed?
I'm hoping the answer is "yes" but I'm guessing the answer is "no".

Anyway:

site_url has a trailing slash. The trailing slash should be
removed,
although I don't know that it would be causing the behavior we're
seeing.
(Seems unlikely, but Eric would know a lot more.)

--Rich

From: Kreuziger, Jim
Sent: Monday, December 12, 2011 10:51 AM
To: Trott, Richard; Bollens, Eric
Cc: Vega
Subject: Re: UCI Libraries mobile url for MWF test site

Rich, Eric,

I'm currently running 1.2.07. I have 1.2.08 in the queue, should be
able
to update sometime today. I'm going to attach a copy of my
global.php
config file, in case this is something you can use.

Right now, Vega is the only one outside the actual framework that
has
tried to create a site. Our UCI mobile site is being developed on
the
domain (m.uci.edu) that the framework resides.

Let me know if there is anything that I can do to help.

Jim Kreuziger
Director, Web Communications
University Communications
University of California, Irvine
www.uci.edu

From: Vega
Date: Mon, 12 Dec 2011 07:02:36 -0800
To: Jim Kreuziger
Subject: Fwd: RE: UCI Libraries mobile url for MWF test site

Jim,
I'm having some problems with my new MWF-based mobile site
(http://www.lib.uci.edu/mwf-test/) in Internet Explorer (desktop and
Windows phone) and reported such at Friday's MWF Developers meeting.
Eric Bollens and Rich Trott asked me to send them the url and you
can
see
Rich's troubleshooting notes in the email below. I'm not sure,
though,
why the trouble only presents in IE...

Vega

-------- Original Message --------
Subject: RE: UCI Libraries mobile url for MWF test site
Date: Fri, 9 Dec 2011 23:56:04 +0000
From: Trott, Richard
To: Vega, Eric Bollens

More notes for Eric:

You can see the problem in IE, so you don't need to get a Windows
phone
or anything.

Their MWF code appears to have all the important relevant bugfixes
that
have been committed to master (unless their doing something weird
like
protocol-less URLs, but who does that besides idiots like me?). You
can
see, for example, their JS source at
http://m.uci.edu/mwf/current/root/assets/js/

Might want to mail Jim K. or whoever and get their config settings
to
see if you can replicate this.

IE is working fine on m.uci.edu, so it's probably something to do
with
this being a client on its own server and not an SP.

Ready to switch to OpenDDR? :-P

--Rich

From: Trott, Richard
Sent: Friday, December 09, 2011 3:40 PM
To: Vega; Eric Bollens
Subject: RE: UCI Libraries mobile url for MWF test site

Eric, this looks like DTS loop trouble. I hope they're running an
MWF
that is a couple versions back and that they just need to update.

From: Vega [
Sent: Friday, December 09, 2011 3:27 PM
To: Eric Bollens; Trott,
Richard
Subject: UCI Libraries mobile url for MWF test site

Rich, Eric;
Here is url to my test instance of mobile site using MWF:

http://www.lib.uci.edu/mwf-test/

Looks great on iPhone, Android but breaks on Windows phone and in
desktop version of IE9.

Mark Vega
Programmer/Analyst
UCI Libraries - Web Services
The University of California, Irvine
P.O. Box 19557
Irvine, CA 92623-9557

title_text unset issue

Reported by Ike as a comment in another issue. I haven't confirmed this bug or anything....

"On a side note, if title_text is not set, the entire page content is
dumped into the title text."

PHP warnings for CURLOPT_CONNECTTIMEOUT_MS

We are getting the following warning(s) in our Apache error_log:

[Wed Nov 02 11:14:02 2011] [error] [client 128.200.134.61] PHP Notice:  Use of undefined constant CURLOPT_CONNECTTIMEOUT_MS - assumed 'CURLOPT_CONNECTTIMEOUT_MS' in /home/uci_test/public_html/uci/mwf-1.2.05/root/assets/lib/path.class.php on line 94, referer: http://uci-test.cwis.uci.edu/mobile/
[Wed Nov 02 11:14:02 2011] [error] [client 128.200.134.61] PHP Warning:  curl_setopt() expects parameter 2 to be long, string given in /home/uci_test/public_html/uci/mwf-1.2.05/root/assets/lib/path.class.php on line 94, referer: http://uci-test.cwis.uci.edu/mobile/

The PHP documentation indicates that CURLOPT_CONNECTTIMEOUT_MS is "Added in cURL 7.16.2. Available since PHP 5.2.3".

We are running PHP 5.3.3 and cURL 7.15.5, so we will need to update cURL, but it would be good to know if this warning is going to cause any real issues.

Looking at the framework documentation, we noticed that the list of required packages doesn't include any sort of version requirements for required packages. Any chance that the documentation be updated to include minimum requirements for packages?

Jim Kreuziger

Device Telemetry Stack on Separate Domain

When the MWF does it's refresh to pass telemetry from client to server on the first page load, the cookie definition is occurring against the content provider host, not the service provider host.

This bug doesn't manifest for service providers who use the front splash page, because the write goes against the service provider and then stays set throug other pages. However, if you're running this in an environment where the framework is completely separate from even the front page, the cookie is set to the wrong place.

iOS Native container: Background color

Short pages will sometimes show a white background if the background color is not set. This is fixed in commit 140072e but that commit has UCSF's background color hard-coded and may not be the best/most-elegant solution anyway....

iOS Native container: Compilation warning

The '_webView' outlet of 'File's Owner' is connected to 'Web View' but '_webView' is no longer defined on MWFWebView.

Remove the Last of Static Cookie Object Avoidance

43b407e

DTS infinite loop edge case

Set up a server called, say, login.proxy.library.ucla.edu.

Serve up a page in docroot called, say, menu.htm.

Assume that the end user might access it through HTTPS or might access it through HTTP, so you have code like this:

<link rel="stylesheet" type="text/css" href="//p1.m.ucla.edu/assets/css.php" media="screen">
<script type="text/javascript" src="//p1.m.ucla.edu/assets/js.php"></script>
<meta name="viewport" content="height=device-height,width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=no;">

(Sure, they shouldn't use p1.m.ucla.edu, but the point is that they use a name that isn't m.ucla.edu. Certainly, there are use cases where more than one hostname for the mobile site is desirable. This is especially true if we want to extract DTS from MWF and make it available for general use. Anyway, even if they shouldn't do this for other reasons, it should not result in an infinite redirect loop.)

Assume m.ucla.edu is running MWF 1.2.09.

Because of the different p1.m.ucla.edu vs. m.ucla.edu hostnames, vars.php will alternately see and not see the m.ucla.edu cookies (depending on if it is being pulled in via http://login.proxy.library.ucla.edu/menu.htm or via http://m.ucla.edu/assets/passthru.php).

The end result is an infinite redirect loop.

iOS Native Container: XCode 4 compatibility

Perhaps it's just me, but I couldn't open the project in XCode 4 and see anything, and neither could a colleague. If I subsequently added everything to a workspace, it opened just fine.

afa823a

Merge Messages API

The Messages API has passed code review and is ready for merge into develop for MWF 1.3.

Update License

A new license has been provided by the UCLA Office of Intellectual Property.

This should be updated in the LICENSE file and on the site, as well as the copyright notice printed by footer changed to read "Powered by the Mobile Web Framework", dropping the reference to UCLA in the name.

Add watchPosition to Geolocation API

I added watchPosition (along with clearWatch) to the geolocation API. I ended up refactoring the older methods to prevent some duplication (e.g. duplicate error messages). I worked off the current develop branch, but I wasn't sure if it's a small enough change that can just be moved into 1.2:

https://github.com/loganfranken/mwf/blob/loganfranken/develop/root/assets/js/standard/geolocation.src.js

Main change:
d0a8042

Clean up:
1b25b1b
7d43842

Should I create a pull request for develop or develop-1.2 (or something else)? Or is this a change we even want to integrate at all? Let me know; thanks!

htmlspecialchars() conflicting with URI parameters?

Having problems with the Head_Site_Decorator concatenating multiple parameters with & rather than &.

Here's the old version:

@@ -110,10 +110,10 @@ class Head_Site_Decorator extends Tag_HTML_Decorator
     private function _generate_url_param_string($params) {
         $rv = '?';
         foreach($params as $key=>$val) {
            $rv .= is_int($key) ? $val.'&' : $key.'='.$val.'&';
         }
         $rv = rtrim($rv,'?&');
        return htmlspecialchars($rv);return $rv;
     }

A possible fix would remove the htmlspecialchars() on the query string and instead apply it directly to names and values.

@@ -110,10 +110,10 @@ class Head_Site_Decorator extends Tag_HTML_Decorator
     private function _generate_url_param_string($params) {
         $rv = '?';
         foreach($params as $key=>$val) {
            $rv .= is_int($key) ? htmlspecialchars($val).'&' : htmlspecialchars($key).'='.htmlspecialchars($val).'&';
         }
         return rtrim($rv,'?&');
     }

Thoughts?

Appcache handler docs need to be written

Assuming the appcache handler pull request is approved, we need some documentation.

passthru.php without a 'return' URL parameter results in an infinite loop

Going to http://m.example.edu/assets/passthru.php results in an infinite loop. This may not be a bug per se since passthru.php should always be called with a return URL parameter. But it's probably better if it detects when no value has been set for return (or when an unsuitable value, such as an invalid URL is set for return) and just exits.

Enable external link styling via rel=external

I've implemented this on the UCSF branch with commit Trott@d990a13 but I think it's useful enough that it should be incorporated into the core. The three main arguments would be:

encouraging use of rel=external enhances accessibility
baking in styling for external links based on the de facto Wikipedia standard is good usability
it gives us a semantic and standards-compliant way to detect external links in the native apps

Here would be the steps I'd take to incorporate it:

Move the stuff for a background arrow image in menus from the anchor object to the list item object. See diff on root/assets/css/default/basic.src.css in the commit above. This does have the disadvantage of styling all list items as menu items, if they are part of a .menu-full, but I don't have a problem with that and actually think it is a good thing to discourage using list items within menus for non-menu items for reasons I can get into if we need to. Of course, since this would be a behavior change, that makes this a 1.3.x feature.
Add in the stuff to style external links and add the .png image that designates external links. See changes in root/assets/css/ucsf/basic.src.css in the commit above. This would go in default/basic.src.css instead and we'd have to de-UCSF-ify the file name.

And I think that's it. Should I go for it on the develop branch?

I currently have this installed and running on m-stage.ucsf.edu so you can go there to see what it would look like. Check out, for example, http://m-stage.ucsf.edu/#/il/shuttle/, where the last three links in the menu are rel=external.

Appcache Handler: Pragma: no-cache header is for requests, not responses

Pragma: no-cache header is for requests, not responses. It should be removed from js.php and appcache.php.

Configurable cache expirations

The image compressor and possibly other things should have a configuration option to specify a maximum age for cached contents. When the compressor sees a file with a time stamp older than that, it should re-fetch etc.

Alternatively, people can use cron jobs or whatever to clear out their cache dirs, but I think it would be good to have an option that is entirely contained within the framework.

Image class can be made to consume all available memory (up to php ini memory_limit setting)

The Image class doesn't take precautions to make sure it won't consume absurd amounts of memory before trying an operation. The result can be a PHP Fatal Error that makes the rest of the script fail to run.

Inserting this near the top of a script in the root dir (say, the default MWF index.php) will result in an error being logged and a blank page being rendered:

require_once(dirname(__FILE__) . '/assets/lib/image.class.php'); ini_set('memory_limit','4M'); // Ironically, this 4.4 Mb image is named "thumbnail.jpg" http://xpress.sfsu.edu/specials/2010s/MOUSE/thumbnail.jpg $image = Image::Factory('http://xpress.sfsu.edu/specials/2010s/MOUSE/thumbnail.jpg'); $image->set_max_height(100); $image->generate_image();

Given the likelihood that the images are from some external input (content in an RSS feed, comments from a user, or just something on an external server that we don't control and that someone else can swap in new content for at any time), it is probably wise to check the probable size of the operation and proceed only if the memory consumption seems reasonable.

This is all very similar to the (now-patched) bug in Mahara detailed at https://bugs.launchpad.net/mahara/+bug/784978. A bug fix for MWF would look very similar to that.

passthru.php should include title element

HTML5 does not permit the omission of a title element unless the title element is provided by a "higher-level protocol". In our case, there is none, so we need to provide a title element. The title element can be an empty string, so we can just include <title></title>.

Reference:
http://www.w3.org/TR/html5/semantics.html#the-head-element

The title element is a required child in most situations, but when a higher-level protocol provides title information, e.g. in the Subject line of an e-mail when HTML is used as an e-mail authoring format, the title element can be omitted.

Android native container: appcache friendly

Eventually, hopefully, everyone will be using an offline AppCache, at which point we'll probably want to incorporate something more like 01648ab than the current offline setup.

Device Telemetry Stack: Infinite reload loop

I suspect it will take some hunting down details to sort out exactly how to reproduce this, but I deleted my classfication cookies, left my other two cookies, and got stuck in an infinite reload loop that kept going through passthru.php.

(Another) Infinite Redirect Loop in DTS

How to replicate:

Check out HEAD on develop-1.2 branch
Do minimal config in global.php
Launch iPhone simulator
Clear cookies
Open Safari and go to a page that is not the home page. For example, go to http://127.0.0.1/mwf/about.php

Clarify Config setting defaults

See email thread "Customizing the Framework, a problem (or two or three)" on the [MWF] list for details.

Head_Site_Decorator output is not valid if multiple JS or CSS libs included

The decorator does not escape the ampersand in the HTML output, resulting in HTML that does not validate.

.not-phone-number when format-detection telephone is "yes"

Rich raised a question in IRC about preventing phone number format detection.

The simple answer is to use meta[name="format-detection" && content="telephone=no"].

However, what about for content providers using format detection? There's a solution for Skype with Windows that inserts a span around each set of numbers so that the hyphens do not cause auto-detection. It will need to be tested in iOS and Android to confirm that it is indeed effective here, but this is essentially the idea:

$('.not-phone-number').each(function(){
    var str = '<span>';
    var arr = this.innerHTML.split('-');
    for(var i = 0; i < a.length-1; i++)
        str += a[i]+'</span>-<span>';
    str += a[a.length-1]+'</span>';
    this.innerHTML = str;
});

The MWF version will need to do this without using jQuery of course, but basically it's just another sprinkle to put into MWF 1.3.

adding charset

See issue #4 for more details.

Extraneous stripslashes in classification.class.php and elsewhere

Static cookie object deals with whether or not to do a stripslashes on the cookie values, so the stripslashes() in classification.class.php is now incorrect (sorry, I missed removing it when I did the static object) and may theoretically result in incorrect values (which, actually, was true before the static object, as it makes assumptions about magic_quotes_gpc).

Commit cc651fe

Now that I look, I see stripslashes() in two other places where it no longer belongs. Coming right up....

dead code in server.src.js / server.js

server.js initializes and checks a variable (this.error) but never
sets it anywhere other than in initialization.

iOS native container: Small typo

Small typo in native container fixed in commit e825f72.

Typo causes unit tests to fail for Android 2.3

Android native container: set minimum SDK to version 8?

The minimum SDK is currently set to version 10. I believe that means that Android 2.3 and above can run the app.

However, at least on the m.ucsf.edu site, about 20% of our Android traffic is Android 2.2.

And according to data from Google, Android 2.2 phones account for about 30% of the phones that have accessed the Android Market in the 14-day period ending January 3, 2012. http://developer.android.com/resources/dashboard/platform-versions.html

I have found no downsides to using version 8 rather than version 10, which will allow Android 2.2 phones to run the app.

The only change I had to make for this was to remove the xlargeScreen setting in the manfiest. That was set to true, which I believe is the immutable setting in SDK 8, so I don't think we're losing any functionality. (Am I wrong about that?)

Are there any known downsides to using SDK8 rather than SDK10?

If not, should we just make that the default in the code?

The commit where I did this is 884d178.

ucla-oarc-mobile / mwf Goto Github PK

mwf's People

Contributors

Stargazers

Watchers

Forkers

mwf's Issues

I do notice that it seems to always be the classification cookie that fails, and not the other two.

--Rich

--Rich

You really need to put that line back. Removing it is not the solution. There's a bug in there that needs fixing, but you need the JS code that script tag provides.

--Rich

Vega

--Rich

Eric, this looks like DTS loop trouble. I hope they're running an MWF that is a couple versions back and that they just need to update.

Recommend Projects

Recommend Topics

Recommend Org

I do notice that it seems to always be the classification cookie that
fails, and not the other two.

You really need to put that line back. Removing it is not the
solution.
There's a bug in there that needs fixing, but you need the JS code that
script tag provides.

Eric, this looks like DTS loop trouble. I hope they're running an
MWF
that is a couple versions back and that they just need to update.