pglewis

Let’s trace this back from the main error message: “Cannot read property ‘url’ of undefined”. That would be coming from here:

https://github.com/pglewis/wp-liveracers/blob/15485d0/scripts/wp-liveracers.js#L26

There should be a global Javascript _lr object and _lr.url should hold the league’s LiveRacer URL. The _lr object should be created in a script tag directly above the div that holds the widget itself:

https://github.com/pglewis/wp-liveracers/blob/15485d0/wp-liveracers.php#L107

The error basically says the _lr object doesn’t exist, however. My first guess was maybe the widget area was inside an iFrame in your theme or something like that but I don’t see any such thing checking your page.

The first thing I’d do is manually double-check that _lr is missing from the console in Dev Tools (Chrome), Firebug (Firefox), or whatever your browser uses to get to the Javascript console. Just type _lr (note the leading underscore) and hit enter and see if it is undefined. If so, you’ll want to check the page source where the widget is inserted and see if the script that defines _lr exists.

• This reply was modified 5 years, 12 months ago by pglewis.

I apologize for long delay, my excuse is that I don’t seem to get email notifications on new support posts. This plugin isn’t super active, being a niche, there’s not a lot to break, and it has been stable for ages so I haven’t been checking in here very often.

Excuses aside I will still support the plugin. Let me know if you still have issues and haven’t found a workaround and I’ll play around based on the info in your post and see if I can reproduce the problem.

This will work for now and is the info I was going to include for you before you did the legwork yourself.

Be advised that Gutenberg has a react-based DateTime component and we will almost certainly be switching to that for 2.8. I need to dig up the GH issue they had for that new-ish component, last I looked several weeks back they had a lot of things to do still.

www.ads-software.com/gutenberg/handbook/components/date-time/

• This reply was modified 6 years, 1 month ago by pglewis.
• This reply was modified 6 years, 1 month ago by pglewis.
• This reply was modified 6 years, 1 month ago by pglewis.

I haven’t heard any reports of this, we would need more information in order to try to duplicate what you’re doing. I’m unsure if this is something that worked before or broke on update, if this is a brand new custom post you created or if you’ve been using it without issue before this.

We can provide better triage and tracking if you want to create an issue on GitHub with more details: https://github.com/pods-framework/pods/issues

Latest branch is ready to be tested again and I’ve double-checked that it does not generate a fatal error this time around.

If you have a local or dev server I would still recommend testing there first. At the very least be sure to make a backup of your production database first, better safe than sorry always.

Sorry about that, a typo my IDE didn’t save me from. I’ve pushed a fix just now which should get merged into the latest branch soon.

This is ready to be tested on the 2.x branch in GitHub.

This should be ironed out in the 1.0.1 release. The problem was introduced via the one tiny, blind change I made without testing right before the www.ads-software.com release. Let that be a lesson, kids.

Definitely a silly mistake. I’ve corrected it in the GitHub repository: https://github.com/pglewis/wp-liveracers

I’ll update the release here as soon as I get a moment to jump through all the hoops required to do so.

Sorry I didn’t get back to you sooner, if I was emailed about the activity it must have gotten buried. I’ll have a moment to take a look at this in a few days. You might check dev tools / firebug console to see if there are any javascript errors showing up that could be a indicator of an issue too. We’ll track it down.

Glad you were able to get it ironed out. That URL param is definitely handy when you start troubleshooting more complex queries.

I’m not sure right off the bat. Try adding ?pods_debug_sql=1 to the URL (or &pods_debug_sql=1 if there are already URL params) to see the exact query Pods is running. That should give some insight.

On problem 2: I think it should be product_gender.meta_value

There is a very handy chart for these situations here:

https://pods.io/docs/code/pods/find/

The first column, 4th row of the table at the bottom of the page covers your scenario.

try: CAST(product_price AS DECIMAL) in your orderby

Post meta is always stored as a string since meta_value is a longtext field in wp_postmeta. Casting it to a decimal type before the sort should work around that.

CAPCHA isn’t a single implementation; there are so many ways to go about it.

I would vote for this as an external plugin to provide the field as I think the implementation is too wide-open to put in core.