Archive for the ‘programming’ Category

Using the PHP PEAR Services_Twitter Package with HTTPS

Saturday, January 25th, 2014

I have a PHP script that runs every few minutes via a cron job that has been running for a few years to send me direct messages on Twitter from a single-purpose Twitter account. The net result is that I can have system alerts sent to me by text message (by having direct messages from this special account subscribed for mobile alerts).

This script stopped working a week or two ago, and I finally got around to figuring out why. On Jan. 14, 2014, Twitter made SSL/TLS mandatory for connections to api.twitter.com. The announcement / blog post about that is here: https://dev.twitter.com/discussions/24239

Apparently, and not surprisingly, the PEAR module, Services_Twitter (available here: http://pear.php.net/package/Services_Twitter/),  works with api.twitter.com, and thus stopped working.

The fix was simple, once I was able to decipher the automated docs…

After this line: $twitter = new Services_Twitter();

I added this line: $twitter->setOption(‘use_ssl’,true);

The placement is probably flexible. But this one line worked. And my phone is now getting all those text message alerts that I dread. Yipee (?)

I wonder if I’m the only person using this library, considering that my Google searches came up surprisingly sparse on this topic…

 

 

Another Highly Customized Bingo Card Customer

Monday, November 7th, 2011

A couple weeks ago we delivered a PDF file that combined bingo cards designed with our custom bingo card generator and a very nicely designed background graphic that the customer had designed in-house. The final result turned out even better than we expected. We hope that the event at the university in the US that contracted the job went well.

We do one or two highly customized bingo card designs every year. They’re a nice change of pace, and often, we can re-use a little bit of programming on the live site. This time, we made a small improvement to the font size of column headers that are mixed lengths. That improvement will be pushed to the print-bingo.com site in the near future.

If you are reading this, and would like custom bingo cards to suit your own complex requirements, give us a call or email.

New Web Based URL Encode and URL Decode Tools

Saturday, April 23rd, 2011

The other day we were  programming a new website feature for a client that required the use of URL encode and URL decode functions.

We realized that our uber-cool web tools site didn’t have any web based URL encode or decode functions, which would have been handy during our testing.  So, we’ve added them to our web based tools site for the next time we need them.

Here are the links to the new tools:

Web Based URL Encode

Web Based URL Decode

PHP PEAR HTML_Template_IT Eats Dollar Signs

Wednesday, December 29th, 2010

Sigh.  We discovered a bug in our recently reworked tools.perceptus.ca (“PWT”) site.

We have a simple, custom, partial MVC system that runs a few of our smaller websites.  That system uses the PEAR HTML_Template_IT package to do the final template rendering. We ported PWT to our MVC to make future site changes much easier.

A week after going live with the changes, we found a baffling bug.  The tools were eating the dollar sign and dollar amounts (but not the decimals) from the input text. E.g. “$103.00” would get returned as “.00”.  Not good.

Apparently, HTML_Template_IT defaults to processing all text with regex.  Not cool.

There might be a historical reason for this, but for new users, this has got to be confusing. Plus, this is NOT mentioned in the intro documentation: http://pear.php.net/manual/en/package.html.html-template-it.intro.php

We’re not the only ones caught by this: http://pear.php.net/bugs/bug.php?id=50.

The fix is to initialize and set the use_preg option, like this:

$tpl = new HTML_Template_IT(‘./’,array(‘use_preg’=>true));

I have glanced at the package pages, and while this behavior is  documented it is buried quite deeply in the documentation.

This also explains a typo we had years ago on a static page that had the text like $5 in it.  That time, we just changed the copy to read 5 dollars and got on with life.

 

Google Chrome Built-in PDF Viewer Incompatibility with IFRAME and a Workaround

Saturday, December 11th, 2010

With the recent automatic upgrade of Google Chrome to version 8, Google made their built in PDF viewer the default viewer *.  I.e. there is now no need to separately download Adobe Reader or Adobe Flash Player to browse the web with Google Chrome.

Generally, I like this addition to Google Chrome; however, it caused some work for us.  Our web based bingo card generator, print-bingo.com, is highly dependent on PDF’s.  That’s the sole reason why our bingo cards are dead-easy to print out by the hundreds.  Unfortunately, Chrome’s built-in PDF renderer does not display PDFs that are in an IFRAME tag properly.

For the last few days, this is what users of print-bingo.com would see after generating 5 pages of bingo cards on print-bingo.com:

 

Broken PDF rendering in an IFRAME in Google Chrome 8 - screenshot from print-bingo.com

Broken PDF rendering in an IFRAME in Google Chrome 8 - screenshot from print-bingo.com

Chrome tries to scale the parent page to fit everything in… and it fails badly.

We were not able to get things working 100% the way we would like, but we have a workable situation now.

The basic steps that we had to take:

  • Change from IFRAME to OBJECT tag.  For whatever reason, this fixes the zooming issue.  And it was quite simple.  In our case, there wasn’t much difference between the two HTML tags.
  • Unfortunately, we can’t find a way to get Chrome to print the contents of the object tag without printing the rest of the page (though, perhaps using CSS  might work).
  • Instead, we added some bold warning text that gives Chrome users instructions to use the manual download links. We use a little function to identify Chrome users – the two key lines of code are: 
    $u_agent = $_SERVER[‘HTTP_USER_AGENT’]; 
    if(preg_match(‘/Chrome/i’,$u_agent)) { $ub = “Chrome”; }

So, we ended up with a workaround.  We sincerely hope that Google will add the missing interface elements that will make things just work, but until then, we are doing some other site improvements as we prepare to bump up the price of Premium Access to $12 in 2011.

* If you want to go back to using Adobe Reader in Google Chrome, you can turn off the  built-in viewer by going to the special address about:plugins and change Chrome PDF Viewer to Disable.  Of course, website owners should not depend on end-users to do this just to visit your site!