Awaiting an answer SP Page Builder Joomla 6 v6.10.0

SP Page Puilder Custom Fonts - PHP 8.5 Issue "Max size limit exceeded."

Asked by Hans 1 week ago Last activity 1 day ago

SP Page Puilder Custom Fonts - "Max size limit exceeded." This issue is widely known & discussed.

Today, I encountered a whole new dimension to this problem: On a website where custom fonts had been working fine up until now, they suddenly stopped working. Both SP Page Builder (6.10.0) and Joomla (6.2.0) are running the very latest versions.

The only thing I changed that caused these major issues was the upgrade from PHP 8.4 to 8.5 (BOTH very latest version after the bug). That’s what triggered this well-known error. So here’s a tip for anyone experiencing this error: Be sure to check your PHP version as well.

Both SP Page Builder (6.10.0) and Joomla (6.2.0) versions are explicitly certified for PHP 8.5.

At the same time, I’d like to report a reproducible bug: The current version of SP Page Builder isn’t 100% compatible with PHP 8.5, so for now, it’s better to stick with PHP 8.4.

18 replies

Robert

1 week ago

Got also SPPB 6.10.0 & J! 6.2 and running on PHP 8.5. Still my own custom fonts. But I have to say it's a modified PHP version, still 8.5.11, but a new build. And I deliver the fonts manually from my servers using a custom css file for the typo. So I wonder in what lies the difference.

Hans Asked this

1 week ago

You say "Still my own custom fonts." That implies that the fonts may have been installed under an earlier version of PHP and are still working under PHP 8.5. Is that the case?

Or did you actually try to delete your custom fonts and install new ones under PHP 8.5? That's what I did. PHP 8.5 caused the error; I rolled back to PHP 8.4, and everything worked perfectly again. It’s crystal clear that PHP 8.5 is the cause for "Max size limit exceeded" this time.

What hasn’t been proven:
I’ve come to believe that the error message "Max size limit exceeded" appears in all cases where something goes wrong with the upload, regardless of the reason. I also still believe there are a number of very different reasons that lead to this error.

Robert

1 week ago · edited

That’s correct; the fonts were installed under a different PHP version (8.3). I build my websites in MAMP Pro, where I install everything. The sites only move to a live server once it’s nearly complete—that might explain it. I upload the fonts myself, rather than using Font Book of using Helix. Perhaps this is helpful to you.

What else, I had to make a few edits in the PHP template in MAMP Pro after updating the PHP versions because I had some errors. The standard PHP template settings where used which caused errors. But that aside. You say rolled back to 8.4, I assume that is 8.4.27? Have you compared upload_max_filesize, post_max_size and memory_limit in both info files?

Hans Asked this

1 week ago

All tests were carried out under the same conditions, using both PHP 8.5 and PHP 8.4, in the following versions:
PHP Version 8.5.12-nmm1 - Issue "Max size limit exceeded."
PHP Version 8.4.27-nmm1 - Fonts upload perfectly
Everything was exactly the same; only the PHP version changed:
Upload Max Filesize 512M
Post Max Size 512M
Memory Limit 512M
Joomla:
Content>Media>Options:
Maximum Size (in MB): 110MB

Robert

1 week ago · edited

I decided to give it a try this morning. I uploaded a few fonts using Font Book, website running on PHP 8.5.12. I didn’t encounter any issues. Do note, this was done locally via MAMP Pro, running on PHP 8.5.12. My test on 8.5.12 showed no issues, so it’s becoming quite plausible that the problem lies with your hosting.

Hans Asked this

1 week ago · edited

Thank you very much for testing it. That's great, so I'm providing some additional information.
The whole topic of font uploads is still very unclear to me overall.

PHP Version 8.5.12-nmm1: This is a specially customized version provided by the web host (in this case, All-Inkl.com)

My goal was to load 4 font weights of the Roboto font locally into Page Builder.
Here’s what I did:
Attempt:
Upload each font weight individually, as described on JoomShaper.
This resulted in the following error message:
"An error has occurred.
1062
Duplicate entry ‘Roboto-local’ for key ‘family_name’"

Then I did a lot of searching and reading. I also saw that there’s quite a bit on this topic in the forum—many different posts—but they all seem to end without a solution.

I then found the following very interesting:
https://www.joomshaper.com/release/sp-page-builder-pro-next/v6.7.0
SP Page Builder 6 Pro 6.7.0
Released July 21, 2026
From the text:
"...
FIXED
Font weight options updated for locally uploaded fonts."

