Pial

Hi @giangiluca,

Thank you for your patience.

As we have not heard back from you regarding the requested tests and diagnostics, we are marking this topic as resolved for now.

If the issue still persists, please feel free to reply with the results of the cache purge, conflict test, and Site Health information, and we will be happy to continue investigating.

Have a great day!

Hi there @burodebom,

Just checking in to see if you’re still experiencing this issue.

As suggested earlier, please try increasing the WordPress memory limit and let us know the result. If the issue persists after that, please share the following details so we can investigate further:

• Current Elementor version
• Current Essential Addons version
• A screenshot of Elementor → System Info
• Any browser console errors that appear when the editor gets stuck loading

Since we haven’t heard back from you for a while, I’ll mark this topic as resolved for now. If the issue still exists, feel free to reply here with the requested information, and we’ll be happy to continue investigating.

Thank you!

Hi @giangiluca,

Sorry for the delayed response.

We re-checked your REST endpoint and it now returns the 3 posts correctly. The earlier empty response was a stale cached response. Your site’s response headers confirm this: the REST API is being served with cache-control: max-age=172800 (48 hours), which is not WordPress default behaviour and is set by something on your caching stack. The page where the Post Grid lives is almost certainly being page-cached the same way, and the cached HTML was generated at a moment when the query returned no posts. The backend works because admin requests bypass the cache.

Could you please do the following and report back what you observe?

1. Purge and temporarily deactivate every cache layer

• Purge and deactivate any caching plugin (WP Rocket, W3 Total Cache, LiteSpeed Cache, WP Super Cache, Breeze, etc.).
• Purge any server-level / host panel cache (Varnish, NGINX, LiteSpeed, hosting panel).
• Purge any object cache (Redis, Memcached) if enabled.
• Purge any CDN cache (Cloudflare etc.).

2. Build a fresh test page

• Create a brand-new Elementor page (so it has never been cached).
• Add a Post Grid widget with the failing category.
• Open it in an incognito window and check whether the posts appear.

3. If it still fails after caches are off, do a plugin conflict test

• Deactivate all plugins except Elementor and Essential Addons.
• Reload the test page in incognito.
• If it then works, reactivate plugins one by one until it breaks again — that plugin is the conflict.

4. Share your Site Health info export

• In WP Admin, go to Tools → Site Health → Info tab.
• Click “Copy site info to clipboard” at the top right.
• Paste the result into a text file and share it with us.

Please share what you find at each step. That will let us pinpoint exactly which layer is causing this.

Hi @temerity001 ,

I’m really glad to hear that everything is working properly now.

I also sincerely appreciate your patience, understanding, and cooperation while we worked through the issue. And thank you so much for taking the time to leave a review and share your feedback. It truly means a lot to me personally and to our entire team. Supportive feedback like yours genuinely motivates us to keep improving and helping our users in the best way possible.

Please feel free to reach out to us anytime if you ever face any issues or need any assistance in the future. We’ll always be happy to help.

Have a wonderful day!

Hi @giangiluca ,

Thank you so much for sharing the templates — that gave us the context we needed to investigate.

Based on our investigation, here’s what we found:

• The Post Grid widget is currently configured to filter by category 1289 (“Corsi sicurezza elearning”).
• WordPress’s own category archive at https://www.quec.net/category/corsi-sicurezza-elearning/ shows “Non riusciamo a trovare quello che cerchi” (no posts found).
• Your site’s REST API endpoint /wp-json/wp/v2/posts?categories=1289 also returns an empty array.

This tells us WordPress itself isn’t finding any published posts in that category, so the Post Grid widget is correctly reflecting that result.

Could you please try the following and let us know how it goes?

1. Open Posts → Categories in your admin and click into “Corsi sicurezza elearning”.
2. Confirm that there are actually published posts assigned to it (not draft, private, or trashed). The count next to the category name in the list includes all statuses, so it may show 3 even if none of them are published.
3. Then try the Post Grid widget with a category you’ve confirmed has published posts — for example, “Agenzia Formativa” — we checked your site and that category does contain published posts that WordPress is returning normally, so it’s a good control test

Looking forward to your reply.

Hi there @burodebom ,

Just following up whenever you get a chance, could you please try the troubleshooting steps we shared earlier and let us know how it goes?

We’ll be happy to check further based on the results.

Thank you!

Hi @flatword ,

Thank you for reaching out.

The link_slug field is an internal identifier generated by BetterLinks for each link, similar to how WordPress creates post slugs. It is usually derived from the link title and is different from both the short_url and target_url fields, which control the actual redirect behavior.

Since link_slug is mainly used internally by the plugin, it is not normally displayed on the BetterLinks edit screen.

Regarding the repeated link_slug values, this commonly happens when links are created using the Duplicate feature. During duplication, the original slug is copied as well. Even if the title or short URL is later changed, the slug itself is not automatically regenerated, which can result in multiple links sharing the same link_slug.

In most cases, this does not affect redirect functionality, since BetterLinks primarily relies on the short_url field for routing. However, we understand how this can be confusing, and improvements to this behavior are already planned as part of the upcoming redesign.

For importing, you generally do not need to worry about the link_slug field. If it is blank or duplicated, BetterLinks should automatically generate or adjust it during import. The main fields required for import are:

• link_title
• short_url
• target_url
• redirect_type (optional, such as 301 or 307)

You can absolutely create your own spreadsheet from scratch for importing. Most additional fields included in exports, such as tags, categories, notes, nofollow, sponsored, and date-related fields, are optional and only need to be included if relevant to your setup.

Fields like ID, link_slug, and date columns can usually be omitted, as BetterLinks handles them automatically during import.

As an additional note, we are currently working on a improved import/export system that will include column mapping support and clearer required field indicators, making custom spreadsheet imports much easier moving forward.

Here’s a demonstration:
https://d.pr/v/UcK2Ml

Here is an early access development version:
https://d.pr/f/w4t8Hf

Hope this helps.