IMPORTANT — STABILIZE THE EXISTING PLUGIN FIRST

I currently have a WordPress plugin for the Pawfect Bag website that is causing:

“There has been a critical error on this website.”

I need you to fix this issue and produce a stable, production-ready version.

Website:

The plugin must provide TWO Elementor widgets:

1. Pawfect Post Grid
2. Pawfect Post Gallery

However, STABILITY IS THE FIRST PRIORITY.

Do not add new features at the expense of stability.

1. CRITICAL REQUIREMENT

The current plugin is causing a WordPress fatal/critical error.

Before adding or changing functionality:

AUDIT THE ENTIRE EXISTING PLUGIN

Inspect every existing:

• PHP file
• class
• function
• hook
• AJAX handler
• Elementor widget
• shortcode
• CSS enqueue
• JavaScript enqueue
• activation hook
• deactivation hook
• uninstall logic
• namespace
• require/include statement

Find the actual reason for the fatal error.

Do not assume the cause.

Do not simply hide the error.

Do not suppress PHP errors with:

@function()

Do not use:

error_reporting(0);

Do not use:

ini_set('display_errors', 0);

to hide a fatal error.

The underlying problem must be fixed.

2. DO NOT DESTROY THE EXISTING WEBSITE

The plugin must NEVER:

• modify WordPress core
• modify Elementor core
• modify the active theme
• modify WooCommerce core
• modify existing posts
• modify existing pages
• modify existing products
• delete content
• overwrite theme files
• overwrite Elementor files
• create unnecessary database tables

The plugin should be isolated and self-contained.

3. EXTREME COMPATIBILITY REQUIREMENT

The plugin must safely work with:

• WordPress
• Elementor
• Elementor Pro
• WooCommerce
• modern PHP
• PHP 8.1
• PHP 8.2
• PHP 8.3

The website may currently use PHP 8.3.

Do not use deprecated PHP syntax.

Do not use deprecated WordPress APIs.

Do not use deprecated Elementor APIs.

4. ELEMENTOR MUST BE OPTIONAL

This is extremely important.

The plugin must NOT cause a fatal error if Elementor is:

• not installed
• inactive
• temporarily disabled
• updating
• unavailable
• partially loaded

Never directly extend an Elementor class before verifying Elementor exists.

WRONG:

class Pawfect_Post_Grid extends \Elementor\Widget_Base

without checking Elementor.

Use a safe architecture.

For example:

if ( did_action( 'elementor/loaded' ) ) {
    // Register Elementor integration.
}

And make sure Elementor widget classes are loaded ONLY after Elementor is actually available.

5. ELEMENTOR VERSION COMPATIBILITY

Do not assume a specific Elementor version.

Before registering widgets:

if ( ! did_action( 'elementor/loaded' ) ) {
    return;
}

Use the appropriate Elementor hooks for widget registration.

Do not instantiate Elementor widgets during plugin load.

Do not access Elementor classes too early.

Avoid:

new \Elementor\Widget_Base()

during plugin initialization.

Elementor itself should instantiate the widget.

6. CLASS LOADING MUST BE SAFE

This is one of the most important requirements.

Avoid duplicate class declarations.

Before loading custom classes, ensure they are loaded only once.

Use a clear architecture such as:

defined( 'ABSPATH' ) || exit;

and properly controlled require_once.

Never use:

require

for files that could be loaded more than once.

Prefer:

require_once

where appropriate.

Never define the same class twice.

Never define the same function twice.

Never register the same callback repeatedly.

7. UNIQUE NAMESPACE / PREFIX

Every plugin class/function must use a unique prefix.

Use:

Pawfect_Elementor_Posts

or an equivalent namespace.

Functions should use:

pawfect_ep_

Example:

pawfect_ep_register_widgets()
pawfect_ep_enqueue_assets()
pawfect_ep_ajax_load_posts()

Classes:

