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.
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.)
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.)
Peekay wrote: ... 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) ...
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.
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.
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.