Released: Street Address Fieldtype + Inputfield

[netcarver]

@thlinna I have not tried this in FormBuilder yet, though I have tested it in a Repeater Matrix setup. I also know it is not yet compatible with being placed in the User template and accessed by a user from the Profile editor - though when editing the user page from the normal page editor, it works just fine. 

@adrian Thanks for the script example!

[thlinna]

@netcarver Ok! If someone with more experience with PW and FB could test the compatibility that would be really nice. I was not able to get it working as I would have expected, but I am not in position to evaluate if the problem is between the chair and the keyboard or could it be a bug.

[netcarver]

I think current incompatibility is more likely than a PEBCAK issue. ?

[adrian]

I have my doubts it will work with FB - I know I had quite a few issues getting my Phone field working. I think in general multivalue fields need some tweaking to work. I eventually got Phone almost totally supported though.

[netcarver]

@thlinna it's definitely a compatability issue. I will need to research how to get this working with FB. Could take a while.

In the meantime, version 1.0.5 is out.

 

[adrian]

2 minutes ago, netcarver said:

@thlinna it's definitely a compatability issue. I will need to research how to get this working with FB. Could take a while.

In the meantime, version 1.0.5 is out.

 

Might save you a little time by taking a look at my changes for the phone field here: https://github.com/adrianbj/FieldtypePhone/commit/bc87e50341f62da6b75de9c79e4ac4574517e49a

I think there might be some more changes above, but that's the start of them.

[adrian]

This discussion might also be useful: 

 

[netcarver]

Thanks to @matjazp, I've just pushed 1.0.6 which allows you to include the destination country ISO in the output if needed.

[netcarver]

On the to-do list for the next version, is localisation of the input and output country names in the country select list (again thanks to @matjazp). To do this, I plan to release a module that I wrote for a different project back in 2014, but never got around to publishing: LibLocalisation. (It needs a little tidy-up first, as PW has progressed a long way since I first wrote it.) This module allows simple localisation of country names, language names and currencies. The Street Address module will leverage this, if it happens to be installed, to display the select list of countries in the language being used by the user's browser - and to localise the destination country name into the language(s) used in the origin country as this is the language that postal workers in the source country will be used to. There will be extra config options to control this.

Following that, I plan to work on @thlinna's request to make this work with FormBuilder.

Update:

 

[netcarver]

@thlinna I have my development copy using LibLocalisation and working with Form Builder now - though it needs some more testing on my part. I'm also not 100% happy with the config controls for the localisation yet, so I'm going to wait a week or so before I release it.

[videokid]

Hi,

I decided to try this module ... so far no luck

Compile Error: Default value for parameters with a class type hint can only be NULL (line 74 of /home/public_html/site/modules/FieldtypeStreetAddress/StreetAddress.php) 

Also, I got this notification:
Failed module dependency: InputfieldStreetAddress requires JquerySelectize

However, after installing jquerySelectize the error didn't go away...

I hope this is somehow some useful information.
 

[netcarver]

@videokid

Thanks for the report, what version of PW and my module are you using? Also, do you have Form Builder installed?

[videokid]

@netcarver

No problem... 
This is an upgrade from PW 2.7.2 and is now PW 3.0.114 [latest dev]
FieldtypeStreetAddress version 1.0.6

I do NOT have Form Builder installed.
 

[matjazp]

Just to add my experience: on the installation, I also got the warning that InputfieldStreetAddress requires JquerySelectize. When installing JquerySelectize, I got:

PHP Notice: Undefined index: forceLoad in ...\modules\JquerySelectize\JquerySelectize.module:127

This is probably a problem with JquerySelectize, but the error went away after a few submits (or maybe modules refresh?) so I didn't bother with that.

[gebeer]

Hello @netcarver and thank you for that great module.

I just installed v1.0.6 on a brand new PW 3.0.98. Did not get any warnings during install that it requires jQuerySelectize. It is listed in the dependencies of the InputfieldStreetAddress module, though. Then, of course, I got a JS error because selectize is not available.
When I click on the JquerySelectize module link in the InputfieldStreetAddress module info section it says 'Session: unknown module'
So maybe that module was part of the core before? Anyways, after installing the JquerySelectize module from the modules directory, everything is working fine.

However, it would be nice to get a warning on install and on the module page if the selectize module is not yet installed.  

[gebeer]

Sorry @netcarver to be bothering again.

When I try to search in ListerPro for a subfield (e.g. locality) with "Contains Text", I get following error: Operator '%=' is not implemented in FieldtypeStreetAddress

Guess this has something to do with how the module is setup. I had this once in my own custom address fieldtype (that has never been published as an official module). But unfortunately I don't know the exact solution to this problem. But I just found a pointer towards a solution in Ryan's post here. 

Hope you can sort it out. Would be nice to be able to search for partial strings within the subfields.

[netcarver]

Hi All,

