Integrating automatic form fillers into A+

Hi,

We are looking at integrating automatic form fillers such as lastpass/autofill into our A+ site, as our client wishes to make appointments and manage data on behalf of their clients.

Currently it seems that the input fields for name, email, etc in the booking form are submitted using ajax and lack any of the name/id tags that the form fillers use to identify fields to populate, so this does not work.

Is there any way that we could modify these inputs using hooks within functions.php such that form fillers would be able to recognise them, as we would prefer not to modify the core code?

Regards,
SteveB

  • pxwm

    Hi Patrick,

    Many thanks for the update.

    I was aware of this post and I have downloaded the beta version.

    Before I test do you happen to know if it has any enhancements relating to auto form fillers?

    It is very important that I can find a solution as my client requires the ability to create and maintain a database of their clients using LastPass or similar and then they will use this to populate the A+ form.

    We also have another client that wishes to use A+ and even though they may well allow their clients to book appointments it would be a great enhancement to allow the use of auto form fillers such as LastPass.

    The reason we want to use LastPass is that they offer client data security and is encrypted

    I'm happy to test the beta version but it would be good to know if the functionality we require is contained within the version or if not what options we have in the way of shortcodes to auto fill the form.

    I suppose one option for consideration in the future would be the functionality in A+ to create an encrypted client database that could auto populate the A+ form.

    I suppose one option would be to use the membership plug-in but I'm not sure our clients want their customers to have to register to make appointments and not sure if the membership plug-in encrypts client data.

    Regards
    SteveB

  • pxwm

    Hi Patrick/Vlad,

    Good news.

    We have been checking the appointments.php code in v1.2.8 and identified the part of the code that builds the browser client side appointment form.

    We then amended the relevant lines of code to add an id to each field.

    e.g. original code line 2033:
    $ret .= '<label><span>'. $name . '</span><input type="text" class="appointments-name-field-entry" value="'.$n.'" /></label>';

    we then added: id="my-name" giving:

    $ret .= '<label><span>'. $name . '</span><input type="text" class="appointments-name-field-entry" id="my-name" value="'.$n.'" /></label>';

    We then tested using LastPass, an auto form filler and it all seems to work.

    We would appreciate if you could confirm if adding this field id would cause any problems to the plug-in and if not would it be possible to maybe add to v1.3 that is currently in beta without affecting testing?
    If it does would you consider including in a future release?

    We also looked at the code in the Beta v1.3 and if we have identified correctly you may have added some functionality to add/amend form fields.
    If we are correct and you could add our revision could you please confirm if our revision could be included in the section of code to add/amend form fields.

    Regards
    SteveB

  • pxwm

    Hi Vladislav,

    We have been testing your latest Beta version: appointments-1.3-BETA-3 and it all looks good.

    However could you please confirm if this latest version includes an option to add/revise the name/id in each of the form fields as per your latest post?

    I've checked all the tabs and especially the 'add-on' tab but can't seem to find any reference.

    Has this functionality been added or will it be added before 1.3 is released?

    Regards
    SteveB

  • Vladislav

    Hello,

    The fields in A+1.3-BETA-3 confirmation markup are still nameless, but they have their IDs set. All of the IDs are exposed for filtering in standard WP filter hooks (e.g. in your functions.php, or in a mu-plugin). The filters are named following this convention: "app-shortcode-confirmation-<FIELD>_field_id", where <FIELD> is the actual field purpose, so these are the actual filter names:

    app-shortcode-confirmation-name_field_id
    app-shortcode-confirmation-email_field_id
    app-shortcode-confirmation-phone_field_id
    app-shortcode-confirmation-address_field_id
    app-shortcode-confirmation-city_field_id
    app-shortcode-confirmation-note_field_id
    app-shortcode-confirmation-gcal_field_id

    The processing function attached to any of those filters will receive the appropriate ID as an argument, and is expected to return a string - this string will then be used as your element ID.

  • pxwm

    Hi,

    I thought it best if I re-opened this post instead of creating a new one.

    Is it possible you could ask @Vladislav if the following got added to v1.3 as I can't find reference to this in the changelog in the zip file?

    Also any chance you could update the history log in the plug-in page as currently this is only contained within the changelog in the zip file

    Hello,

    The fields in A+1.3-BETA-3 confirmation markup are still nameless, but they have their IDs set. All of the IDs are exposed for filtering in standard WP filter hooks (e.g. in your functions.php, or in a mu-plugin). The filters are named following this convention: "app-shortcode-confirmation-<FIELD>_field_id", where <FIELD> is the actual field purpose, so these are the actual filter names:

    app-shortcode-confirmation-name_field_id
    app-shortcode-confirmation-email_field_id
    app-shortcode-confirmation-phone_field_id
    app-shortcode-confirmation-address_field_id
    app-shortcode-confirmation-city_field_id
    app-shortcode-confirmation-note_field_id
    app-shortcode-confirmation-gcal_field_id

    The processing function attached to any of those filters will receive the appropriate ID as an argument, and is expected to return a string - this string will then be used as your element ID.

    Regards
    SteveB

  • Vladislav

    Hello,

    Just to confirm, this is indeed already in v1.3. The shortcode handling is a bit refactored now, so the actual code for this is in includes/class_app_shortcodes.php, class App_Shortcode_Confirmation, method process_shortcode(). The list of filters is exactly the same as mentioned above. The actual default IDs follow this convention: appointments-field-customer_FIELD_NAME - so, e.g. "appointments-field-customer_name", "appointments-field-customer_email", "appointments-field-customer_phone" and so on.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.