Pawfect_EP_Plugin
Pawfect_EP_Query
Pawfect_EP_Renderer
Pawfect_EP_Ajax
Pawfect_EP_Elementor
Pawfect_EP_Post_Grid_Widget
Pawfect_EP_Post_Gallery_Widget

Do NOT use generic names such as:

PostGrid
PostGallery
Renderer
Ajax
Plugin
Query

because they can conflict with other plugins.

8. SAFE PLUGIN BOOTSTRAP

The main plugin file must be extremely lightweight.

Example architecture:

pawfect-elementor-posts.php

should ONLY:

1. Define plugin constants.
2. Check WordPress environment.
3. Load the main plugin class.
4. Initialize after WordPress is ready.

Do not put the entire plugin inside the main plugin file.

9. SAFE INITIALIZATION

Use a controlled initialization flow.

Recommended concept:

Plugin File
    ↓
Environment Check
    ↓
Load Core Class
    ↓
plugins_loaded
    ↓
Initialize Core
    ↓
Check Elementor
    ↓
If Elementor exists
    ↓
Register Elementor Integration
    ↓
Register Widgets

Do not initialize Elementor functionality before Elementor has loaded.

10. SAFE ELEMENTOR REGISTRATION

The Elementor integration should be completely isolated.

For example:

elementor/
├── class-elementor.php
├── class-post-grid-widget.php
└── class-post-gallery-widget.php

Do NOT include the widget classes until Elementor is confirmed available.

The plugin should still activate successfully if Elementor is missing.

11. IF ELEMENTOR IS MISSING

If Elementor is not installed/active:

The plugin must remain active without a fatal error.

Optionally show a normal WordPress admin notice:

Pawfect Elementor Posts requires Elementor to enable the Pawfect Post Grid and Pawfect Post Gallery widgets.

The notice must NOT appear on the frontend.

The plugin must NOT crash.

12. IF ELEMENTOR IS UPDATED

The plugin must tolerate Elementor updates.

Do not rely on internal/private Elementor classes.

Only use documented/public APIs where possible.

Do not access internal Elementor files directly.

Do not require files from:

elementor/includes/

manually.

Do not instantiate Elementor internals.

13. TWO ELEMENTOR WIDGETS

Create exactly two widgets:

Widget 1

Pawfect Post Grid

Widget 2

Pawfect Post Gallery

Both must be independently usable.

Both must appear under:

Pawfect Elements

14. WIDGET REGISTRATION MUST NOT CAUSE FATAL ERRORS

If one widget has a problem, it must not crash the entire website.

Use defensive checks.

For example:

• verify required Elementor classes
• verify methods exist before calling them
• verify WordPress functions exist
• verify query objects
• verify post objects
• verify attachment IDs

Never assume an object exists.

15. PAWFECT POST GRID

The Grid widget must support:

Query

• Post Type
• Posts Per Page
• Order By
• Order
• Offset
• Categories
• Tags
• Custom Taxonomies
• Include Posts
• Exclude Posts

Use WP_Query.

Do not use custom SQL unless absolutely necessary.

16. PAWFECT POST GALLERY

The Gallery widget must support:

• Grid
• Masonry
• Image-focused layout
• Featured image
• Post title
• Category
• Date
• Excerpt
• Read More
• Hover effects
• Optional lightbox
• AJAX Load More
• Pagination

But every feature must be implemented only if it can be done safely.

Stability is more important than adding unnecessary functionality.

17. ALL CONTROLS MUST BE ELEMENTOR CONTROLS

Both widgets must be controlled through Elementor.

Controls include:

Content

• Post type
• Number of posts
• Categories
• Tags
• Order
• Order By

Layout

• Columns
• Gap
• Image ratio
• Image height

Content visibility

• Image
• Category
• Date
• Author
• Title
• Excerpt
• Button

Style

• Colors
• Typography
• Border
• Radius
• Shadow
• Padding
• Margin

Hover

• Image zoom
• Overlay
• Card hover

