yinxingmaiming

As of 2022-12-24:

Elementor supports PHP 8.0.x.

Elementor does NOT support PHP 8.1.x (reasons not disclosed)

This is truly a bizarre thread. I am likewise having issues and I have the same question. Let’s keep it simple:

1. Does Elementor / Pro support 8.0?
2. Does Elementor / Pro support 8.1?

Actually, I’ll you test it and put a tested fix into your GA product. The pull request title Database optimizer now handles postmeta when cleaning revisions is a little concerning, as it suggests that your team had not even considered postmeta records in your original design. The posts-postmeta relationship is a fundamental structure in WP – I’m now concerned about what else may be missing.

But thanks for updating the status.

In my experience, a 500 error is a server error, not an Elementor-specific error. You might want to check with your web hosting service and ask them to check their logs.

Elementor can be resource intensive and you may have inadvertently triggered a resource limit error.

• This reply was modified 2 years, 3 months ago by yinxingmaiming.

You clearly do NOT understand the issue.

There are two tables involved in purging revisions: posts and postmeta.

– the posts table contains the revision header. For the third time, the post record is being correctly deleted.

– the postmeta table contains all the revision detail records. And for the third time, your plugin is NOT properly deleting these records.

The complete sql should include sth like:

DELETE FROM xxx_postmeta postmeta

LEFT JOIN xxx_posts posts ON posts.ID = postmeta.post_id

WHERE posts.post_type = 'revision'

• This reply was modified 2 years, 3 months ago by yinxingmaiming.
• This reply was modified 2 years, 3 months ago by yinxingmaiming.

Sorry – not clear what your comment/SQL means.

Just to clarify, when I run the LS Post Revisions purge:
– the post record(s) associated with revisions are correctly purged.
– postmeta records associated with the revision post record are not purged.

Assuming the SQL in your comment is the code executed by the Post Revisions purge, pls note:

$sql = “DELETE FROM$wpdb->posts is only deleting records from the posts table. But the postmeta records associated with the revision post records are not referenced in your SQL statement. And I doubt there is a cascading delete in place.

I’m sure I’m stating the obvious, but:

posts table – contains the original post header record
– posts table – contains the revisions header record (these are correctly deleted)
— postmeta table – contains the detail records associated with the revision header in the posts table (these are not getting deleted)

Could you please confirm that the LS Posts Revision purge is, in fact, deleting the revisions’ postmeta records. Every time I run this function, I get orphan postmeta records.

Update

I just ran LS Purge Post Revisions and now have 1295 orphan records in postmeta.

Cache was operational. Could that be the problem?

This is actually a material issue – I’ve run up as many as 100K orphan recs that push the DB size to well over 1GB.

Thx

Prosenjit

Thx so much for the info. Can I also ask

– can we create our widgets using EKit?

– are there templates that provide samples of custom widgets built with EKit?

Thx again

OK, will do.

But in the short-term, can I just ask – is there any limit to the number of columns in a responsive legend – meaning, is amcharts somehow hard-coded so there can’t be more than 2 columns for a mobile form factor?

Thx – not trying wiggle out of posting on github, but the above is my real question…:>)

worked like a charm…

Thx so much!

You rock!!!

Rod

The amcharts “adapter” really doesn’t do anything unique, except to handle the amcharts js scripts and making sure there is a known div to place the output. Other than that, the amchart js code should run fine. I develop all my charts in IntelliJ and I only need to change the reference to the data source (from a local dir to a server dir).

Can you look at the console tab in your browser inspector to see what the error is – 404, cross-origin, etc.?

Another possibility – have you changed the div reference in your code? The HTML section of the plugin requires the following:
<div id=”$CHART$” style=”width: 100%; height: 500px;”></div>

So your code needs to reference $CHART$ instead of the hardcoded div name in your code. Sounds basic, but this is often the problem when I migrate to the plugin.

In your JS code, change:
root = am5.Root.new ( “chartDiv” );
to:
root = am5.Root.new ( $CHART$ );

• This reply was modified 2 years, 5 months ago by yinxingmaiming.

The Elementor doc references: {$query_id}, which I had assumed meant some auto-generated query id would be interpolated.

But in fact, it needs a literal, as in:

add_action( ‘elementor/query/xxxxxx’, ‘custom_query_test_02’ );

For those of us not coming from a WP dev background, a suggestion would be to more clearly define the add_action param types.

Not a WPCode issue – the Elementor doc references: {$query_id}, which I assumed (incorrectly) meant a query id would be interpolated. It needs a literal: ‘elementor/query/xxxxxx’

Thx for the quick reply. Not quite sure what you’re referring to.

The page in question is: https://dev04.sinologix.io/

I guess the more helpful angle would be: is there any known problem with custom queries?

Thx

• This reply was modified 2 years, 5 months ago by yinxingmaiming.