From this, I inferred that it might be possible to pack different font weights into a single ZIP file. Unfortunately, the description for “SP Page Builder 6 Pro 6.7.0” doesn’t specify in detail exactly which options have been updated.

However, I decided to try uploading multiple font weights in a single ZIP file, and it worked perfectly. A complete success.

After that, I upgraded PHP to the mentioned version 8.5.
Afterward, I needed two additional weights of the same font.
So I generated a new ZIP file containing all the font weights, deleted the old fonts, and tried to upload the new ZIP file with the complete set of new font weights.
That resulted in the error mentioned. Even the original ZIP file with 4 fonts (exactly the file I had uploaded before) could no longer be uploaded!!!

Since it had worked before and I had only changed the PHP version, I reverted PHP to the former version, and the font upload worked again, with the ZIP with 4 font weights and also the new ZIP with 6 font weights .

The behavior is reproducible. I switched back to PHP 8.5, and it didn't work there.

Afterward, I found the following:
SP Page Builder 6 Pro 6.10.0
Latest
Released 7 October 2026
"New
Added multi-weight support for custom fonts"
https://www.joomshaper.com/release/sp-page-builder-pro-next/v6.10.0

This means that my approach was absolutely correct—it was exactly the right way to do it—but it’s obviously not compatible with PHP 8.5, and that’s where the error lies.

Robert

1 week ago

Don’t know either, I would upload the fonts though ftp. Also no Google API keys needed. With a good Stylesheet using clamp you have all you need. Meanwhile write a message to your host to see if they can spot anything.

Hans Asked this

1 week ago · edited

I don't think All-Inkl provides a non-standard or buggy version of PHP 8.5. They have a huge number of clients, something like that would get around immediately.
The clamp function is interesting, but it won't be introduced until PHP 8.6. How do you use it in 8.5?
Another question:
Uploading fonts directly to templates/justice/fonts is straightforward—it’s clear how to do it. Is that ultimately the same as using the Page Builder’s upload feature? Do the fonts appear in the Page Builder’s Font Book?
I thought the Page Builder also handled additional configurations.
BTW, I’ve already customized the CSS in custom.css anyway.

Update:
I just checked where the fonts I uploaded with SP Page Builder Pro are stored:
Not in:
/TestJustice/components/com_sppagebuilder/assets/fonts
Nor in:
TestJustice/templates/justice/fonts

I can't find the fonts. Where are they?

Robert

1 week ago

Hi Hans,

Quick clarification on clamp: it’s a CSS function, not a PHP one, so it works in any modern browser regardless of your PHP version. I use it in custom.css for fluid typography. for quite a while now.

On fonts via FTP versus the Page Builder upload: they’re not the same thing. If you upload font files to templates/justice/fonts and load them with @font-face in custom.css, the browser just gets them through CSS. As far as I know they won’t show up in the Page Builder’s font list, because that list is managed by the builder itself (your family_name duplicate-key error suggests it stores uploaded fonts in the database). You simply use the family name in your CSS. I can’t say where the builder stores its own uploads, sorry.

This is the kind of setup I mean (adjust file names):

@font-face {
  font-family: "Roboto";
  src: url("../fonts/Roboto-Regular.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Roboto";
  src: url("../fonts/Roboto-Bold.woff2") format("woff2");
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Roboto", sans-serif;
  font-size: clamp(1rem, 0.95rem + 0.25vw, 1.125rem);
}

h1 {
  font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3rem);
}

h2 {
  font-size: clamp(1.5rem, 1.1rem + 1.8vw, 2.25rem);
}

custom.css sits in templates/justice/css/, hence the ../fonts/ path. clamp(min, preferred, max) keeps the size between a minimum and maximum while it scales with the viewport width.

For the upload error itself, check the PHP error log at the moment the upload fails.

I made a video 5 months ago about clamp: Clamp in Helix & SPPB

Hans Asked this

1 week ago

Hi Robert, thanks for the explanations.
Clamp in CSS is interesting; I’d only seen it used in PHP and had no idea it existed in CSS as well.

