Slow website load while plugin is active

Smexhy
(@smexhy)

5 months, 3 weeks ago
For some weird reason, whenever I activate this plugin, backend starts loading like 10-20 seconds every time I try to load any page. Network tab clearly shows 15s+ load time of asset “wp-content/plugins/wp-hotel-booking/assets/js/admin/room-filter.min.js?ver=6933c3988edeb” whatever is it responsible for because of 404 status. It makes the site basically unusable. Any idea what could be responsible for this? Also Another issue is with wp-json/wp/v2/users/me?context=edit&_locale=user but again only with this plugin active, so I suppose it’s responsible in one way or another.
- This topic was modified 5 months, 3 weeks ago by Smexhy.
- This topic was modified 5 months, 3 weeks ago by Smexhy.
- This topic was modified 5 months, 3 weeks ago by Smexhy.

Viewing 3 replies - 1 through 3 (of 3 total)

Thread Starter Smexhy
(@smexhy)

5 months, 3 weeks ago
I did some digging and found the cause of the 30-second timeout. It’s in includes/class-wphb-session.php.

On lines 17-19, the code forces a session_start() on every page load without checking if the user is in the admin panel:

PHP
```
if ( ! session_id() ) {
   @session_start( array( 'read_and_close' => true ) );
}
```
This causes session locking on the backend, which freezes the dashboard.

I’ve temporarily fixed it on my site by wrapping it in a check so it doesn’t run in the dashboard:

PHP
```
// Only run if NOT admin
if ( ! is_admin() && ! defined( 'DOING_CRON' ) && ! session_id() ) {
   @session_start( array( 'read_and_close' => true ) );
}
```
Could you please implement a similar check in the next version update? Currently, the plugin is unusable on the backend without this patch.

Also, regarding the 404 error I mentioned, the plugin is looking for room-filter.min.js but the folder only contains the un-minified room-filter.js. I had to rename the file manually to stop the 404.
Thread Starter Smexhy
(@smexhy)

5 months, 3 weeks ago
After implementing the !is_admin() check (which completely fixed my slow backend loading), I found that the plugin’s session handling was still causing a consistent 13-16 second hang on the frontend during page loads and redirects.

The issue seems to be that when the session starts on the frontend:

PHP
```
// Only run if NOT admin
if ( ! is_admin() && ! defined( 'DOING_CRON' ) && ! session_id() ) {
    @session_start( array( 'read_and_close' => true ) );
}
```
…the read_and_close flag isn’t reliably releasing the lock on my server environment. This causes the classic session locking scenario, where one page hangs up all subsequent requests until the timeout is hit.

I was able to fix the frontend lag immediately (bringing load times down from 16 seconds to 2 seconds!) by forcing the write lock to close:

PHP
```
if ( ! is_admin() && ! defined( 'DOING_CRON' ) && ! session_id() ) {
    @session_start();
    session_write_close(); // Explicitly releases the write-lock
}
```
My question for your team:
1. Could you please confirm if using session_write_close() here is safe for all core booking functionality? I’m hoping to verify that I haven’t broken any necessary server-side writes, although it seems safe since the plugin relies heavily on cookies for persistence.
2. If it looks good, please implement both the !is_admin() check and this explicit session_write_close() command in the next version update.
- This reply was modified 5 months, 3 weeks ago by Smexhy.
Plugin Support brianvu-tp
(@briantp)

5 months, 2 weeks ago

Hi Smexhy,

Thank you very much for contacting us and for taking the time to investigate the issue in such detail.

Our team will evaluate these changes carefully to ensure they are fully compatible. If your approach is safe for general use, we will include the improvement in an upcoming update of the plugin.

Thank you again for your helpful feedback.

Best regards,
Brianvu-tp

Viewing 3 replies - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.