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!

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.

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.

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!

Quote:

I pulled 2.5.6 from SVN and things are working quite well. Fresh installs in both PHP 5.3.10 and 5.4.6 went smooth. Comments are back and functional. After running both installs through a variety of activities, the logs are clean of messages coming from XOOPS itself. (Wish I could say the same for all of my code ;)

The only curious thing under 5.4 was that logger shows this message on the admin preferences general settings:
Notice: Array to string conversion in file /class/xoopsform/formhidden.php line 78

It is just on general settings, but it is consistent. It doesn't seem to cause any obvious problem.

Overall, two thumbs up from here!

I tossed 2.5.6 beta1 into a couple of environments and tested a bit using a current project as the base. This was a quick run thru, not an exhaustive coverage test, but here are the results.

Using 2.5.6 beta1 to upgrade a 2.5.5 system under PHP 5.3.10 went smoothly. No issues.

On fresh install with any PHP version, the xoopscomments table is missing.

On PHP 5.4.6 and 5.4.11, this message shows up in the logs a lot:
PHP Strict Standards: Only variables should be assigned by reference ... kernel/object.php on line 374

Overall, seems pretty solid - great work!

Thanks for this! Over the weekend I was able to play with XOOPS running entirely on an Android tablet. The php version involved was 5.4.8, and this took me from a 2.5.5 that didn't really even install correctly to what seems to be a fully functional system. This proof of concept paves the way for some very intriguing possibilities.