Unable to change meeting location with latest 3.9.3 update

[marcinyorkpa]

Describe the bug We are running Wordpress 5.5.3 with TSML version 3.9.3

I'm trying to change a location for an existing meeting.

As soon as I change the Address, the "Update" button becomes disabled, and nothing I do will re-enable it.

I'm following the steps I've always followed for updating a meeting location:

1. Open the meeting
2. Change the address to the new address
3. Give that address a name
4. Attempt to click "Update"

I don't see any errors in the JavaScript console.

I've tried in both Chrome and Firefox and the behavior is the same

Expected behavior The "Update" button is enabled, and submitting the form saves the meeting update

In addition, the "Preview" button does not work as well. It's clickable, but nothing happens

Screenshots If applicable, add screenshots to help explain your problem.

Initial screenshot of button after pulling up the meeting to edit

The existing location

Location after editing it. Note that the map update worked as expected

The Update button after scrolling back up to save changes

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome and Firefox
• Version latest versions of Chrome and Firefox

[tech2serve]

Please try these steps and see if it works:

1. Open the meeting.
2. Change the Location name to the new location.
3. Change the address to the new address.
4. Attempt to click "Update".

Put another way, reverse the order or your second and third steps.

[marcinyorkpa]

thanks @tech2serve

I've tried as you suggested, but the behavior persists.

The Update button stays submittable when I change the name, but as soon as I clear the Address field, the button is disabled and never reenables

[tech2serve]

but as soon as I clear the Address field, the button is disabled and never reenables

Just confirming, because I don't want to make an unvalidated assumption, that you mean you clear the Address field after changing the Location, and then you enter the new and geocodable address, but the Publish button doesn't enable again?

While I do believe we have a bug, I'm also finding I can work around it on my site by following the steps I outlined. I'm hopeful we can with yours as well. I suggest continuing to try different combinations of clearing both fields and then entering the new information.

Do you have other addresses to change or is this the only one? Did others work as expected?

[marcinyorkpa]

I took a screen capture to show exactly what I'm doing.

I've tried it on multiple meetings, and by creating a brand new meeting and then changing to a different address. I experience the same behavior each time, and no amount of reordering events seems to get the form submittable for me.

thanks again.

[tech2serve]

In your screencast, I noticed the notification number for some extension you have installed in your browser increased from 1 to 3:

Can you tell me what that is?

[marcinyorkpa]

Yeah, that's LastPass.

I've tried this in a browser window with all extensions disabled, and in Edge where I have no extensions installed, and the behavior is identical across all these different browsers.

Thanks.

[tech2serve]

@marcinyorkpa,

I am looking at code to see how we can rework this and make it more robust. But I'm also experimenting with different workarounds in order to provide you a solution today. Please try:

1. Open the meeting.
2. Change Address to the new address and tab to let the system geocode the address.
3. Change Location to the new location, and tab down to Address.
4. Go to the end of Address and delete USA, then tab to let the system geocode a second time.
5. Confirm both Location and Address as are you want them be.
6. Scroll up and see if Update is enabled. If so, click it.

If this doesn't work for you, then I suspect something particular to your site. If you have a staging site, perhaps load it up with TSML and a set of data, but skip any other plugins you have on your production site. See if the problem exists there.

We've also seen weird problems like this clear up if the website cache is cleared/deleted. This can often be accomplished through your hosting provided c-panel/dashboard.

[machouinard]

@marcinyorkpa

Was this also an issue prior to the WordPress 5.5.3 update, with or without TSML 3.9.3?

One thing you might try is installing and enabling the Enable jQuery Migrate Helper plugin. It's possible some old jQuery code in another plugin could be causing this. The plugin will show you warnings about TSML but I believe those are only related to address lookup which appears to be working without issue.

[marcinyorkpa]

Thanks so much, @machouinard and @tech2serve

I was able to get it working with a combination of adding that jquery migrate plugin and following the back-and-forth steps above.

For what it's worth, these are the errors I see from the jquery migration helper:

This page generated the following warnings:

    https://york-pa-aa.org/wp-content/plugins/12-step-meeting-list/assets/js/admin.min.js: jQuery.parseJSON requires a valid JSON string
    https://york-pa-aa.org/wp-content/plugins/12-step-meeting-list/assets/js/admin.min.js: jQuery.parseJSON requires a valid JSON string
    https://york-pa-aa.org/wp-content/plugins/12-step-meeting-list/assets/js/admin.min.js: jQuery.parseJSON requires a valid JSON string

Now, though, for the address I saved, I'm seeing other weird behavior: On the meeting edit page, the map shows the typical location marker and everything looks fine. But on the published page, the "Directions" box is gone. I've even tried it with different addresses, but none of them will get the "Directions" box back. Here's a link: https://york-pa-aa.org/meetings/humble-beginnings/

I'm mystified. Can you think of anything that would explain this?

Thanks again!

[tech2serve]

We're aware and working the jQuery warnings (#168). These issues may be related and I've been working this tonight.

My suspicion regarding why the Directions box is gone is because the location somehow got flagged as an approximate location. Are you familiar with phpMyAdmin?

[tech2serve]

@marcinyorkpa,

I am increasingly seeing this issue as NOT related to the jQuery warnings. Nor am I convinced the jQuery warnings are actually directly related to TSML (still working that piece). I have tested meeting editing with the jQuery Migration Helper both activated and deactivated, and the results seem to be the same: I am able to edit meetings, and the only form I see a hiccup consistently with is when I edit the address before editing the name in Location. And in that scenario, I'm able to cause the address to geocode a second time and then update the meeting entry.

My suggestions:

1. If you are familiar with, or have access to, phpMyAdmin, I'd like to get a copy of a cache from your site to confirm my suspicion regarding the directions. So if yes, can we set up a time for me to chat you through this?
2. Continue to look at other plugins you have and try disabling them. I did ask above if you had a staging/demo site you could test with? This is often the quickest and most effective way to confirm another plugin as the problem.
3. Alternatively, if you export a csv of your meeting data and email it to me (devs@code4recovery.org) I'll bring it up on my dev site and see if I experience the issue.

Thanks.

[Grateful-Viv]

I tried to duplicate error.

Changed address on staging site and pressed update.

Did not change it.

Then, as suggested, changed the name of the location and the street address. Update held.

However, when I went back to change it to correct location name and street address, the update button is no longer active.

If I revert back to original location, I still cannot change the address (change 201 N Bedford to 201 North Bedford). It will not stick no matter how many times I try to update it.

[marcinyorkpa]

@tech2serve thanks again for your reply. I've emailed you with a CSV and some other answers.

I just tried 2 other things:

1) create a brand new meeting, with a brand new location

• I could not get the Update button to work without having the jquery migrate plugin enabled
• When I did get the Update button enabled, the Map for this new meeting with new location didn't have the "Directions" bits 2) create a brand new meeting, and associate it with an existing location
• this time, the direction bits did show up

Not sure if that's helpful or not. Seems like bottom line is that when creating a new location, it gets a bug in its crawl... some value not set correctly or some such thing

[tech2serve]

Hey @marcinyorkpa,

Sorry for the delay in getting back to you. I got tied up in some other things.

In looking at the data you emailed me, it appears to be correct. This causes me to think something in your site is conflicting with our plugin.

