A PHP warning that appears on only one visible page can still originate from theme code that runs across the entire WordPress site. In one support case, a public-facing page showed a broken heading containing unexpected @ET-DC@… text instead of the intended title.
The root cause was a bug in the theme’s image-setup code. That routine ran on every page load and assumed every registered image size had a corresponding large version. One blog-thumbnail size did not. The resulting PHP warning was printed into the frontend output, where it collided with Divi‘s page-title rendering. Updating the theme logic to fall back to the largest defined image size resolved the warning.
Issue background
A WordPress page began displaying a public-facing warning and an unusual page heading instead of the expected title. The affected output included malformed text beginning with @ET-DC@….
Because the page itself was not entirely built with Divi, the investigation needed to look beyond the page builder. The site’s homepage and shared header/footer components used Divi, while many internal pages relied on PHP templates and Gutenberg.
Recent plugin changes initially created several plausible suspects, including timeline, caching, and media-related plugins. However, the final diagnosis did not trace the problem to those recent plugin updates.
Diagnosis
The developer found the problem in the theme’s image-setup code.
That code executed on every page load and registered the different image crop sizes used throughout the site. Its logic assumed that every image-size configuration included a large version.
One image size used for blog thumbnails did not define that version. When the theme tried to access it anyway, PHP generated a warning.
On production, the warning text was being printed directly into the page output. On the affected page, that unexpected output interfered with the way Divi assembled the page title, which is why the visitor saw malformed @ET-DC@… text rather than a normal heading.
This also explains why the issue appeared page-specific even though the faulty image-setup code ran globally. The PHP warning existed at the theme level, but its visible effect depended on how a particular page rendered its content.
Resolution steps
The documented fix was targeted to the theme logic:
- Inspect the PHP warning rather than assuming the page builder is broken. The visible title corruption was only the symptom. The underlying problem came from theme code executed earlier in the request.
- Trace the warning to the image-size setup routine. The developer identified the theme code responsible for defining the site’s image crop sizes.
- Review the assumptions made by that routine. The code expected every image size to contain a
largedefinition, but one blog-thumbnail configuration did not. - Remove the unsafe assumption. The image-setup logic was updated so it no longer requires a
largesize to exist in every configuration. - Add a fallback to the largest available size. When
largeis not defined, the code now uses the largest image size that is actually available. - Retest the affected page. Once the warning stopped being generated, the page title rendered normally again without the malformed Divi output.
The important fix was defensive handling inside the theme code. Rather than adding a special-case workaround for the affected page, the developer corrected the shared image-size logic that caused the warning in the first place.
Final outcome
The PHP warning was resolved by updating the theme’s image-setup routine to handle missing image-size definitions safely. The affected page returned to normal, and the malformed @ET-DC@… title output disappeared.
The broader lesson is that a WordPress warning visible on one page may still originate from shared theme code. When page output becomes corrupted after a PHP warning, trace the warning back to its source before modifying Divi, Gutenberg, or the page template itself.
Defensive checks are especially important in image-registration code, where different crop configurations may not all expose the same named sizes. Falling back to an available size is safer than assuming a specific array key or variant will always exist.
If your WordPress site is displaying PHP warnings, malformed Divi output, or frontend errors caused by custom theme code, contact Freshy. Our WordPress team can trace the underlying warning, correct the theme or plugin logic, and restore the affected page safely.