Responsive

• Desktop
• Tablet
• Mobile

18. DO NOT EXECUTE AJAX IN ELEMENTOR EDITOR UNNECESSARILY

This is very important.

Elementor Editor can behave differently from the frontend.

Do not trigger:

Load More AJAX
Infinite Scroll AJAX
Filter AJAX

automatically while Elementor is rendering the editor.

Detect Elementor editor/preview mode where appropriate.

The widget should render a safe preview.

19. AJAX MUST BE ISOLATED

If AJAX is implemented, use dedicated actions:

wp_ajax_pawfect_ep_load_more
wp_ajax_nopriv_pawfect_ep_load_more

Do NOT use generic AJAX action names.

Every AJAX request must have:

• nonce
• validated page number
• validated post type
• sanitized taxonomy values
• safe query arguments

Example:

check_ajax_referer(
    'pawfect_ep_load_more',
    'nonce'
);

20. AJAX FAILURE MUST NOT BREAK THE PAGE

If AJAX fails:

The page should continue working.

Display:

Unable to load more posts. Please try again.

Do not produce:

• PHP fatal error
• uncaught JavaScript exception
• white screen
• broken layout

21. QUERY SAFETY

Create one shared query class.

Example:

Pawfect_EP_Query

It should:

• validate post type
• validate taxonomy
• sanitize IDs
• sanitize pagination
• restrict query arguments
• return a safe WP_Query object

Never pass raw Elementor values directly into WP_Query.

22. RENDERER SAFETY

Create a shared renderer:

Pawfect_EP_Renderer

Before rendering:

if ( ! $post instanceof WP_Post ) {
    return '';
}

Validate every object.

Never assume:

get_post_thumbnail_id()

returns an image.

Never assume a taxonomy exists.

Never assume an excerpt exists.

Never assume an author exists.

23. IMAGE SAFETY

Use:

wp_get_attachment_image()

where possible.

If a post has no featured image:

Do NOT generate broken HTML.

Instead:

• use a safe placeholder
• or hide the image container

Make this configurable.

24. NO GLOBAL CSS CONFLICTS

All CSS must be namespaced.

Use:

.pawfect-ep-post-grid
.pawfect-ep-post-gallery
.pawfect-ep-card

Never use:

.card
.grid
.gallery
.button
.container
.title

25. NO GLOBAL JAVASCRIPT CONFLICTS

Do not create global variables such as:

var settings;
var gallery;
var grid;
var ajax;

Use an isolated namespace:

window.PawfectEP = window.PawfectEP || {};

Prefer modern scoped JavaScript.

Do not overwrite:

• jQuery
• Elementor
• WordPress globals
• WooCommerce globals

26. NO JQUERY DEPENDENCY UNLESS REQUIRED

Use vanilla JavaScript where possible.

If jQuery is genuinely required:

• declare it as a WordPress dependency
• do not assume it exists
• do not load another copy

27. CSS/JS ENQUEUE SAFETY

Do not load plugin assets on every page unnecessarily.

Only enqueue assets when:

• widget is rendered
• shortcode is rendered
• required plugin frontend functionality is active

Do not enqueue Elementor-specific assets if Elementor is inactive.

28. PAWFECT BAG DESIGN

The visual style must match:

Use the existing site’s:

• colors
• typography
• spacing
• rounded styling
• button treatment
• image presentation
• visual hierarchy

Do not introduce an unrelated design.

However:

Do not scrape or copy website content.

Only reproduce the design language.

29. ELEMENTOR STYLE CONTROLS

Use official Elementor control APIs.

For typography:

Group_Control_Typography

For border:

Group_Control_Border

For shadow:

Group_Control_Box_Shadow

For background:

Group_Control_Background

Do not manually recreate controls that Elementor already provides.

30. PHP 8.3 SAFETY

The plugin must be compatible with PHP 8.3.

Check for:

