Marta Fernandez

Hi @ludwigkeck

The error “Invalid subscription configured for this block” usually appears when the Payment block is linked to a subscription or Stripe configuration that is no longer valid or properly connected.

Here are a few things you can check:

1. Make sure your Stripe account is still correctly connected via Jetpack (Jetpack > Settings > Payments).
2. Try removing the Payment block and adding it again from scratch on the new page.
3. If you duplicated the block from another page, it may carry an invalid subscription ID, in that case, you need to reconfigure the payment inside the block settings.
4. Open the block settings and verify that the product/payment option is properly selected or recreated.

If the issue persists, disconnecting and reconnecting Stripe in Jetpack can also help reset the configuration.

Hello @andyjay2012

Yes, this can be achieved with a plugin, no need to build everything from scratch.

You have a few options depending on complexity:

• Simple solution: Import your spreadsheet (CSV) into WordPress using a plugin like WP All Import, then display/search it with a table plugin like TablePress + its search/filter extensions.
• More advanced search (AND / OR / NOT): Use a plugin like Search & Filter Pro or FacetWP. These allow conditional logic and more flexible queries once your data is imported as custom posts or a custom database.
• Best approach (recommended):
  1. Import your spreadsheet as a custom post type (each row = one entry)
  2. Store columns as custom fields
  3. Use a filtering/search plugin (FacetWP or similar)

No custom coding is strictly required unless you need very specific UI or performance optimization.

Hello @funkyflower ,

What you describe is usually caused by bots hitting the WooCommerce checkout endpoint directly. WooCommerce creates the order before the payment step, so even if the payment fails or is never completed, the order can still appear as draft/pending.

reCAPTCHA plugins also often protect login or forms but not always the checkout, which allows bots to create these orders.

A few things that would help diagnose this:

• What status do these orders have exactly (Draft, Pending payment, Failed)?
• Is guest checkout enabled?
• Which captcha/security plugins are currently active?

If you don’t mind sharing the URL of the site, I’d be happy to take a look from the outside and see if anything obvious stands out.

At this URL on your site, you can check the robots file. I don’t see anything that prevents search engines from crawling.

You can check it yourself here:

https://edufrienz.com/robots.txt

Have you been able to check the crawl errors in Search Console?

Hello @specialconnectionstudio

Since the site itself loads correctly at:

https://design.special-connection-studio.de/brave-business/

but the redirect loop happens when opening the dashboard, this often indicates that WordPress is not resolving the correct site URL internally.

A couple of things would be useful to check:

1. In the wp_blogs table, verify that the entry for the site has:

domain → design.special-connection-studio.de
path → /brave-business/

2. In the options table for that site (likely wp_2_options), confirm that these values are set to:

siteurl → https://design.special-connection-studio.de/brave-business
home → https://design.special-connection-studio.de/brave-business

If either of those values is missing /brave-business, WordPress may repeatedly redirect /wp-admin/.

Also, when the redirect loop happens, are you accessing the dashboard via:

https://design.special-connection-studio.de/brave-business/wp-admin/

or through Network Admin → Sites → Dashboard?

If you can, could you also confirm what values you currently see for home and siteurl in that site’s options table?

Thanks for confirming.

The error DB Error: no database selected usually happens when the database connection is established but the database name is not actually selected in the connection string.

Since your database is eca, please check:

1. In phpMyAdmin, confirm that the database eca exists and contains the CiviCRM tables after installation.
2. Verify that the MySQL user you entered during the installer has permissions on the eca database.
3. Check your CiviCRM configuration file (usually civicrm.settings.php) and confirm that the database name is correctly set to eca.

Also, since you are using XAMPP, make sure the database host is set to localhost.

If possible, could you also confirm:

• the database host you entered during installation
• whether any CiviCRM tables were created in the eca database?

That’s normal.

The CSS we added only affects the front-end of the site, not the WordPress editor. The editor uses its own styles, so the border can still appear there even though it’s removed on the live page.

I checked your page and the border is no longer visible on the public page, so the fix is working correctly.

Hi @msbabaseball

I checked your page and the border comes from the Jetpack form container (.wp-block-jetpack-contact-form-container).

You can remove it by adding this CSS:

.wp-block-jetpack-contact-form-container {
border: none !important;
}

Add it in Appearance → Customize → Additional CSS.

That will remove the border around the Jetpack form block.

Could you try adding this and confirm if the border disappears?

• This reply was modified 1 month ago by Marta Fernandez.
• This reply was modified 1 month ago by Marta Fernandez.