bcworkz

You’ll need the phpMyAdmin app in order to hopefully resolve this. It’s generally accessed through your hosting account or cPanel. It allows you to directly view and manipulate the DB.

If this is a new installation, drop all tables with the wp_kv9a6brmkv_ prefix. Any data you may have added will be lost. Then reinstall WordPress.

If this is not a new installation, verify that the tables are actually missing. It’s possible they exist but the DB user that WP is using has no permission to access them. The tables’ assigned permissions will need to be corrected.

If they are truly missing, yet other WP tables such as posts, terms, etc. still exist, your DB has become seriously corrupted and the rest of the DB may not be reliable. It’d be best to drop everything (but first backup what you have now, just on principle), then restore from a known good backup.

If you don’t have a good backup, you could attempt to patch up the existing DB. Alter the table prefix in the wp-config.php file, then reinstall WP. Rename the new options and postmeta tables using the needed wp_kv9a6brmkv_ prefix. You may drop the remaining new tables. Restore the table prefix in wp-config.php back to what it was. You should regain basic functionality this way, but all of your media uploads (attachment posts) will be lacking crucial information. You’ll need to delete all existing media and re-upload it. This will likely break all the media URLs that exist in your posts. You’ll need to also correct all such URLs. Despite all this effort, it’s possible your site will still not work correctly. We cannot know what else might be wrong with the DB aside from missing tables.

You should be escaping any content prior to output. Run $descripcion1 through esc_xml().

By truncating the field to the first 600 chars, there could be HTML tags that fail to properly close, which could cause XML issues. There’s no simple, elegant way to make sure everything closes correctly. The brute force way to ensure there are no improper HTML blocks is to simply strip out all HTML tags so only plain text remains. This is what the WP auto-excerpt function does.

Configuration varies somewhat depending on the specific O/S. I believe Pi OS is essentially Debian?

If so, it uses a virtual host scheme. Generic instructions here.

Where the example has <VirtualHost *:80>, replace the * with the actual IP address you’re using. If you’re not using port 80, change the 80 to the correct port.

I think the only entries you really need is an arbitrary server name and the DocumentRoot entry. Though you should want the log files enabled as well. Be sure your DocumentRoot value reflects the actual path on your server.

Enabling debugging is a good tip. Adding to that thought: for production sites, you shouldn’t leave debugging turned on for extended periods of time. Being able to see error messages not only helps you get to the root of the problem, it also can help hackers better exploit any vulnerability they might be trying to exploit.

Doesn’t the email tell you what the actual error was? What was actual the error then? If it’s not in the email or you didn’t get the email, check your server;s error log for the actual error message.

Once the error is known, the next step is to deactivate the theme or plugin responsible. This can be done without accessing the WP admin area by using FTP to rename the directory of the module responsible for the error. You should then be able to log into your site again. You may then restore the proper directory name, but do not re-activate the related module. Seek assistance through the dedicated support channel of the problem module to help you resolve the error.

Sometimes the error message is too vague to identify a specific module. To regain basic functionality, via FTP, rename your current theme’s directory and also rename the /plugins/ directory to deactivate all plugins. After logging in, restore the proper directory names. Then install and activate the Health Check & Troubleshooting plugin. Activate the plugin’s Troubleshooting mode. Use its troubleshooting admin bar item to selectively activate the various modules in order to identify the source of the error.

if you’re adding it directly to a block it can cause issues

Indeed. The block editor is very particular about what block attributes are permitted.

You should be able to use the code editor to add an inline <style> HTML element with appropriate CSS code. Alternately, add the CSS to the Additional CSS section of the customizer (classic theme) or style book (block theme). The Additional CSS section is output for all posts and pages. To target a specific page, look at the post’s <body> tag class attribute values. It’s theme dependent, but there is usually a class such as postid-1234 you can use to target a specific page.

In case you haven’t discovered it yet, check out your browser’s element inspector tool that’s part of its developer tool set. To get to it in most browsers, right-click the image and select the “Inspect” option. With the tool, you can edit, add, or remove CSS and immediately see the effect on the page. Changes in the tool do not persist. Once you have arrived at desirable CSS, copy/paste it to an inline style or Additional CSS section. An added benefit — when you’re adding CSS in the tool, it’ll auto-suggest CSS code that’s possible to use.

If you’re unable to re-activate your normal theme, then it’s definitely causing errors. Not only by corrupting an archive query, but it also has some fatal error that prevents it from being activated.

Check your error log to determine what error is preventing it from being activated. Relay this information to your theme’s dedicated support channel so the theme authors can make appropriate corrections.

If you know something about PHP programming, you might be able to patch the error yourself, though the theme authors still ought to be notified so the problem can be fixed for other users.

Getting the theme activated again may not resolve the original corrupted query problem. There are numerous ways a theme can corrupt queries, but most commonly the “pre_get_posts” action is involved. Search your theme’s files for any add_action() call involving “pre_get_posts”. Once found, make that line into a PHP comment (add // at the head of the line). That should prevent it from altering the query. There could be other undesired side effects in doing so, but if it resolves the archive query issue then we know where more attention needs to be focused.