Awaiting an answer SP Page Builder Joomla 5 v6.10.0

SP Page Builder 6.10.0 Pro – Excessive Bandwidth Usage and Unexpected Changes to Manual Page Ordering

Asked by Tanidis Triantafillos 2 weeks ago Last activity 42 minutes ago

Hello JoomShaper Support Team,

We are experiencing two serious issues with SP Page Builder Pro on a Joomla development website.

Environment:

SP Page Builder Pro: 6.10.0
Joomla: 5.4.9
PHP: 8.3.36
Website: https://dev.agorazin.gr/
Approximately 99 published pages and 137 trashed pages

1. Excessive bandwidth consumption in the Pages manager

Our website normally consumes approximately 2 GB of bandwidth per month. However, during October 2026, bandwidth usage increased dramatically, reaching over 42 GB.

After analyzing the server access logs and Chrome DevTools Network activity, we identified repeated requests to the SP Page Builder Pages API:

/administrator/index.php?option=com_sppagebuilder&task=/editor.pages&limit=100&sortBy=ordering

Our findings include:

Approximately 13.29 GB transferred through editor.pages requests in a single day's access log.
591 requests to this endpoint.
Individual responses reaching approximately 44 MB.
Reducing the Pages list limit from 500 to 10 decreased one observed response from approximately 38.3 MB to 3.8 MB.

The requests originated primarily from an authorized administrator working in SP Page Builder.

Our questions:

Is this amount of data transfer expected when managing approximately 100 pages?
Why does the Pages API return such large responses?
Does the API include trashed pages or their content when retrieving the published Pages list?
Is there a known performance issue or recommended optimization for this behavior?

2. Manual page ordering unexpectedly changed

Our client manually arranged approximately 100 pages in a specific sequence using the Pages manager.

After using the search function to locate a page, she noticed that her carefully arranged order was no longer preserved.

We tested both Ordering Ascending and Ordering Descending, but neither restored her previous arrangement.

We also inspected the ordering values directly in the Joomla database.

For example, the client confirms that these four published pages were previously arranged consecutively:

ΚΑΡΑΜΕΛΕΣ
Candy Mini Basic 0549
Candy maxi Basic 0034
Candy maxi Basic 0034 Plus

Their current database values are:

Page	ID	Ordering
ΚΑΡΑΜΕΛΕΣ	181	24
Candy Mini Basic 0549	216	25
Candy maxi Basic 0034	195	28
Candy maxi Basic 0034 Plus	197	31

Other published pages now occupy positions 26, 27, 29 and 30.

This indicates that the stored ordering no longer matches the sequence established by our client.

We have not confirmed whether the search operation caused the changes, but the client noticed the issue immediately afterward.

Our questions:

Is this a known issue in SP Page Builder 6.10.0?
Can searching, sorting or changing the Pages list limit accidentally modify stored ordering values?
Is there a safe way to restore the previous manual ordering?
Is there a fix or update that prevents this from happening again?

We have preserved the current database values and can provide screenshots, SQL results and relevant access-log excerpts.

We would appreciate your investigation and guidance, particularly because the client relies heavily on manual page ordering for her daily work.

Thank you in advance for your assistance.

Best regards

7 replies

Atick Eashrak Shuvo Staff

1 week ago

Hello,

We apologize for the inconvenience caused by these issues.

Thank you for providing such a detailed report and for sharing your findings. The access logs, network activity, and database ordering values will be helpful in investigating both the excessive bandwidth consumption and the unexpected changes to the page ordering.

To help us investigate these issues more thoroughly, would you please confirm whether we have your permission to take a full backup of your website, including its files and database? This will allow our development team to examine the current state of the website and investigate the issues more closely without risking the existing data.

We appreciate your cooperation and patience. We will proceed with the investigation once we receive your confirmation.

Best regards

Tanidis Triantafillos Asked this

1 week ago

Hello JoomShaper Support Team,

Thank you for your response and for looking into these two issues.

You have our permission to create a full backup of the development website, including its files and database, for investigation purposes.

However, we kindly ask that any testing or debugging that could affect the website's content.

Please let us know your findings, whether these are known issues in SP Page Builder Pro 6.10.0, and if a fix or workaround is available.

Thank you for your assistance. We look forward to your findings.

Best regards

Tanidis Triantafillos Asked this

1 week ago

Urgent Follow-up – SP Page Builder Pages Manager Now Completely Unavailable (HTTP 500)

Hello JoomShaper Support Team,

I am following up on our open support ticket regarding the excessive bandwidth consumption and the unexpected changes to the manual page ordering in SP Page Builder Pro 6.10.0.

Could you please let us know if there are any updates from your development team regarding these issues?

Unfortunately, the situation has now become even more serious.

The SP Page Builder Pro Pages Manager is no longer loading the list of available pages. Instead, we are receiving the following error:

Request failed with status code 500

I have send a screenshot showing the issue: https://prnt.sc/yDL-sLq85NsX

This means that we can no longer access the existing pages to edit their content or carry out our daily work.

Previously, despite the problems with manual page ordering, we could at least access and edit individual pages. Now, even that is no longer possible.

