Mark

That’s something that hasn’t crossed my mind to test for until now. Thank you for bringing it to my attention!

I don’t have an immediate solution for you, but I’ll look into this as soon as I get a chance.

There’s absolutely no reason you should have lost that original data.

Something is severely wrong for that to occur, given that the lite plugin only reads from those tables; it does not in any way try to alter, update, or delete them. In my testing I successfully ran the upgrade on databases with a dozen entries up to one with a few hundred.

Again, there’s nothing in the code that modifies that original data. So I’m at a complete loss for the moment as to what to suggest.

The only reason I could see your site staying in maintenance mode that long is due to the process timing out, or something killing it prematurely, keeping it from running the command to disable maintenance mode. I’ve got a couple ideas how to avoid that in future releases that I think I’ll go play around with…

Is there any backup you have which has the original business directory tables? There should be three of them, wp_lddbusinessdirectory, wp_lddbusinessdirectory_cats, and wp_lddbusinessdirectory_docs, keeping in mind of course that the wp_ prefix may be different of course. If you can get them, I would like to be able to test the plugin against them.

There’s multiple issues here.

Unfortunately all of my inputted businesses disappeared. I can live with that as they can be resubmitted.

They should not have disappeared, one of the first features I built in to this new version was an upgrade path. The old plugin was using some very rudimentary private tables to store it’s information, the new plugin benefits from custom post types and taxonomies (storing all its information alongside the rest of your posts and pages).

Until the plugin comes out of beta it doesn’t remove any of this old information. Once it’s out of beta I’ll add a tool to ask if you want this information removed, but until then it’s left 100% intact.

I’d like to know why it’s not upgrading for you. If you’re not too invested, could you try deactivating and deleting the lite plugin, then reinstalling it? Your site may go into maintenance mode for a moment, don’t worry about that. Let me know if it still fails to import all your listings.

Where is the map info pulled in from, there is no set field when creating a listing, so assume it is from the address fields themselves?

It is from the address fields, yes. They are glued together in ldl_get_listing_meta() and then sent to be geocoded via Google Maps geocode API.

The listings won’t generate geocode information if anything is missing from the address (with the exception of an Address Line 2 as this is rarely used). So if you’re short a zip code, or it doesn’t have the region, it will bail.

In your case it looks like the geocoded elements are missing (the content of the LatLng() call). I just added some more stringent error checking to the development branch on that, but I’m curious if something else isn’t causing a bug for you. Do all your addresses include all elements short Address #2?

Also have the Special Offers element been removed completely now?

No, the data is still there, but I had originally decided to disable this until the users front end interface had been built (where people could log in and manage their own listings). It’s use seems to be prevalent enough that I need to turn it back on asap, even if it’s only managed through the dashboard. I’ll try and bring this back online with the next version bump.

LordZed, this particular thread is already considered resolved. If you could post the details (WP version, plugin versions, etc) to a new thread, I would be happy to help.

I’m pretty sure that’s a new problem altogether, at least I haven’t seen it come up before now.

I can see where the issue is happening, and I just fixed it for the next version release. I was hoping to get it out in the next three days but I’ll try and speed it up to today if I can.

Check your wp-config.php file and see if WP_DEBUG is set to true (or 1). If it is, set it to false (or 0). That should disable output of error messages (error messages are great for development and staging, but are better disabled in a live environment except for diagnosing issues). Once warnings are suppressed the plugin should work okay until the update comes out.

I saw this happening locally too, after I originally responded.

It’s been fixed in the development branch and should be released with the next version (0.5.3 as of right now). I’m trying to run through and test everything before it goes on WordPress.org, but I would tentatively say it should be out within the next 72 hours.

wp_is_post_revision() returns, according to the codex:

False if not a revision, ID of revision’s parent otherwise.

The concept was that given the parent post ID it would use that as the basis for generating the shortlink. Back in the day I decided to go that route as a failsafe to make sure the link was being generated, and since it never generated links for revisions in any of my tests, I assumed it was working across the board.

Going forward, if wp_is_post_revision() returns anything other than false it will exit out of wp_generate_shortlink(). I’m curious why it wasn’t successful in using the parent ID, but that’s an issue for another day.

Well that’s bloody interesting.

Now that we know that (it works in 1.0.1) maybe I can figure out what I changed… it hooks to the same filters, so it’s not that.

Sorry for the slow response time, it was a busy week at work.