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!
* Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
In reply to: [Images in Category pages](https://wordpress.org/support/topic/images-in-category-pages-2/)
* [Ramesh Ammula](https://wordpress.org/support/users/rajaramesh/)
* (@rajaramesh)
* [3 days, 7 hours ago](https://wordpress.org/support/topic/images-in-category-pages-2/#post-18993889)
* Ah, that copy-paste detail is huge! That’s almost certainly where that stray
HTML came from.
* When you paste images or text directly into WordPress category descriptions
from another page or document, it often sneaks in hidden HTML tags, inline styles,
or hardcoded image sizes. That extra code overrides Astra’s default layout settings.
* Here is an easy way to clean it up:
1. Go to **Posts > Categories** in your dashboard and edit the category causing
trouble.
2. In the Description box, switch over from the **Visual** tab to the **Text/Code**
tab so you can see the raw HTML.
3. Look for extra tags around the image (like
or ) and
clean them out.
4. If the image code looks messy, delete it and re-add the image using the official**
Add Media** button instead of pasting it in.
* Once that description HTML is clean, Astra should be able to layout the category
page properly again!
* Let me know how it goes!
* Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
In reply to: [There has been a critical error on this website](https://wordpress.org/support/topic/there-has-been-a-critical-error-on-this-website-462/)
* [Ramesh Ammula](https://wordpress.org/support/users/rajaramesh/)
* (@rajaramesh)
* [3 days, 8 hours ago](https://wordpress.org/support/topic/there-has-been-a-critical-error-on-this-website-462/#post-18993830)
* Hi [@ejin](https://wordpress.org/support/users/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`:
* ```wp-block-code
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.
* ```wp-block-code
Also, don't leave WP_DEBUG enabled on the live site permanently. Once the error has been captured, turn debugging back off.
```
* Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
In reply to: [Encoding for non-Latin characters suddenly broken (Chinese, Korean)](https://wordpress.org/support/topic/encoding-for-non-latin-characters-suddenly-broken-chinese-korean/)
* [Ramesh Ammula](https://wordpress.org/support/users/rajaramesh/)
* (@rajaramesh)
* [3 days, 8 hours ago](https://wordpress.org/support/topic/encoding-for-non-latin-characters-suddenly-broken-chinese-korean/#post-18993826)
* ```wp-block-code
Hi @gordsellar,The fact that you are seeing strings such as — directly in the database is a very important clue. That looks more like an encoding conversion/mojibake problem than a font problem.I would not change or remove DB_COLLATE yet. The values in wp-config.php don't necessarily tell us the character set/collation that the existing database tables are actually using.Since you have a backup from before the problem appeared, I would first check the database structure before making any changes.In phpMyAdmin, could you check the Collation column for the affected tables, especially wp_posts?You can also run:SHOW TABLE STATUS;and look at the Collation values.If the affected tables are using something like latin1 while WordPress is connecting with utf8mb4, that could explain why the data is being interpreted incorrectly. But if the database actually contains the mojibake text (—, 變, etc.), we should first determine whether the data was converted incorrectly at some point rather than simply changing the database collation.I would definitely avoid running a bulk charset conversion on the live database until we know exactly how the existing data is encoded. With thousands of posts affected, the old backup could also help us compare the same record before and after the corruption and determine the correct conversion method.If you can post the collation of wp_posts and one affected value from the database, we may be able to narrow this down further.
```
* Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
In reply to: [Images not visible while editing posts after updating to WordPress 7](https://wordpress.org/support/topic/images-not-visible-while-editing-posts-after-updating-to-wordpress-7/)
* [Ramesh Ammula](https://wordpress.org/support/users/rajaramesh/)
* (@rajaramesh)
* [3 days, 8 hours ago](https://wordpress.org/support/topic/images-not-visible-while-editing-posts-after-updating-to-wordpress-7/#post-18993819)
* Hi [@juanwp22](https://wordpress.org/support/users/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.
* Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
In reply to: [Images in Category pages](https://wordpress.org/support/topic/images-in-category-pages-2/)
* [Ramesh Ammula](https://wordpress.org/support/users/rajaramesh/)
* (@rajaramesh)
* [3 days, 8 hours ago](https://wordpress.org/support/topic/images-in-category-pages-2/#post-18993812)
* Hi [@andywalding](https://wordpress.org/support/users/andywalding/) ,
* I think the important part here is that the image is actually inside the category
description as HTML, rather than being a separate category image.
* Since WordPress normally sanitizes category descriptions when they are saved,
something on the site must have previously allowed that `![]()
` HTML to remain
there. That could be a plugin, the theme, or some custom code.
* Since you’re using Astra or Astra Pro and everything is up to date, I’d first
check whether the behavior started after a recent WordPress, plugin, or theme
update.
* You could also make a full backup and test the category with a staging site or
a default WordPress theme. That would help narrow down whether this is coming
from WordPress itself or something added by the site.
* The fact that the old category still displays the image, but saving it removes
the HTML, is a useful clue. It suggests the image data is already there and is
being stripped when the category description is saved.
* I’d be interested to know what changed immediately before this started happening.
* Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
In reply to: [Edit page showing header](https://wordpress.org/support/topic/edit-page-showing-header/)
* [Ramesh Ammula](https://wordpress.org/support/users/rajaramesh/)
* (@rajaramesh)
* [3 days, 9 hours ago](https://wordpress.org/support/topic/edit-page-showing-header/#post-18993787)
* Hi [@sibichan](https://wordpress.org/support/users/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 3 days, 8 hours ago by [Ramesh Ammula](https://wordpress.org/support/users/rajaramesh/).
* Forum: [Fixing WordPress](https://wordpress.org/support/forum/how-to-and-troubleshooting/)
In reply to: [Navbar and Focus on element (JS)](https://wordpress.org/support/topic/navbar-and-focus-on-element-js/)
* [Ramesh Ammula](https://wordpress.org/support/users/rajaramesh/)
* (@rajaramesh)
* [3 days, 9 hours ago](https://wordpress.org/support/topic/navbar-and-focus-on-element-js/#post-18993767)
* Hi [@wildapache](https://wordpress.org/support/users/wildapache/),
* That is a very common issue when working with fixed or sticky navigation bars
on mobile screens! When you focus an element, the browser scrolls it to the absolute
top edge of the screen, which places it directly underneath the header.
* Here are two effective ways to fix this:
* Option 1: Modern CSS `scroll-margin-top` (Easiest)
* You can use the CSS property `scroll-margin-top`. This tells the browser to keep
extra breathing space above the element when scrolling or focusing on it.
1. First, make sure your `
` or `
` tag has `tabindex="-1"` so it can receive focus via JavaScript: * ```wp-block-code
Error message goes here
Add scroll-margin-top to your CSS class (set it equal to your mobile navbar height + a little extra padding, e.g., 80px):CSS.my-error-box { scroll-margin-top: 80px;}
```
* Now, when you run `element.focus()` in JavaScript, the browser will stop scrolling
80px before the top edge, leaving the message fully visible below your header.
Option 2: JavaScript `scrollIntoView({ block: 'center' })`
* If you prefer a pure JavaScript solution, instead of letting `.focus()` jump
to the top, you can focus without scrolling and then gently center the error
element on the screen:
* JavaScript
* ```wp-block-code
const errorEl = document.getElementById('error-message');
// Focus without triggering default scroll jump
errorEl.focus({ preventScroll: true });
// Smoothly scroll the element into the center of the viewport
errorEl.scrollIntoView({ behavior: 'smooth', block: 'center' });
```
* Hope this helps solve the issue! Let me know if you run into any trouble applying
it.
Viewing 13 replies - 1 through 13 (of 13 total)