This is a critical issue for us, as it is effectively preventing us and our client from managing the website's content.

We understand that your development team may need time to investigate the underlying causes. However, given the current situation, we would greatly appreciate it if this ticket could be treated as a high-priority issue.

Could you please clarify:

Has your development team made any progress in investigating the previously reported issues?

Is the HTTP 500 error potentially related to the unusually large responses from the editor.pages API?

Is there any immediate workaround that would allow us to access and edit our existing pages while the investigation continues?

Can you provide an estimated timeframe for an update or a possible resolution?

Our immediate priority is to restore access to the Pages Manager so that we can continue working, even if the manual ordering issue remains unresolved temporarily.

We would really appreciate your prompt assistance, as this situation is now seriously affecting our daily operations.

Thank you for your attention and support.

Best regards

Atick Eashrak Shuvo Staff

1 week ago

We apologize for the inconvenience.

Unfortunately, I haven't received any updates from our development team regarding the previously reported issues yet.

Regarding the Pages Manager issue, I accessed your website's backend and checked the page listing. It appears to be loading correctly from my end, as shown in this screenshot: https://prnt.sc/W9qNW5p9SERv

Since the issue isn't occurring on my end, could you please clear your Joomla cache and browser cache, then check again? If the issue persists, please let us know so we can investigate further.

We appreciate your patience and understanding while we look into these issues.

Klaus Decker

1 week ago

We've noticed a similar error on our site since the update to version 6.10.0. There's a programming error in the page editor. When opening a page for editing, the editor attempts to display a preview of 20 articles. To do this, however, it loads all 20,000+ articles—including their full text—each time, and then discards almost all of it. It doesn’t do this just once, but 44 times simultaneously, until our PHP limit is reached. This resulted in a 500 error. That's why the error occurred right when we opened the page in the editor, rather than immediately after the update.

Here's what we did: We corrected an error in the “dynamic_content.php” file. Now the editor only loads the 20 articles it actually needs, which significantly reduces traffic and server load.

Tanidis Triantafillos Asked this

1 week ago

Hello JoomShaper Support Team,

I would like to sincerely thank you and your development team for your assistance in resolving the issues we were experiencing with SP Page Builder Pro 6.10.0.

Our client has been working in SP Page Builder and has confirmed that the Pages Manager is now functioning normally, allowing her to access and edit pages without the previous HTTP 500 errors.

We truly appreciate the time and effort your team dedicated to investigating and fixing this problem.

I have also been monitoring the website's bandwidth consumption. We will continue monitoring the website over the coming days.

Thank you once again for your excellent support!

Best regards

Toufiq Senior Staff

6 days ago

Hello,

Thank you for your kind words and for sharing the update. We’re glad to hear that the Pages Manager is now working as expected and that your client can access and edit pages without encountering HTTP 500 errors.

We appreciate you monitoring the website’s bandwidth consumption. Please continue to keep an eye on it over the coming days, and if you notice any unusual activity or issues, feel free to let us know. We’ll be happy to assist you further.

Thank you for your patience and cooperation throughout this process.

Best regards,
JoomShaper Support Team

Tanidis Triantafillos Asked this

42 minutes ago

Hello JoomShaper Support Team,

Thank you again for your assistance in resolving the HTTP 500 errors and improving the Pages Manager's performance.

Unfortunately, we are still experiencing two issues that we would appreciate your help with.

Manual Page Ordering – Our Main Priority

The previously reported issue with manual page ordering remains unresolved.

Our client continues to manually arrange approximately 100 pages in her preferred order, but the sequence changes unexpectedly after some time, and the manually configured ordering is lost.

This has happened repeatedly, forcing her to spend considerable time rearranging the same pages.

As mentioned in our original report, we have already examined the ordering values in the database and provided examples demonstrating that the stored order does not match the sequence configured by our client.

This is currently our most important issue, as it directly affects our client's daily workflow.

Could your development team please investigate why the manually configured ordering is not being preserved and whether there is a fix or reliable workaround?

We would also appreciate knowing whether searching, sorting, refreshing the Pages Manager, or changing the number of displayed pages could affect the saved ordering values.

Bandwidth Consumption – Still Higher Than Expected

Although the previous HTTP 500 errors have been resolved and the Pages Manager is functioning again, we are still concerned about bandwidth consumption.

Over the last five days, the development website has consumed approximately 8.7 GB of traffic.

During this period, our client has been working in SP Page Builder every day.

The development website does not receive significant public traffic, and we are not aware of any other activity that would explain this level of bandwidth consumption.

Given the previously identified performance issues and unusually large responses from the editor.pages API, we are concerned that some excessive data transfer may still be occurring.

Could you please review this as well and confirm whether this level of bandwidth usage is expected during normal SP Page Builder administration?

If necessary, we can provide additional server logs or network activity details.

Our immediate priority is resolving the manual page ordering issue, but we would also appreciate a further review of the bandwidth consumption to ensure that the previous performance problem has been fully addressed.

Thank you for your continued assistance. We look forward to your findings and recommendations.

Best regards,
Triantafillos Tanidis