Fix the two faults behind the broken demo: WP_Error terms and the Font Awesome handle collision - #348
Merged
Merged
Conversation
wp_get_object_terms() returns a WP_Error when the taxonomy is not registered, which happens whenever whatever supplied the portfolio post type is deactivated while its posts remain. ! empty() is true for an object, so the WP_Error was pushed straight into tax_query and WP_Query then returned the wrong related posts rather than none. Not fatal here -- unlike the same pattern in the companion plugin's Portfolio widget, which raised a TypeError in implode() and truncated the page -- but wrong in the same way and worth closing off. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
WordPress deduplicates enqueues by handle: whichever caller registers a handle
first wins, and every later enqueue of the same handle is silently a no-op.
The theme registered its Font Awesome 6 as plain 'font-awesome', which is the
same handle Elementor uses for the Font Awesome 4.7 it bundles.
On any site running Elementor -- including the official demo -- Elementor
registers first, so the theme's Font Awesome 6 never loaded. The theme then
rendered fa-brands / fa-solid / fa-x-twitter / fa-mobile-screen against
Font Awesome 4, where none of those classes exist, and the social, search and
menu icons came out as blank boxes.
Verified on the demo's markup:
id='font-awesome-css' href='.../elementor/.../font-awesome.min.css?ver=4.7.0'
and the theme's own fontawesome6/all.min.css absent from the page entirely
while every other theme stylesheet loaded normally.
Renaming to 'shapely-font-awesome' means the theme always gets the version its
markup is written against, whatever plugins are installed.
Note for child themes: anything calling wp_dequeue_style( 'font-awesome' ) to
swap the icon set now needs the new handle. The theme's other generic handles
('bootstrap', 'flexslider', 'owl.carousel') carry the same collision risk but
are left alone here -- they are not currently broken anywhere, and renaming
them would break dequeues for no present benefit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
puikinsh
changed the title
… collision
The Epsilon framework enqueues Font Awesome for the customizer screens with
wp_enqueue_style( 'font-awesome', EPSILON_URI . '../../assets/css/...' );
which is wrong twice over.
EPSILON_URI is already trailingslashit'd to
.../themes/shapely/inc/libraries/epsilon-framework/
so '../../' climbs to .../themes/shapely/inc/ -- one level short of the theme
root. The resulting .../shapely/inc/assets/css/fontawesome6/all.min.css does
not exist and never has, so the customizer has been 404ing on its own icon
font. Confirmed against the working tree: the old path resolves to a file that
is not there, the new one to the real 102 KB stylesheet.
It also reuses the generic 'font-awesome' handle, so on any site where a plugin
registers that handle first the enqueue is a silent no-op regardless of path.
Now points at get_template_directory_uri() and shares the theme's
'shapely-font-awesome' handle, so the admin and front end load one file, once,
with a real version string for cache busting.
This library is vendored rather than a submodule, so it is patched in place --
same as the two existing PHP-compatibility patches in inc/libraries/.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Same failure as the companion plugin's CI: phpcodesniffer-composer-installer is a Composer plugin, and current Composer refuses to execute plugins that are not explicitly allow-listed. The require aborted with "contains a Composer plugin which is blocked by your allow-plugins config" before PHPCS was installed, so the coding-standards job had been failing on infrastructure rather than on anything in the theme. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while diagnosing the fatal on https://colorlibhub.com/shapely/ (fixed in shapely-companion #42). The theme has the same unguarded pattern.
wp_get_object_terms()returns aWP_Errorwhen the taxonomy is not registered — the case whenever whatever supplied the portfolio post type is deactivated while its posts remain.! empty()is true for an object, so theWP_Errorwas pushed straight intotax_query:Not fatal here — unlike the plugin's Portfolio widget, which passed the
WP_Errortoimplode()and raised a TypeError that truncated the page. The consequence is quieter:WP_Queryreceives a malformedtax_queryand returns the wrong related posts instead of none.Both
wp_get_object_terms()calls are now checked withis_wp_error(). After this, all four term lookups across the theme are guarded (archive-jetpack-portfolio.phpalready was).Verified:
php -lclean across 85 files, front-end sweep shows all pages complete with 0 PHP notices and 0 JS errors.🤖 Generated with Claude Code