Closed jedimonkey closed 3 years ago
oh, we are using the latest version - 4.0.2. Here is a listing of other software versions:
Application Info PHP version 7.4.14 OS version Linux 4.19.121-linuxkit Database driver & version PostgreSQL 13.1 Image driver & version Imagick 3.4.4 (ImageMagick 6.9.10-23) Craft edition & version Craft Pro 3.6.8 Yii version 2.0.40 Twig version v2.14.3 Guzzle version 7.2.0 Plugins Colour Swatches 1.4.1.1 Embedded Assets 2.5.1 Feed Me 4.3.5.1 Freeform 3.10.8 Google Maps 4.0.2 Mix 1.5.2 Navigation 1.4.14 Plural 2.0.0 Query 2.0.3 Redactor 2.8.5 Redactor Anchors 1.1.0 Redactor Custom Styles 3.0.4 SEO 3.6.7 Smith 1.1.12 Super Table 2.6.7 Timetable 3.2.1 Validateit 1.0.3
Aha! worked it out. We originally had a supertable with an smartaddress field in it. But we found that we couldn't use the proximity searching functionality with it nested in the supertable, so it was added as it's own seperate field. As the client had already started some data entry, we held off removing it. So there lies the issue the second field nested in the supertable, I've rolled everything back, removed the superfluous field from the supertable and performed the upgrade to googlemaps. No longer having that sql error.
Ok cool, glad you got it sorted out! 👍
We have a project that is about to go live, and we have it working using the Smart Maps. Just noticed it's discontinuation so trying to swap our logic over to this plugin. However, we have a weird bug that I can't seem to determine how it's occurring.
We have a section with an address field on it, and trying to perform a proximity search on it. As soon as the element query is executed we have an SQL error:
The twig to generate it is pretty simple:
{% dd([craft.entries.section('centre').address({ target: {lat: -31.9523123, lng: 115.861309} }) | length]) %}
The issue is clearly the double left join:
I've traced the code and can't determine why it's calling AddressField->modifyElementsQuery twice, which calls the ProximitySearchHelper::modifyElementsQuery. It either needs a check to determine it's being added already, or work out why the duplicate request is occurring.
We are using Postgres, so maybe there is a bug with the postgres side of things?
Here is a dump of the Entry Query which to me looks okay: