as i feared, designburo.nl is down

i hope not for long because now the module doesn't work

OK, if anyone is interested in generating a QR code in a block with the Website Name and Article Title embedded with the page link, I created a new block for the Geekwright QR module specifically to pick up Publisher VARs.

For testing you can download the hacked module here

Just select 'File/Download' to grab the whole ZIP, or click on 'xoops_version.php', 'blocks/blocks.php' and 'language/English/modinfo.php' to see the changed files.

If it works OK I will post the code to the guys over at Geekwright who have done a nice job with this module. Perhaps they might develop some other module-specific blocks.

WARNING - You must ensure that your Xoops trust path is writable. This is by default 'xoops_lib/modules'. If you don't check those permissions, the module will not install.

The new Publisher block should of course only be added to the Publisher module pages. For non-article pages it just captures the URL.

Please post here if it works... or not!

Oops, a QR discussion and I missed it!

I got a note yesterday from Peekay, with his modifications to the QR module and a pointer to this discussion. After reading through it all, it sounded like a possible solution would be to make a block that implements a MEBKM format bookmark code. That format looks like this:
MEBKM:TITLE:(title);URL:(url);;

The bare URL is already used in the "Here" block, and it is fairly easy to grab the document title straight from the DOM. That way the title usually is specific to to the displayed content and contains the site name. A block that does that is now part of the QR module 1.3 source on GitHub, at:

https://github.com/geekwright/qr

If you are interested in giving it a try, probably the easiest way is to choose the Zip button (left side) - "Download this repository as a zip file" option. The zip file will contain a folder 'qr-master' that should be renamed to 'qr' and placed in your site modules folder. (Actually you can install it as qr-master and it should work fine, but it would be distributed as qr.)

Any feedback is welcomed. Thanks!

First of all, thank you for your work

My first test result :

I had to chmod 777 xoops_lib/modules/ to obtain on install, this positive message :



But I still have an error on this page (modules/system/admin.php):



My Configuration :

PHP version 5.3.10-1ubuntu3.5
Mysql version 5.5.29-0ubuntu0.12.04.1
XOOPS version 2.5.5

Wow, a double embarrassment, as all the work on the latest version of the qr module was done on Ubuntu 12.0.4.

The php rename will need write permissions on both ends. Rather than passing out world write permissions, I'd recommend moving the directory manually. Drop to a terminal and just issue a command like:

mv /xxx/xxx/modules/qr/trust /zzz/zzz/xoops_lib/modules/qr

Then everything should work fine. You can accomplish the same thing with ftp/scp or other file managers if a shell isn't available.

This used to be a totally manual step. The latest versions have tried to automate it. It has worked in a lot of circumstances, but obviously not in all. Depending on the configuration of os->web server->php there can be combinations that just don't work well, and some that work flawlessly (such as most suphp or similar based systems.)

I'm seriously considering moving this operation into a page in the module admin so it can show proper diagnosis, feedback and guidance. Hiding it in the install and update hooks seemed like a great idea at the time, but in practice it seems a source of complication, not simplification.

For now, I'd recommend manually moving it. I'll try and rework it as time permits.

Thanks for the feedback, and sorry for the troubles.

I've reworked things a bit. so there is no more issue with trust path installation. It has been treated like a blackbox, but the library codebase isn't that large, and took only a few tweaks to met the same security goals from within the module directory.

Also added is a 'popup' option to the blocks, so blocks don't have to take up large amounts of layout space, but remain easy to access. This is especially helpful with the mecard and new bookmark blocks. (The popup versions also have a better quiet zone than most in-line placements, so the codes can often scan more reliably.)

All this is featured in QR Module V1.3 available here: http://geekwright.com/modules/wfdownloads/singlefile.php?cid=1&lid=1

As always, suggestions and comments are welcome.

Look forward to trying it.

Can we have a block that creates a 'me card' in 'Vcard' format that Android phone will recognise and add to contacts.? (Apologies if the existing one does this, I haven't actually tried it)

Some info here.

Quote:

A vCard can be done, but there are a few questions that come up.

Setting up to do a vCard is not really a problem. Making it work with any given phone is the problem. An android device (or any device, really) doesn't dictate the type of code or format used. It has an contact manager that can hold certain data, and that varies by version and implementation.

The scanner app is where the magic happens, converting what is scanned to what the contact manager can use. By all the stats I've ever seen, there is much better coverage for the MECARD than vCard. Can you give me an example of an Android scanner that doesn't do MECARD?

I can understand why you might want some of the extra fields possible in the relatively huge vCard spec, but it is unrealistic to expect the results on the scanning end will be anywhere near universal. Also, size quickly becomes an issue on the scanning end, where bigger translates to higher failure rate, which in turn translates into end user frustration.

Deciding on the list of vCard types to include could easily be the most time consuming part of adding support for vCard. If it is a minimal list, it doesn't add much value, but if it is too large, it becomes cumbersome and likely to fail during scanning or in post scan decoding.

One compromise I've seen which mitigates these issues is to save the full vCard as a file on the web, and put the URL to it in the QR code. This generally gives the contact manager (on whatever platform) full access to the data to pick and choose, rather than having the scanner app act as the intermediary. Unfortunately, even this is not universal.

If there is significant interest and agreement on the details of a vCard addition, I'll be happy to put it in. I just need a good map of what is expected.

Thanks for the feedback!

You can omit a lot of the options to create a basic business vcard. The spaces between semi-colons in the code below are the omitted values, e.g 'City' is included in the submit form, but 'County' is left out.



This works on our business Android phones (automatically adds to contacts) but not iPhones... of course.

It was just a thought. I agree it would be too much work unless a number of people showed an interest.

Well, I played with a vCard block. You can find the results on GitHub on the 'vcard' branch. You can grab it as a zip here.

This experiment reminded me of one of those facts of XOOPS that I have to relearn periodically, and that is that the options of a block are limited to fitting into a MySQL varchar(255) column. This means that if the data gets too large, the block starts failing.

Aside from that, the results of testing by scanning across devices also provided disappointing results (this was expected.) As an example, defining multiple phone numbers resulted in a list of phone numbers with randomized types no matter what was specified in the vCard data. It doesn't help much to specify a fax number if ends up as a home number in the contact information.

To properly implement this on the XOOPS side would require a database component to store and edit vCards. That sounds like it would be a better fit for a Profile like module, rather than forced into QR. Even then, the results might be more of a source of trouble than convenience until there is a substantial change in the mobile space.

You are free to try it out; It could work fine in some controlled circumstances.

I'm sorry I can't bring better news.