Feedback on 5.4.4.3, the 2. beta of 5.5

5. It should be possible to determine which search fields are shown as advanced fields and which are displayed all the time. Currently the fields are preset to be in the basic always-visible group or in the advanced, hidden-by-default group, and the only option is to either show them in that designated group or not to show them at all.

For example we might want to display Categories all the time and move the geo “Near…” field to be an advanced one.

Current options

Enable advanced fields? – Yes/No
Hidden by default? – Yes/No
Enable field 1 – Yes/No
Enable field 2 – Yes/No

More flexible options

Display field 1 – Always/As an advanced field/Don’t display
Display field 2 – Always/As an advanced field/Don’t display

As you can see, this also makes redundant the options to show/hide advanced fields and hide/show them by default, simplifying the settings. The only downside I can think of quickly is that this requires reworking the template to first print the HTML for all Always fields and then for Advanced fields, if any. As the search fields already have their own templates, this should be doable in a reasonable time:

foreach( $always_fields as $always_field ) {
  em_locate_template('templates/search/'.$always_field . '.php',true);
}
if( !empty($advanced_fields) ) {
  //show the advanced search toggle and open the container
  foreach( $advanced_fields as $advanced_field ) {
    em_locate_template('templates/search/'.$advanced_field .   '.php',true);
  }
  //close the container
}

6. The post informing of 5.4.4.3 shows the smiley icon as stretched. Firefox properties for it state “15px × 15px (scaled to 620px × 620px)”.

7. We weren’t able to get the geo proximity search to do anything. If we type something in there, no dropdown appears, and when we submit the search, the results are the same with an empty string or any string in the geo fields. What could be the cause?

The events-search.php and events-list.php templates are the default 5.4.4.3 ones. We have tried the proximity search with locations and towns that our site has as well as those that produce a dropdown result on the demo site, such as “cal” for california. It seems that whatever loads the dropdown list on the demo site isn’t working at our end.

As an additional piece of information, we tried setting the form to use GET instead of POST. That shows an URL of type ?action=search_events&em_search=&geo=oulu&near=category=11&country=FI. Even if we fill the same value, eg. “oulu” for the attribute “near”, nothing changes: all events are displayed regardless of their location.

Whilst the feedback is appreciated, it’s a headache to answer so many questions in one thread, in the future seperate threads per topic is better pls.

1. are you sure that’s not a customization you made? I can’t find mention of that class in previous versions either

2. not sure what you mean here… grouped events have an entirely seperate template now.

3. will consider for future updates (I agree), but this time round we’ll have to assume developers read our blog posts ??

5. Will look into that. Nice idea but if it’ll delay releasing 5.5 (we’ve pushed it back enough already) then it may have to wait.

6. fixed ??

7. geo doesn’t work with a name, it works with coordinates (the near attribute) in the form of 123,123 which is determined by the Google JS. We do have plans on adding text-geo searching but it may even come in the form of another plugin. If you have issues with that please supply a link in a new thread and I could take a look.

Sure.

1., 2. & 3. Could have written these better, these are basically the same thing. There was an issue and it would have been resolved with noticing that earlier. Giving a notification about that for certain users when updating might save you time in terms of support tickets. In my fantasy it would be this easy in pseudocode:

if ( upgraded from 5.4.4 or earlier to the current version && custom events-list.php && default event list setting is grouped && haven't dismissed notice ) {
  show notice in wp-admin with a link to dismiss it;
}

The update in 2. was that the issue was resolved, originally possibly cache-related.

7. New thread: https://www.ads-software.com/support/topic/getting-near-geo-search-to-work-in-5443

Marking as resolved.