Would you send me a screen cap of the location block on the admin side for the Humble Beginnings 9a Sunday meeting (for which the Directions button isn't show up)?

Also, are you seeing any issues with the Directions in the Meeting Guide app?

[marcesher]

Here you go. Thanks!

Not sure if this is helpful, but: I activated the Query Monitor plugin and tried to see if there were any meaningful differences in queries that run for meetings that work vs this busted meeting (and any new meetings with new locations I create), and one thing I see is that in the query that returns information about the location, the existing good meetings don't have any row at all for is_approximate_location, whereas this busted meeting does have a row for it. Now, the value is false which seems right, so... I dunno. I wonder if it could be a PHP version problem? Our hosting provider is still on PHP 7.2 😬

As for the meeting guide app... nope, that looks good.

[marcesher]

I did a little more debugging and here's what I found.

In the busted meeting, I see this:

["is_approximate_location"]=> string(5) "false"

I then added some code into the single meeting template, and I confirmed that the block starting at https://github.com/code4recovery/12-step-meeting-list/blob/master/templates/single-meetings.php#L52

<?php if (!in_array('TC', $meeting->types) && !($meeting->is_approximate_location)) { ?>

is definitely not getting through due to the !($meeting->is_approximate_location) check

I did that by isolating just that part of the conditional and confirming that, in our Wordpress on php 7.2, that block returns false, i.e. "not approximate" thinks that it is approximate with the value of "false"

In other words, the string "false" is true, and so !(true) is the problem.

Do you think this could be a php version problem?

Thanks again!

[tech2serve]

I think what we need to figure out is why, at least on your site, the boolean is converted to the string. Or, at least that is what Query Monitor is reporting?

But I suspect that is what is happening since I believe php of any version will evaluate $meeting->is_approximate_location === "false" as true, but I need to confirm that.

[tech2serve]

@rs0715 and @marcinyorkpa --

I'm merging discussion regarding the Directions dialogue not displaying into this issue from #217.

Although I think I know what is going on, I'm unable to figure out so far why it is happening to your sites and not others.

Please reply to this comment with:

1. Hosting provider
2. Wordpress and PHP versions
3. Is Enable jQuery Migrate Helper installed and activated?
4. Complete list of other plugins installed. And those that are activated.
5. Whether or not you have a demo/staging site with the same hosting provider and same configuration we can use for testing.

I apologize if some of this is repetitive, but this will help me think of this all in one group,.

Thank you for your help in getting this resolved.

[rs0715]

From: Tech2Serve notifications@github.com Sent: Wednesday, November 11, 2020 8:53 PM To: code4recovery/12-step-meeting-list 12-step-meeting-list@noreply.github.com Cc: rs0715 rich@datarightservices.com; Mention mention@noreply.github.com Subject: Re: [code4recovery/12-step-meeting-list] Unable to change meeting location with latest 3.9.3 update (#208)

@rs0715 https://github.com/rs0715 and @marcinyorkpa https://github.com/marcinyorkpa --

I'm merging discussion regarding the Directions dialogue not displaying into this issue from #217 https://github.com/code4recovery/12-step-meeting-list/issues/217 .

Although I think I know what is going on, I'm unable to figure out so far why it is happening to your sites and not others.

Please reply to this comment with:

1. Hosting provider - godaddy
2. Wordpress and PHP versions 7.3
3. Is Enable jQuery Migrate Helper installed and activated? yes
4. Complete list of other plugins installed. And those that are activated. See attached
5. Whether or not you have a demo/staging site with the same hosting provider and same configuration we can use for testing. no

I apologize if some of this is repetitive, but this will help me think of this all in one group,.

Thank you for your help in getting this resolved.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/code4recovery/12-step-meeting-list/issues/208#issuecomment-725776253 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ARWV2NI7FYAEM5ARSD7FNFTSPM5XJANCNFSM4TGR35JQ . https://github.com/notifications/beacon/ARWV2NLLEX2NLAWVXM3QKWTSPM5XJA5CNFSM4TGR35J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFNBHO7I.gif

[tech2serve]

@rs0715 I’m not seeing an attachment showing other plugins.

[rs0715]

Plugins ‹ — WordPress.pdf

[tech2serve]

@rs0715 Please confirm you've done a test with ALL plugins deactivated EXCEPT TSML and Enable jQuery Migrate Helper. And that during that test, you still did not have the Directions box for meetings that were not location temporarily closed and with a full address?

[rs0715]

All plugins disabled - no luck

Plugins ‹ — WordPress.pdf ss.docx

[marcinyorkpa]

• Hosting provider: iPage
• Wordpress and PHP versions: WP 5.5.3, PHP 7.2.4
• Is Enable jQuery Migrate Helper installed and activated? yes
• Complete list of other plugins installed. And those that are activated: See attached
• Whether or not you have a demo/staging site with the same hosting provider and same configuration we can use for testing: No

I disabled all plugins except TSML, jquery migrate helper, and google API key, and I still see the behavior described above

[rs0715]

any update on this?

[97eighty]

@marcinyorkpa @rs0715 Hi, we're working on reproducing this error. Neither @tech2serve or myself are having luck but we have a few ideas. Is it possible for you to send us an export of your database? We'd like to look closer in to the contents of the post and post_meta tables. Please send to devs@code4recovery.org. Thanks Mark

[rs0715]

See attached backup_2020-11-14-2013_bgf26dmyftpuploadcom_e9bde7520bb7-db.gz

[rs0715]

hello - i restarted my site today along with enabling the api under a different account. Publishing, updating and direction issues seem to be solved. I am wondering though how i can edit and style the meeting this page. I have seen a few sites that have a header or nav bar on that page but i am not sure home to get to it to edit it. Thanks for all your help and info.

[97eighty]

Hi @rs0715

Good to hear you solved your problem. There are several widgets that allow you to place headers and footers on the meeting list page as well as the meeting detail page. I suggest starting there.

[rs0715]

Starting where?

From: 97eighty notifications@github.com Sent: Sunday, November 15, 2020 3:11 PM To: code4recovery/12-step-meeting-list 12-step-meeting-list@noreply.github.com Cc: rs0715 rich@datarightservices.com; Mention mention@noreply.github.com Subject: Re: [code4recovery/12-step-meeting-list] Unable to change meeting location with latest 3.9.3 update (#208)

Hi @rs0715 https://github.com/rs0715

Good to hear you solved your problem. There are several widgets that allow you to place headers and footers on the meeting list page as well as the meeting detail page. I suggest starting here:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/code4recovery/12-step-meeting-list/issues/208#issuecomment-727628825 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ARWV2NMC34AO4UZP4CX2LUDSQAYUZANCNFSM4TGR35JQ . https://github.com/notifications/beacon/ARWV2NPPQUE6ZPSQ443BR7TSQAYUZA5CNFSM4TGR35J2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFNPLYGI.gif

[tech2serve]

@marcinyorkpa, It is interesting that @rs0715 was able to solve the issue on his site. Maybe he'll elaborate more on the steps he took to clear the issue?

I am going to work over the the next couple of days on an update to the plugin that should make the tracking of approximate locations (which, when true, the directions dialog shouldn't show up) more robust. However, no guarantee that it will solve your issue as we've not been able to duplicate it with our databases.

[marcinyorkpa]

@tech2serve perhaps I can help troubleshoot more on my end. Please help me understand something.

In the block that prevents Directions from showing up, looking at this conditional: !($meeting->is_approximate_location)

Since:

• That check requires a boolean
• is_approximate_location in my case is a string
• the is_approximate_location database value is ultimately coming from wp_postmeta, with a meta_key of is_approximate_location and a meta_value of "false", which is a longtext database field type

My question is: What would cause that to ever get turned into a boolean in the first place? I tried following the code but was unable to determine what would convert the DB string data into a PHP bool. I imagine you will be able to answer that quickly and point me to the exact line of code where that happens.

Based on my admittedly cursory understanding of all this, it sounds like the problem is: the code expects a boolean, and you do too, and in your testing that's what you get, so there's something about either our wordpress install, or database, or something, that is causing a difference in behavior from what you expect, related to datatypes in this case. Or, put shorter and more plainly, the question seems to be: Why isn't this value converting to a bool, as you expect?

Perhaps if I see that, I can troubleshoot further from there.

[97eighty]

@rs0715

Sorry. Go into the Widgets area and you'll see where you can place headers and footers for those pages.

Mark

[rs0715]

a screenshot might be helpful, not sure how your getting there, i am using elementor as a page builder but i can use the default also. just not sure how to access the pgs

[tech2serve]

@rs0715, I suggest you search for some Wordpress or Elementor tutorials. This isn't really a TSML issue directly. If you're a member of AA, you might also try TIAA Forums.

[tech2serve]

@tech2serve perhaps I can help troubleshoot more on my end. Please help me understand something.

In the block that prevents Directions from showing up, looking at this conditional: !($meeting->is_approximate_location)

Since:

• That check requires a boolean
• is_approximate_location in my case is a string
• the is_approximate_location database value is ultimately coming from wp_postmeta, with a meta_key of is_approximate_location and a meta_value of "false", which is a longtext database field type

My question is: What would cause that to ever get turned into a boolean in the first place? I tried following the code but was unable to determine what would convert the DB string data into a PHP bool. I imagine you will be able to answer that quickly and point me to the exact line of code where that happens.

Based on my admittedly cursory understanding of all this, it sounds like the problem is: the code expects a boolean, and you do too, and in your testing that's what you get, so there's something about either our wordpress install, or database, or something, that is causing a difference in behavior from what you expect, related to datatypes in this case. Or, put shorter and more plainly, the question seems to be: Why isn't this value converting to a bool, as you expect?

Perhaps if I see that, I can troubleshoot further from there.

I'm pretty sure the is_approximate_location you're seeing as a string is a result of the wp_localize_script call on line 8 of single_locations.php. Javascript does indeed appear to be interpreting the value as a string, but in php we handle is_approximate_location as a boolean. This is set when you enter a new meeting address (if only city and state, is_approximate_location is set to true and written to the database). The conditional you're referencing above is checking if $location->is_approximate_location, a php variable, is true or false. The Javascript side of life is not really important in this case.

When I wrote the 3.9 update, I only stored is_approximate_location in the database if it was true, and didn't store anything if it was false. I did this because I believed that a null value in the database would be read as false. AFAIK, this seems to be working with nearly all of the 400 or so deployments of v3.9.3. In fact, your website is the only known one right now, and it doesn't seem to be happening with all of your meetings. (This is why @97eighty and I thought if we could get a copy of your database, we could load it and see if we can see what is being handled differently.)

Is Humble Beginnings a meeting you first added after your TSML was updated to v3.9.3? And were the other meetings with full addresses in the database before the TSML update? Or, was Humble Beginnings originally just identified by city and state only? And then was changed to be associated with a full address? Are you seeing issues with other meetings? Hopefully this gives you a sense to what we're analyzing. What continues to bewilder us is why this appears to be only happening with the one meeting? My guess is that when we figure out the true cause of the anomaly on your site, we'll have found the real bug.

I'm grateful for your patience and willingness to work with us.

[tech2serve]

• the is_approximate_location database value is ultimately coming from wp_postmeta, with a meta_key of is_approximate_location and a meta_value of "false", which is a longtext database field type

Hey @marcinyorkpa, I missed this above. You are correct that is_approximate_location is stored in wp_postmeta. Are you saying your database (perhaps you're using phpMyAdmin?) shows the field time as longtext? Or, how did you determine this?

I'll need to confirm in my database.

[marcinyorkpa]

@tech2serve that is all very helpful in further isolating the problem.

To answer your questions:

This was an existing meeting, but I had changed it to a new location, which I had just added.

I also tried adding a new meeting, with a different new location, and I saw the same behavior on the meeting screen, with the Directions box not appearing. I then looked in the database and see that it, too, has "is_approximate_location" : "false"

So now it seems the next debugging question is: Why would the code save it if it's false, when you intend it to only save when it's true?

I took a look at the code and, same caveat as before, this is all new to me so I'm pretty much just floundering in the dark here, but when I look at this line:

https://github.com/code4recovery/12-step-meeting-list/blob/master/includes/save.php#L247

It doesn't look like there's any logic that keeps it from saving either a true or a false... it just takes whatever's in the form post and stores it.

I then looked at the geocode code, and then at the form details to see what happens when creating a new Location, and I see that when I add a new location, the is_approximate_location hidden field does get set to false... see the screenshot

So based on my limited understanding of the code, it sure looks like the behavior I'm seeing matches what the code is written to do... 1) stick a value in the hidden field, which comes from geocoding, 2) save that value, regardless of whether it's true or false

And then the behavior I see on the meeting page -- with the Directions box not showing up -- also matches what it looks like the code was written to do.

The thing I don't understand is: how is this working in everyone else's? !

Thanks again! This is a fun puzzle.

[marcinyorkpa]

I also wondered if perhaps the reason it was behaving differently on our site is that I had to add the jquery migrate plugin just to get the "Save" button to work in the first place -- the thing that started this whole thread -- but I just disabled that plugin, tried adding a new meeting with a new location, and confirmed that the is_approximate_location hidden field does get populated as false in that situation, too (though the save button is still disabled:) )

[tech2serve]

Lots of good points here. Thank you.

You're correct that with new meetings, or updates which trigger the save.php logic, the is_approximate_location is stored, and it should be regardless of the value. However, the database updater logic that executed when users migrated to v3.9 series of the plugin only wrote is_approximate_location if the location was determined to be approximate (i.e., city and state only). You can see this in the database_updates.php file.

But this ambiguity that you're alluding to is precisely why I intend to write an update that sets the is_approximate_location in the database for every entry, regardless if it is true or false. Part of my concern is that we don't really know how some of the Wordpress functions are handling the boolean when the initial value may not exist in the database. On the other hand, even your inspections of the final value on the website seems to indicate it is being handled correctly.

I'm further confused by the the fact that this issue continues for you even when you're adding new meetings. So I think it remains worthwhile to explore your database if you can email a copy to us (@97eighty).

Also, any chance you could ask you hosting provide what version of MySql they are using for your sites?

[marcinyorkpa]

Hi @tech2serve . Just emailed you a full database dump. Thanks again for all your work!

[tech2serve]

@marcinyorkpa,

Please confirm TSML v3.9.4 resolves the approximate location issue you were experiencing.

[marcinyorkpa]

@tech2serve thanks so much for all your work on this and for sticking with it.

I can confirm that the approximate location issue is fixed, and meetings now correctly show the "Directions" button on the meeting screen.

I can also confirm that the "Update button" issue which started all this is still present, and only resolves for me by installing the jquery migrate helper plugin.

Do you have any idea what might be causing that?

thanks!

[tech2serve]

Has your Wordpress site updated to version 5.6?

I would also try the old “deactivate all other plugins and see if the problem persists”. It could be that something else is causing a conflict.

If those don’t help, let’s start looking again for new errors in the console?

[Grateful-Viv]

Yes. No problems detected. Thank you.

On Sat, Dec 19, 2020 at 6:14 PM Tech2Serve notifications@github.com wrote:

Has your Wordpress site updated to version 5.6?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/code4recovery/12-step-meeting-list/issues/208#issuecomment-748538057, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO25D7KPRCFE6QXWTBQ5E33SVUXURANCNFSM4TGR35JQ .

[marcinyorkpa]

Hi @tech2serve

I updated our site to WP 5.6 today, and now the location editing behavior is worse than before, in that even with the jquery migrate helper plugin enabled, I can't get the "Update" button to work when I add a new location.

I'm attaching a few animated gifs to show the behavior, both with and without that plugin installed.

Can you give me a pointer to finding the javascript code responsible for disabling and re-enabling the "Update" button? I tried figuring it out myself, but have so far been unsuccessful. I tried getting Firefox dev tools to break on a change to the button so that I could follow the code, but I'm clearly doing something wrong because I can't get it working. Thanks for any tips to help me debug the javascript.

with jquery migrate installed and activated

with jquery migrate deactivated

[tech2serve]

Hey @marcinyorkpa,

I appreciate your frustration. Here is what I can tell you from Code for Recovery's work. If you're on Wordpress 5.6 with PHP 7+, and you're using TSML 3.9.4, you should not need Enable jQuery Migrate Helper. This doesn't mean other plugins you have installed aren't conflicting or requiring the Helper. But, from our perspective, with 3.9.4, you don't need it.

It isn't clear from the second gif if the map showed up during the geocode?

Before we proceed with in depth troubleshooting, please test a setup with all other plugins disabled (including Enable jQuery Migrate Helper) and TSML v3.9.4 installed. If the problem persists, reset cache for the server and your browsers. If the problem persists, make sure you haven't made any other modifications to the site (if you're running a child theme, please post the mods here).

If after that, we're still seeing frequent issues with reactivation of the Update button, I'll want to start by getting a detailed description of the setup.

[marcinyorkpa]

@tech2serve OK, I think I'm getting somewhere. But where I've gotten is a complete head scratcher to me.

First, I was able to get a copy of my site running locally... both the entire wordpress install, all configs, and a database export. The one thing I can't exactly replicate is whatever the hosting company configures via their php.ini and whatnot. Not sure how important that is right now.

Second, I cannot replicate the problem locally, as you expected. Everything works just fine.

Third, I was able to add a bunch of debugging to isolate where things to awry. So I've learned some things, but I've hit a wall.

In short, things go wrong in the admin.js's tsml_address ajax call. I don't know why this is, but that ajax call gets an empty (zero byte) response. I added a fail() to see the error, and I see:

tsml_address Request Failed: parsererror, SyntaxError: JSON.parse: unexpected end of data at line 1 column 1 of the JSON data

which is basically just "empty response"

Now, to try to figure out the empty response, I added some error_log debugging into ajax.php's tsml_admin_ajax_address function.

What I've observed is that when that first condition trips... the one that just return array(), that's when I get the empty response. This makes sense because presumably that's the condition for a new location, i.e. one that doesn't yet exist. Interestingly, locally, this returns 0 and not an empty response.

When the second condition trips, the ajax call works fine, which is why existing locations result in the "Update" button getting reactivated.

So now I've reached a point where I just have no idea why that code would result in an empty response, especially when I can't replicate it locally with the same code and database.

When I ask myself, "what's different in my real site vs local", the things I think of are:

1. hosting php.ini vs. the default php.ini from the wordpress docker image
2. prod runs ssl whereas local doesn't
3. prod has a big of fiddly code in wp-config.php to switch database user, to get around a hosting company queries-per-hour limitation; but I removed that code just to rule it out and it didn't make a difference

I don't see anything obvious in the debug.log file on our real site, nothing that clearly indicates an error. Which leads me to suspect that the empty response is happening in the transport layer, or possibly in WP's apparatus that sits on top of the TSML ajax.php. 🤷

Even when I just hit the URL directly in a browser, for example https://york-pa-aa.org/wp-admin/admin-ajax.php?action=tsml_address&formatted_address=705%20E%20Market%20St%2C%20York%2C%20PA%2017403%2C%20USA -- i.e. not just trying to troubleshoot ajax calls in dev console -- I get the empty response. But not locally.

So: ever see anything this whacky before? I'm going to start googling around for wordpress admin-ajax.php empty response and see if I find anything.

I fully anticipate a big head slap for myself once we figure this out!

Again, I can't thank you enough for how persistent you've been in sticking with me on this. I've worked on open source software for over a decade, and I know how thankless it can seem and how like 95% of the problems you support are problems with other people's setup. I really, really appreciate all your work and help!

[marcinyorkpa]

@tech2serve one other thing I see in the debug.log but I honestly can't tell if it's related:

[21-Dec-2020 21:32:59 UTC] PHP Notice:  Undefined index: types in /wp-content/plugins/12-step-meeting-list/templates/single-locations.php on line 77
[21-Dec-2020 21:32:59 UTC] PHP Notice:  Undefined index: types in /wp-content/plugins/12-step-meeting-list/templates/single-locations.php on line 79
[21-Dec-2020 21:37:07 UTC] PHP Notice:  Undefined index: types in /wp-content/plugins/12-step-meeting-list/includes/shortcodes.php on line 27
[21-Dec-2020 21:37:07 UTC] PHP Notice:  Undefined index: types in /wp-content/plugins/12-step-meeting-list/includes/shortcodes.php on line 40

[97eighty]

Hey @tech2serve @marcinyorkpa I've been following this a bit and finally have some cycles to help out. Where do you need me. @marcinyorkpa I know this is probably answered but I picked up something from another support issue. If you wait for a few minutes does the update button work? I'm happy to pull your meetings into an online test build if you think it will help eliminate some of the things to check out.