I also upload the fonts and reference them in CSS, as you mentioned, using:
@font-face {
That’s necessary because I need to use the fonts in sections that aren’t managed by SP Page Builder at all.

What I’m curious about is, how do you use the fonts in SP Page Builder Pro?
Page Builder Pro has “Fontbook.” That’s where I upload them, and that’s where they’re displayed.
Then, under “Settings” in SP Page Builder, there’s the “Typography” feature. That’s where presets are defined.
Presets are a handy feature for quick and convenient typography control on a website. When I change a preset, I change the font on all elements controlled by SP Page Builder and can be sure that this actually happens. That’s really cool.

Can you use this functionality even though you’re not uploading the fonts via SP Page Builder at all, but rather via FTP?
That is the real question.

Robert

1 week ago

Forget fonts in page builder, once set in your stylesheet/css no need for fonts in page builder. The stylesheet takes care of all the fonts all over your website. So leave the font selection blank in pagebuilder.

Ziaul Kabir Staff

1 week ago

Hi Hans,

Here is one answer to your questions about the upload error, the duplicate-entry error, where the fonts are stored, and whether FTP fonts work in the builder.

1. "Max size limit exceeded." on PHP 8.5

We reproduced this error. It happens when PHP's memory_limit is -1 (unlimited). With that value, a font ZIP is rejected even when it is small. We used a 1.6 MB ZIP with 32 font files. The same ZIP uploads normally when memory_limit is a number such as 512M.

I've passed it to our development team.

Your phpinfo showed 512M, but hosts often keep separate PHP settings for each PHP version, and the value your website sees can differ from the one you checked. To see what applies to your site:

Create a file info.php in your site root containing <?php phpinfo();.
Open it in the browser with PHP 8.5 selected, and note memory_limit, post_max_size and upload_max_filesize.
Do the same with PHP 8.4, then delete info.php.

(In Joomla you can also use System → System Information → PHP Information.)

If 8.5 shows -1, 0 or an empty value for memory_limit, set it to a number such as 512M in your hosting panel for that PHP version. The upload should then work. If it already shows a number, memory_limit is not your cause. Please post the three values for 8.5 and the error from your PHP error log at the moment the upload fails.

2. "Duplicate entry 'Roboto-local' for key 'family_name'"

Each upload creates a new database row for the font family, and the family name must be unique. Uploading a second weight of Roboto as a separate file therefore fails. Your ZIP approach is the right one: SP Page Builder 6.10.0 added several weights in one package.

3. Where are the fonts stored?

The files are in media/com_sppagebuilder/assets/custom-fonts/<FontName>/.
The font record is in the database table #__sppagebuilder_fonts.

They are not in the component's assets/fonts folder or in the template's fonts folder.

4. Can FTP-uploaded fonts be used in Font Book and Typography presets?

No, not as such. The Font Book list and the Typography presets read the #__sppagebuilder_fonts table (rows with published = 1). The upload creates that row and copies the files. FTP upload to templates/justice/fonts does neither, so the builder doesn't know those fonts.

On the front end, the builder loads a local font from media/com_sppagebuilder/assets/custom-fonts/<FontName>/stylesheet.css, so that stylesheet must exist under that name.

Robert's approach, with @font-face in custom.css and the font selection left blank in the builder, works for the website's styling. But you'd lose the preset control inside the builder. You can use both: upload through Font Book so the builder knows the font, and keep your @font-face rules in custom.css for the areas outside the builder, with the same family name.

Recreating what the upload does by hand (files in the folder plus a database row with type local) might work, but we haven't tested it and it isn't an official method. Don't try it on a live site without a database backup.

Please let us know what you find under PHP 8.5, and we'll look further.

Best Regards,

Robert

1 week ago

My approach is separate from the builder’s font handling entirely, and that’s simply what I find easiest to maintain. I never touch the builder’s fonts: no Font Book, no database entries. The fonts are plain files on the server, loaded with @font-face in custom.css. Since nothing in the database or the builder is changed, there’s little that can go wrong, and it’s easy to undo by removing the file or the CSS rules.

Why I prefer it:

1. Everything typographic lives in one place, so the look stays consistent across the whole site.
1. I can use clamp() for fluid font sizes: one line instead of setting desktop, tablet and mobile separately.
1. No Google API key or external requests needed, and the fonts load from my own server.
1. It’s easy to move between sites, since it’s just a CSS file and a fonts folder.

Furthermore, it is primarily a one-time task, which is also the reason why it remains low-maintenance.

The trade-off is indeed that the fonts don’t appear in the builder’s font list or presets, so the Font Book route makes more sense when clients or others edit pages themselves. For my own builds, the stylesheet is simply what I find easiest to maintain.

Martin Grunert

1 week ago

Interesting approach, Robert. ;)