• undefined array keys
• null passed to typed functions
• invalid string operations
• deprecated dynamic properties
• incompatible method signatures
• incorrect return types
• missing class types
• incorrect nullable handling

Avoid deprecated PHP behavior.

31. WORDPRESS CODING STANDARDS

Follow WordPress standards.

Use:

defined( 'ABSPATH' ) || exit;

Use proper escaping.

Use:

esc_html()
esc_attr()
esc_url()
wp_kses_post()

Use sanitization:

sanitize_text_field()
absint()
sanitize_key()

Use capability checks for admin functionality.

32. NO ADMIN DATABASE REQUIREMENT

Do not create custom database tables.

Do not create unnecessary options.

The widgets should work using Elementor’s saved widget settings.

Do not require an admin settings page for normal functionality.

33. NO ACTIVATION CRASH

Plugin activation must be safe.

The activation hook must NOT:

• load Elementor widget classes
• execute WP_Query
• execute AJAX
• render frontend markup
• access unavailable classes

Activation should only perform minimal compatibility/setup checks.

34. NO DEACTIVATION CRASH

Deactivation must be safe.

Do not delete content.

Do not perform destructive operations.

35. UNINSTALL SAFETY

uninstall.php must be safe.

Do not delete:

• posts
• pages
• products
• media
• Elementor templates
• WooCommerce data

unless explicitly created by the plugin and explicitly configured for deletion.

36. ERROR LOGGING FOR DEVELOPMENT

Instead of hiding errors, add optional development logging.

Use:

if ( defined( 'WP_DEBUG' ) && WP_DEBUG ) {
    error_log( 'Pawfect Elementor Posts: ...' );
}

Do not expose stack traces to normal visitors.

Do not log sensitive data.

Do not log continuously in production.

37. GRACEFUL FAILURE

Every major subsystem must fail gracefully.

Elementor unavailable

→ Plugin remains active.

Invalid post type

→ Show empty state.

No posts

→ Show “No posts found.”

Missing image

→ Use placeholder/hide image.

AJAX failure

→ Show retry message.

Invalid taxonomy

→ Ignore invalid filter safely.

Missing Elementor API

→ Do not register affected functionality.

PHP compatibility issue

→ Show admin notice rather than crashing frontend.

38. DO NOT USE THESE SHORTCUTS

NEVER fix the critical error by:

@include
@require
@method

Never:

error_reporting(0);

Never:

ini_set('display_errors', 0);

as a replacement for fixing the error.

Never wrap the entire plugin in a broad:

try {
    ...
} catch (Throwable $e) {
}

that silently hides errors.

Do not swallow fatal problems.

Fix the actual cause.

39. IMPORTANT — EXISTING PLUGIN MIGRATION

If an existing plugin already exists in the workspace:

DO NOT blindly overwrite it.

First:

1. Inspect the current files.
2. Identify the fatal error.
3. Identify existing functionality.
4. Preserve useful existing functionality.
5. Refactor unsafe code.
6. Fix class loading.
7. Fix Elementor integration.
8. Fix AJAX.
9. Fix JavaScript.
10. Fix CSS conflicts.
11. Test the complete plugin.

If necessary, rebuild individual components.

Do not preserve broken architecture merely for backward compatibility.

40. BACKWARD COMPATIBILITY

If the existing plugin already has:

• shortcode
• class names
• widget names
• settings
• saved Elementor widgets

preserve them where reasonably safe.

Do not unnecessarily change:

shortcode names
widget identifiers
CSS selectors
saved settings

If a breaking change is absolutely necessary, document it.

41. TESTING REQUIREMENTS

Before considering the plugin complete, test:

Test 1

Plugin activation with Elementor active.

Test 2

Plugin activation without Elementor.

Test 3

Elementor editor opening.

Test 4

Pawfect Post Grid widget.

Test 5

Pawfect Post Gallery widget.

Test 6

Frontend rendering.

Test 7

No posts.

Test 8

Post without featured image.

Test 9

