Ramesh Ammula

<span style=”font-size: inherit;”>Hi Linda,</span>

I think the “custom_html-91” and “custom_html-92” names you were given are actually a useful clue.

Those are likely WordPress Custom HTML widget IDs. You normally would not find those as files in your hosting account. They are managed from inside WordPress.

Depending on your setup, check:

Appearance → Widgets

or, if you’re using a block-based theme:

Appearance → Editor → Widgets

Look for Custom HTML widgets and check whether they contain the AdSense code. If you find the code there, you can remove it from the widget rather than editing plugin files.

However, since you were also told that the AdSense code appears three times in the page header, there may be another source injecting it. I would not edit the files of other plugins to remove it.

If you can access the WordPress admin, first check Plugins for Google Site Kit or any ad/AdSense-related plugin, and also check your theme’s header/custom-code settings.

If you want, you can paste one of the actual AdSense code snippets that you are trying to remove here. That would make it easier to identify whether it is coming from an AdSense Auto Ads script, a widget, a plugin, or something else.

In standard WordPress, the Category Description box is just a basic text box (no visual/code tabs at all). That’s actually why the HTML code is showing up literally on the page—WordPress is treating those HTML tags as plain written text, not as code to render an image.

​Since default WordPress strips images out of category descriptions, you have two real ways to fix this:

1. ​Clean out the raw code: Just highlight and delete all that raw HTML text from the Description box so the messy code stops displaying on your website.
2. ​Use a Category Image plugin: If you want actual images on your category pages, install a free plugin like Categories Images or Category Featured Image. These plugins add a proper “Upload Image” button directly to the category edit page, so you don’t have to deal with raw HTML code at all.

​Hope that clears up why that code was sticking around!

No problem at all! You were actually looking in the Astra Theme settings (under Appearance > Customize), which is why you couldn’t find it!

​To edit the category descriptions, you just need to stay in the standard WordPress Admin Dashboard:

1. ​On the left-side menu of your WordPress dashboard, hover over Posts and click Categories.
2. ​Hover over the category that is causing the problem and click Edit.
3. ​On that edit page, scroll down to the Description box.

​How to check for hidden HTML:

• ​If you see a Text tab (or Code tab) at the top right of the Description box, click it to see the raw HTML.
• ​If you see the visual text with your images inside, look at the code/text to see if there are extra HTML tags like <span style=”…”> or <div style=”…”> around the image or text.
• ​The cleanest fix is to highlight and delete the pasted image/text inside that box, click the Add Media button (if available) to insert the image properly, and click Update at the bottom.

​Let me know if you are able to locate the Posts > Categories page now!

Hi @ejin,

The older theme could be involved, but I wouldn’t assume that yet because the exact cause will be in the PHP fatal error.

Since the error happens both when adding a post and on part of the About page, I’d first try to get the actual error message before changing the theme or WordPress version.

If you have access to the hosting files, check whether you received the WordPress “Your Site is Experiencing a Technical Issue” email. WordPress Recovery Mode often identifies the plugin or theme that triggered the fatal error.

If you don’t have that email, you can enable logging temporarily in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then reproduce the problem by trying to add a post and also loading the About page. After that, check wp-content/debug.log.

The important part is the fatal error line, especially the file path, function name, and line number. That should tell us whether the problem is coming from AccessPress Mag Pro, a plugin, PHP compatibility, or something else.

If you can paste the fatal error from the log here (remove any passwords or private paths), we can work out the specific fix instead of guessing.

Also, don't leave WP_DEBUG enabled on the live site permanently. Once the error has been captured, turn debugging back off.

Hi @juanwp22 ,

Your test results are actually a useful clue. Since the same local copy shows the problem in 7.0.4 but works correctly after updating to 7.1 RC3, it looks much more like a WordPress core/editor issue in the 7.0.x branch rather than something specific to GeneratePress.

WordPress 7.1 includes several changes and improvements around media handling in the editor, so your result is consistent with those changes.

I don’t want to point you to a specific Trac ticket without confirming that it is the same issue. If you want to investigate it further, I’d suggest checking the 7.0 and 7.1 editor/media changes in Trac or the Gutenberg repository and comparing the related fixes.

For now, your local test is a good way to confirm that the issue is resolved in 7.1 RC3. I’d wait for the final 7.1 release before updating the live sites, then test the same workflow there.

Thanks for sharing the testing results they should also help narrow down whether this is a 7.0.x regression.

Hi @sibichan,

I can definitely help clear this up for you!

1. Why the header is showing in the editor Since Twenty Twenty-Five is a full-site editing (block) theme, WordPress shows your site header and footer directly in the page editor by default. It’s just showing you a live preview of how the entire page will look once published.

If you want a specific page without a header, you can change the page layout:

• In the right sidebar, click Page.
• Look for Template and select a template like “Blank” (or edit the template to remove the header component).

2. Fixing the Cover block width If your Cover block isn’t stretching all the way across the screen, it’s usually blocked by a parent container:

1. Click on your Cover block.
2. In the toolbar directly above it, click the alignment icon and choose Full width.
3. If it’s still boxed in, check if your Cover block is sitting inside a Group block. If it is, select that outer Group block and either set it to Full width as well, or toggle off “Inner blocks use content width” in its settings panel on the right.

Give that a shot and let me know if it works! If you get stuck, feel free to share a screenshot of your block list view (the icon with three staggered lines at the top left) so we can see how the blocks are nested.

• This reply was modified 2 days, 9 hours ago by Ramesh Ammula.