Your videos have actually given me some useful ideas in the past - your work with fluid typography was one of the inspirations behind adding fluid font sizing to my own Joomla extension.

I’m currently working quite a lot on local font management and integration with different Joomla environments, so your approach of deliberately keeping typography independent from the framework and page builder is particularly interesting to me.

For experienced users, managing this directly through CSS is certainly a clean and flexible solution. At the same time, I think there are plenty of Joomla users who would prefer to avoid the manual integration and maintenance of custom CSS - or simply don’t feel comfortable writing and maintaining that code themselves.

That’s one of the reasons I started working on OD Local Fonts: trying to make local font management accessible without taking away the flexibility for users who want more control.

I’d be curious to hear your thoughts on it sometime, especially from the perspective of someone who prefers this kind of independent workflow.

And your post has already given me another idea to think about. ;)

Hans Asked this

1 week ago

I agree with Martin that managing fonts using CSS alone is the best solution for some users, but not for everyone. It’s great that Martin is offering an alternative solution for local fonts, because this issue has really caused a lot of trouble in Joomla/Page Builder so far.
Personally, however, I prefer a solution that works exactly as intended by SP Page Builder and is fully integrated into this system.
That’s why I’m now happy that, at least under PHP 8.4, I have a very clean solution that’s fully integrated into SP Page Builder.
I hope that JoomShaper will make this work under 8.5 as well.

Robert

1 week ago

The complete stylesheet is particularly helpful when it comes to fonts and how they behave on HTML-based websites. For some of my clients, I’ve offered to convert their sites into static websites—no more hassle with constant CMS updates, extensions, and stuff like that. In many cases, their websites function essentially as online brochures that rarely, if ever, require changes. And let’s be honest: once you get the hang of using an AI tool like Claude, you can build some truly impressive websites that rival modern templates—especially when you incorporate some clever CSS.

As for managing things via page builder and dealing with clients, it’s quite straightforward: the clients actually have less work to do. They simply select the heading style they want, and the rest is handled automatically by the CSS. No more fussing over different font sizes for various devices or selecting presets within an add-on. It’s simple.

Martin Grunert

1 week ago

@Hans: And that’s exactly the kind of workflow I had in mind.

The idea is not to replace the native controls of page builders or frameworks, but to complement them. For example, fonts can be managed centrally through Helix Ultimate and its typography settings can be used as the site-wide foundation, while SP Page Builder can still be used wherever more individual settings are needed.

That central approach was something I personally missed for quite some time, especially when working with different tools on the same website, and ultimately led me to develop my own solution for it.

@Robert: And I think this discussion shows the two different approaches very well. Hans prefers using the native controls of frameworks and page builders, while you deliberately keep typography independent and control it directly through CSS.

My approach so far has been to combine central font management with the native controls people are already familiar with, making it easier to use without requiring everyone to work with CSS.

But your approach of moving the typography itself into a central CSS layer is an interesting direction to think about as well. There might be a way to combine both concepts in the future: native integration for those who want it, and an optional independent approach for those who prefer centralized control.

You’ve definitely given me another idea to explore. ;)

Robert

1 week ago · edited

I made a font & clamp generator (dunno how to call it :)), see image. Upload font, do the setup and done. It also includes a live preview so you can see the result direct.