Invalid taxonomy.

Test 10

AJAX Load More.

Test 11

Pagination.

Test 12

Mobile responsive layout.

Test 13

Tablet responsive layout.

Test 14

Desktop responsive layout.

Test 15

WooCommerce active.

Test 16

Elementor Pro active.

Test 17

PHP 8.3.

Test 18

WP_DEBUG enabled.

Test 19

Repeated Elementor editor reload.

Test 20

Plugin deactivate/reactivate.

42. PHP LINT

Before finalizing:

Run PHP syntax checks against EVERY PHP file.

For example:

php -l file.php

Do this for every PHP file in the plugin.

There must be:

ZERO PHP syntax errors.

43. JAVASCRIPT VALIDATION

Check every JavaScript file for:

• syntax errors
• undefined variables
• duplicate event handlers
• unhandled promises
• invalid selectors
• Elementor editor conflicts

There must be no browser console errors caused by the plugin.

44. WORDPRESS FATAL ERROR PREVENTION

Pay particular attention to common fatal errors:

Class not found
Call to undefined function
Call to undefined method
Cannot redeclare class
Cannot redeclare function
Cannot access protected property
ArgumentCountError
TypeError
Parse error
Declaration must be compatible

Search the entire plugin specifically for these risks.

45. FINAL ERROR AUDIT

Before delivering the plugin, perform a final audit:

PHP

• No fatal errors
• No syntax errors
• No duplicate declarations
• No missing classes
• No missing functions

Elementor

• No Elementor fatal errors
• Widgets register only after Elementor loads
• Editor works

JavaScript

• No console errors
• AJAX works
• Editor does not break

CSS

• No global conflicts
• Responsive behavior works

WordPress

• Activation works
• Deactivation works
• Uninstall works safely

46. DO NOT CLAIM IT IS STABLE WITHOUT TESTING

Do not tell me:

“The plugin should work.”

Actually inspect and validate the code.

If you find a problem during testing, fix it before finishing.

Do not leave known errors unresolved.

47. FINAL PLUGIN ARCHITECTURE

Use this general architecture:

pawfect-elementor-posts/
│
├── pawfect-elementor-posts.php
│
├── includes/
│   ├── class-plugin.php
│   ├── class-query.php
│   ├── class-renderer.php
│   ├── class-ajax.php
│   └── class-assets.php
│
├── elementor/
│   ├── class-elementor.php
│   ├── class-post-grid-widget.php
│   └── class-post-gallery-widget.php
│
├── assets/
│   ├── css/
│   │   ├── post-grid.css
│   │   ├── post-gallery.css
│   │   └── frontend.css
│   │
│   └── js/
│       ├── post-grid.js
│       └── post-gallery.js
│
├── languages/
│
├── readme.txt
│
└── uninstall.php

You may improve this structure if necessary, but maintain the same principles.

48. MOST IMPORTANT FINAL INSTRUCTION

I am specifically experiencing:

“There has been a critical error on this website.”

Therefore:

DO NOT prioritize adding features first.

First make the plugin fatal-error resistant and production stable.

Then implement the two Elementor widgets.

The final result must allow:

WordPress
    ↓
Plugin Activation
    ↓
No Critical Error
    ↓
Elementor
    ↓
Pawfect Elements
       ├── Pawfect Post Grid
       └── Pawfect Post Gallery

Both widgets must be fully controlled from Elementor.

The frontend design must match:

The plugin must not break the existing website even if Elementor is temporarily unavailable.

After implementation, provide a concise report showing:

1. What caused the original critical error.
2. What was changed to fix it.
3. How Elementor loading is now protected.
4. How duplicate class/function errors are prevented.
5. What compatibility checks were added.
6. What tests were performed.
7. Confirmation that all PHP files passed syntax validation.
8. Confirmation that no known frontend JavaScript errors remain.

Do not simply suppress the error.

Fix the root cause and build the plugin using defensive, production-grade WordPress architecture.