I realise there is work that still needs doing on this module. This includes supporting a full set of selector operators and publishing the support for use in Form Builder. Unfortunately I'm buried deep in some non-PW development at the moment and can't put the time in that's needed, this also explains my absence from the forum for the past month. It is on my radar though and I'll get back to it when I can - probably in late Jan. ?

[netcarver]

Hello all,

I've just pushed a rather alpha version of this module to a new branch on github. The localisation branch adds a few new features that might be of interest.

1. Update default countries list (in English) with names from the country-list project.
2. Use LibLocalisation (if installed) to localise country select lists in the Inputfield.
3. Allow localisation of config and inputfield select lists to the language of the user's browser.
4. Switch to storing ISOs in uppercase, can still handle stored lowercase ISO codes.
5. Unify country list loading code.
6. Detect changes to input address when saving page.
7. Add compatibility with FormBuilder.

You'll need to do a manual update from the new branch to try this out. Backup first please.

I'm pushing this now in its alpha-state, as I've had a few health problems recently and don't want to hold off making this available any longer.

[netcarver]

On 12/9/2018 at 9:49 AM, gebeer said:

Sorry @netcarver to be bothering again.

When I try to search in ListerPro for a subfield (e.g. locality) with "Contains Text", I get following error: Operator '%=' is not implemented in FieldtypeStreetAddress

Guess this has something to do with how the module is setup. I had this once in my own custom address fieldtype (that has never been published as an official module). But unfortunately I don't know the exact solution to this problem. But I just found a pointer towards a solution in Ryan's post here. 

Hope you can sort it out. Would be nice to be able to search for partial strings within the subfields.

@gebeer

Could you try replacing getMatchQuery(...) in FieldtypeStreeAddress.module with the following and let me know if it fixes things for you...

    public function getMatchQuery($query, $table, $subfield, $operator, $value)
    {
        $subfields = StreetAddress::getAddressFieldNames();
        if ($subfield == 'country_iso') {
            $subfield = 'data';
        } else if (in_array($subfield, $subfields)) {
            $subfield = 'data_' . $subfield;
        }

        if ($operator == '%=') {
            $ft = new DatabaseQuerySelectFulltext($query);
            $ft->match($table, $subfield, $operator, $value);
            return $query;
        }

        return parent::getMatchQuery($query, $table, $subfield, $operator, $value);
    }

 Thank you.

[adrian]

6 hours ago, netcarver said:

I'm pushing this now in its alpha-state, as I've had a few health problems recently and don't want to hold off making this available any longer.

Hope it's nothing too serious and you're on the mend.

[gebeer]

On 2/1/2019 at 5:32 AM, netcarver said:

Could you try replacing getMatchQuery(...) in FieldtypeStreeAddress.module with the following and let me know if it fixes things for you...

Is working like a charm ? Thank you!

[netcarver]

Great, thanks @gebeer , I've added that to the codebase locally and it should be in the next release.

@thlinna and anyone else using this module, could you please try out the localisation branch in Form Builder and let me know what works (or not) for you - I'd appreciate some feedback before merging these changes into master. Please also try it with LibLocalisation if you want to make use of localisation of the country names in the country select lists and resultant formatted address.

Many thanks.

[modifiedcontent]

I need some kind of address field type to store street addresses for events -  the map marker modules produce unusable garbage addresses...

This module looks solid and probably does what I need for my case. Why does the module assume it will be used for postal mailings? Is that really necessary?

Couldn't the UX be a bit more usage agnostic and use the regular admin fonts etc.?

[netcarver]

@modifiedcontent Thanks for the post.

Quote

Why does the module assume it will be used for postal mailings?

Circular answer: It assumes it will be used for postal mailings because that's exactly what it was developed for. It was something I wrote for myself and a charity I'm involved with. Ironically, we use it for postal addresses that appear in other places, not just printed matter, including emails. Works just fine.

If you need to prevent the address-label-like format preview, you can simply turn it off in the field settings.

Quote

Is that really necessary?

Not sure I understand. As all address subfields are accessible via the api, you can easily pull any, and format them as needed for whatever purposes within your own templates or hook functions. 

Quote

Couldn't the UX be a bit more usage agnostic and use the regular admin fonts etc.?

As I pointed out earlier in the thread, this was written as a compromise between straight textarea input and a form based approach. I've never come across an address input field that I actually liked - until I wrote this one.

I am open to considering a PR that allows different skins for the module, if you're interested in helping. Otherwise I can only suggest customising the CSS file that appears inside the module if you'd like to revert to the default fonts/inputfield look. You could also try switching the input of the field over to the "Fixed data table" option under the Select Input Format section of the settings, to see if that suits your requirements better.

 

[modifiedcontent]

13 minutes ago, netcarver said:

Not sure I understand ...

To me the beauty of Processwire is that it makes no assumptions how you use it. This module breaks with that logic a bit, probably unnecessarily.

I have started editing the css. That is no big deal. I'll look into how to use this field as input for the map marker modules, make them work together.

btw, I hope your health problems are under control. Either way, take care.