![font - clamp generator(https://ibb.co/5m7J0v0)

Martin Grunert

1 week ago

WOW - I didn't expect that. Hats off to your work! Now I just have to be careful not to copy your ideas... ;)

Funny coincidence: I added this milestone about 30 minutes ago: https://prnt.sc/SNcLdP6TYPlk

Although my approach will take a slightly different direction...

Robert

1 week ago

Have added a few more options, now you can assign whatever what you want related to the fonts. The tool gives also tips and warnings related to performance etc. Fun part is that I added a color scheme tool and a button creator. Everything works as one.

Robert

1 week ago

Hi Martin,
Here the concept as image, everything works like a charm.

https://ibb.co/F4NVmX96

Hans Asked this

1 week ago

@Ziaul: Thank you for the clarification

@Robert: Thank you so much for always responding and constantly thinking of ways to find practical solutions beyond the SP Page Builder Pro local font management.
These insights are very valuable because the issue of local font management in SP Page Builder Pro has caused far too much confusion and frustration up to this point. This is also evident in the forum threads, which have never led to a satisfactory solution—at least, I haven’t been able to find anything of the sort. I can therefore fully understand why Robert is relying exclusively on a solution that doesn’t require Joomla administration.

Regarding our topic:
Currently however, I get the impression that JoomShaper has actually improved things since SP Page Builder Pro 6.10 running on PHP 8.4.
That’s why I’m particularly pleased with Ziaul’s response, which is more detailed than any other answer I’ve seen on this topic so far. In particular, it is important to clarify in the documentation that fonts no longer need to be uploaded individually, but rather as a package. So far, this issue has only been hinted at in a release note for version 6.10. The documentation still refers to individual fonts! This is exactly what no longer works when dealing with different styles of a single font.
If the issues are now resolved and local installations are running smoothly, then it’s imperative that JoomShaper update its documentation so it doesn’t drive people crazy. And I have to say that everything is now running smoothly for me—but only under PHP 8.4, definitely not under PHP 8.5.

Of course, it would be great if local fonts now worked with PHB 8.5, which is officially certified.

Regarding PHP 8.5:
Joomla! Version Joomla! 6.2.0 Stable
PHP Version 8.5.12-nmm1
Upload Max Filesize 512M
Post Max Size 512M
Memory Limit 512M
Font upload : Error, see above

Regarding PHP 8.4:
Joomla! Version Joomla! 6.2.0 Stable
PHP Version 8.4.27-nmm1
Upload Max Filesize 512M
Post Max Size 512M
Memory Limit 512M
Font upload: OK, all very good

Ziaul Kabir Staff

1 week ago

Hi Robert,

Thank you for the detailed feedback and for confirming that local font management works correctly under PHP 8.4.

I’ve also tested this under PHP 8.5, and I haven’t encountered the same issue. Since the reported PHP limits are identical in both environments, we’ll need to investigate further to determine why the upload fails on your PHP 8.5 setup.

Could you please help us investigate this by trying the following steps under PHP 8.5?

Verify the actual PHP settings: Create an info.php file in your site root containing <?php phpinfo();, open it in your browser, and check the values of memory_limit, post_max_size, and upload_max_filesize. Please delete the file afterward for security reasons.
Check the upload request: Open your browser’s Developer Tools → Network tab, attempt to upload the font package, and select the uploadFont request. Please share its HTTP status code and response.
Check the PHP error log: Share any relevant error log entries from the time the upload fails.
Test with a small ZIP: Try uploading a small ZIP containing just one font file. If it fails with the same error, this may indicate an issue with the upload size validation. If only larger ZIP files fail, it may be related to the request size.

These results will help us determine whether this is a PHP 8.5 compatibility issue, a server configuration difference, or a problem with the font upload validation in SP Page Builder Pro.

We’ll also review the documentation to clarify that font families with multiple weights and styles should be uploaded as a package rather than as individual files.

Thank you for your patience and for helping us investigate this issue.

Best Regards,

Robert

1 week ago · edited

Hi,

I only had an issue with wrong values after updating the PHP versions, MAMP Pro gave the default values: MAMP_memory_limit_MAMP, so changed in into this:

max_execution_time = 300
memory_limit = 512M

That is all.

I created this info.php file with so check:

<php var_dump(ini_get('max_execution_time'), ini_get('memory_limit'), ini_get('upload_max_filesize'), ini_get('post_max_size'), php_ini_loaded_file());

Before php put '?'
This editor doesn't allow the correct code.

I only checked locally.

Ziaul Kabir Staff

1 week ago

Hi Robert,

Thanks for checking this and for posting your values. The MAMP_memory_limit_MAMP placeholder is a useful warning for anyone who sees odd behaviour after switching PHP versions.

We tested that value against SP Page Builder's font upload check, and it doesn't cause "Max size limit exceeded." The values that do cause it are -1, 0 and an empty memory_limit. So your placeholder wasn't the same problem, though it is the same kind of surprise after a PHP update.

Hans is on All-Inkl, not MAMP, so we're waiting for his phpinfo() values and the response of the uploadFont request under PHP 8.5.

Thanks again for your time on this.

Hans Asked this

1 week ago · edited

Dear Ziaul, I already posted my PHP settings for the All-Inkl server—both for V8.4 and V8.5—yesterday, at the end of my longer post. See above.
I'm glad you're looking into this.

Ziaul Kabir Staff

1 week ago

Our dev team is checking the issues. I will update you once I get information from them.

Best Regards,

Hans Asked this

1 week ago

Thank you very much

Hans Asked this

1 day ago · edited

Dear Ziaul, is there any news from your dev team?