Solved SP Page Builder

Disappointed by the way JoomShaper restricted local font support in SP Page Builder

Asked by Martin Grunert 3 weeks ago Last activity 3 weeks ago

I have been using JoomShaper products for more than nine years. With OD Local Fonts, I never intended to compete with JoomShaper. The purpose of the extension was to complement Helix Ultimate, Helix 2 and SP Page Builder by making it easier for users to work with locally hosted and variable fonts.

From the beginning, I kept Paul Frankowski informed about the project, its goals and its development. I shared new features with him and provided early versions for testing, so it was transparent from the start what ODLF was intended to do.

With version 1.4.0, I added the SP Page Builder integration. At that time, local fonts could be used with multiple styles and weights. Variable fonts could also be integrated, and their weight range could be selected in the Typography editor. I tested this functionality and it worked as intended.

While comparing older and current SPPB versions, I discovered that this capability was later restricted. In SPPB 6.3.2, selecting multiple weights for local fonts was still possible. In current versions, however, the JavaScript explicitly limits local fonts to 400 / Normal and disables the weight field. This restriction is still present in SPPB 6.9.0.

This means that my implementation was technically correct and worked as designed. The limitation was introduced later directly within SP Page Builder.

I have to say that I am deeply disappointed by the way this situation has been handled. I understand that not every feature can or should become part of the official product. However, restricting a previously working capability without any transparent explanation has made it impossible for my extension to provide the functionality it was designed and tested to deliver.

I do not want ODLF to compete with JoomShaper. If certain features are not intended to be part of the official product scope, I can understand that. However, why should a third-party extension not be allowed to extend those features for users who need them? A strong extension ecosystem makes it possible to cover specialised requirements without JoomShaper having to implement and support every possible use case itself.

This raises an important question for me:

On what technical or conceptual grounds was the selection of local font weights disabled, and why was a previously working third-party integration subsequently restricted?

I would appreciate a transparent explanation. This is not about telling JoomShaper which features must be part of SP Page Builder. It is about understanding why a previously possible extension was later restricted, even though it simply added functionality for users who wanted to use local and variable fonts.

For reference, here is the original forum discussion related to this topic:
https://www.joomshaper.com/forum/question/44930

Accepted answer

Marked as the solution

Atick Eashrak Shuvo Staff

3 weeks ago

Hello Martin,

Thank you for your understanding and for taking the time to assess and test the workaround.

I appreciate your feedback regarding the communication, and I’m glad we were able to clarify the technical aspects and establish a practical path forward. Please proceed with testing and refining the ODLF-side implementation for your 2.0.1 release.

I believe we can consider this matter clarified and resolved from our side. Thank you again for the constructive discussion.

Martin Grunert Asked this

3 weeks ago

Thank you, Atick. I have marked your answer as accepted.

The first test of the planned ODLF 2.0.1 implementation has been successful: locally hosted font families can again use their available weights in the SP Page Builder editor, while SP Page Builder core files remain untouched.

My goal has always been to improve the product experience for users. In particular, locally hosted fonts matter greatly for many European website operators, where privacy and GDPR requirements make reducing unnecessary third-party requests especially important.

I appreciate that we were ultimately able to find a practical solution.

15 more replies

Martin Grunert Asked this

3 weeks ago

I have found an additional detail that makes an official explanation from JoomShaper even more necessary.

In JoomShaper’s own Anobiz Quickstart package, Plus Jakarta Sans is installed through the SP Page Builder Font Book with four styles. In the Typography editor, all four weights - Normal, Medium, Semi Bold and Bold - are available and selectable.

https://prnt.sc/MWa1sHRDGUiu https://prnt.sc/6Vs9vzX9AmFa

I also checked the frontend output. The font is served locally by SP Page Builder from:

Plain text

/media/com_sppagebuilder/assets/google-fonts/Plus Jakarta Sans/stylesheet.css

There is no external request to Google Fonts involved.

This demonstrates that SP Page Builder is technically capable of handling locally stored fonts with multiple weights. JoomShaper itself uses this capability in its own Quickstart packages.

At the same time, fonts classified as local in SP Page Builder are explicitly restricted to 400 / Normal, and the weight selector is disabled for them.

This means that the capability exists and is used internally by JoomShaper, while the same functionality is explicitly blocked for local fonts provided by users or third-party integrations.

This is no longer simply a question of whether SP Page Builder technically supports multiple weights for locally hosted fonts - it clearly does.

The important question is therefore:

Why does JoomShaper restrict this functionality for user-provided local fonts while using the same underlying capability in its own products and Quickstart packages?

I believe this deserves a clear technical explanation from JoomShaper.

Atick Eashrak Shuvo Staff

3 weeks ago

Hi Martin,

We sincerely apologize for the inconvenience and frustration this situation has caused.

We understand your concern regarding the changes in SP Page Builder and how they have affected your third-party extension. However, we would like to clarify that SP Page Builder is a standalone product, and our primary responsibility is to maintain its functionality, stability, performance, and security as part of our own product roadmap.

While we understand that third-party extensions may integrate with SP Page Builder, we cannot guarantee that an external extension will continue to work unchanged across future versions. As SP Page Builder evolves, we may modify its internal implementation, editor behavior, APIs, or other functionality for technical, compatibility, performance, or security reasons. Third-party extensions that depend on those internal behaviors need to adapt accordingly to remain compatible with the latest versions.

We would also like to point out that our official SP Page Builder documentation does not state or guarantee compatibility with third-party local-font extensions or integrations. Furthermore, local font management is already a built-in feature of SP Page Builder, so users can manage and use locally hosted fonts directly through the functionality provided by the product.

Regarding the differences you observed between previous and current versions, the fact that a particular behavior was possible in an earlier version does not necessarily mean that it represents a permanently supported public API or a guaranteed third-party integration point. Internal functionality can change as the product develops.

We appreciate the time and effort you have invested in developing ODLF and understand that these changes have created additional work for you and your customers. However, maintaining compatibility with a third-party extension ultimately requires the extension to adapt to changes made within SP Page Builder.

We hope this clarifies our position and the distinction between built-in SP Page Builder functionality and third-party integrations.

Thank you for your understanding.

Martin Grunert Asked this

3 weeks ago

Thank you for your response. Unfortunately, it does not address the main concerns I raised and reads primarily as a general disclaimer regarding third-party compatibility.

I fully understand that SP Page Builder is a standalone product and that JoomShaper must be able to change internal implementation details. However, this is not simply a case of an undocumented internal API changing. A capability that previously worked for third-party integrations was deliberately restricted in the editor interface: local fonts are reduced to a single 400 / Normal option and the weight field is disabled.

To make the timeline and the original context clear, I am attaching an image from my original forum post from one year ago. It explicitly described the planned variable-font support and the possible SP Page Builder integration. I also stated that I wanted to receive JoomShaper’s feedback first, adjust the project accordingly, and only then share it with the community.

The original post included the following statement:

“I’d love to hear JoomShaper’s feedback first. I’ll polish based on that and then share it with the community.”
https://prnt.sc/eeSNMUztuufP https://prnt.sc/zdKYfZdg0TeG https://prnt.sc/MJBs-yoh8dr3
https://www.joomshaper.com/forum/question/41002

This was therefore not an undisclosed or unexpected third-party project. The intended direction was publicly visible from the beginning, and there was an opportunity to raise concerns before the integration was developed, released and used by customers. If this type of integration was considered problematic or unsupported in principle, this would have been the appropriate time to communicate that.

Several important points remain unanswered:

The purpose of ODLF was disclosed from the beginning.

My original forum post clearly explained what I was developing and how it was intended to integrate with Helix Ultimate, Helix 3 and SP Page Builder. I also kept Paul Frankowski informed about the project, its purpose and its development.

If this type of integration was considered unacceptable or unsupported in principle, that could and should have been communicated at that time - before users relied on the functionality and before I invested substantial development effort into it.

The implementation was working before it was restricted.

In SP Page Builder 6.3.2, multiple weights could still be selected for locally hosted fonts. My integration worked correctly in that environment. In current versions, the JavaScript explicitly treats fonts classified as local differently by limiting them to 400 / Normal and disabling the weight selector.

This is not merely an accidental incompatibility caused by an internal refactoring. It is an explicit product decision affecting the editor UI.

The security and compatibility explanation does not match the actual implementation.

JoomShaper’s own products and templates use variable fonts internally, and the community has repeatedly asked for broader variable-font support.

At the same time, SP Page Builder permits locally hosted Google-font files with multiple weights, while restricting user- or third-party-provided local fonts through a simple local type check and a disabled form field.

If the concern were genuinely security, performance or technical compatibility, it would be important to explain why one category of locally served font files is allowed to expose multiple weights while another category is explicitly blocked.

A CSS file served locally is not inherently less secure because it was provided by a third-party extension rather than shipped by JoomShaper. Likewise, allowing Google Fonts while disabling local third-party fonts does not, by itself, constitute a meaningful security boundary.

The third-party ecosystem is part of the SP Page Builder model.

JoomShaper documents custom addons, integrations and extension mechanisms for SP Page Builder. Third-party developers are encouraged to extend the product for specialised use cases rather than forcing every feature into the core.

It is therefore contradictory to promote extensibility while simultaneously stating that third-party extensions must expect to be blocked whenever their functionality does not match an internal product decision.

I am not asking JoomShaper to officially implement or support every third-party extension. I am asking why a previously possible integration was intentionally restricted without a transparent warning or a documented technical reason.

The issue is not that JoomShaper refuses to guarantee compatibility forever. No developer can reasonably demand that. The issue is that SP Page Builder previously allowed this use case, the use case was publicly disclosed, users relied on it, and the capability was later disabled in a targeted way without any clear communication to affected developers or users.

This has had real consequences. I developed ODLF on the basis of functionality that was available and working, corrected my documentation when necessary, received customer complaints and had to deal with refund requests after the restriction was introduced.

Telling affected third-party developers simply to “adapt” is not an adequate response when the product intentionally removes the capability they relied on without explaining the reason or offering an alternative integration path.

It is particularly difficult to reconcile the statement that third-party extensions are supported with the suggestion that developers must simply accept being blocked whenever JoomShaper decides that a particular extension use case is no longer desirable.

**I would therefore still appreciate a specific statement from JoomShaper:

Was the restriction of multiple weights for local fonts intentional?
What concrete security, performance or compatibility problem does it address?
Why are locally hosted Google-font files treated differently from user- or third-party-provided local fonts?
Was the intention to prevent third-party extensions from extending this part of SP Page Builder?
Is there any supported extension point through which a third-party integration can provide local and variable-font weights without modifying or bypassing SP Page Builder?**

A generic statement that internal behaviour may change does not answer these questions. It only explains why JoomShaper does not want to guarantee permanent compatibility. That is a different matter from explaining why a previously working and publicly disclosed integration was deliberately restricted.

For reference, I have attached screenshots and links documenting:

the original public announcement of the project and its planned SP Page Builder integration;
the previous SP Page Builder behaviour;
the current restriction of local-font weights;
JoomShaper’s own use of variable fonts.

I would appreciate a transparent technical and conceptual explanation of this decision, as well as a clear statement regarding the intended role of third-party integrations within the SP Page Builder ecosystem.

Martin Grunert Asked this

3 weeks ago

Additional clarification regarding the integration

To avoid any misunderstanding: OD Local Fonts does not provide a general public API for third-party extensions. The integration uses Joomla’s existing extension mechanisms, plugin events and the interfaces exposed by the respective Joomla extensions. It does not modify SP Page Builder core files and does not rely on a private or undocumented API.

This is also why the original public project discussion is relevant. The project and its intended integrations were already presented approximately one year ago. Paul Frankowski described it as “BIG WOW and IMPRESSED of talent”, stated that he would start testing it, and asked for a usage tutorial.

The attached screenshot documents that exchange. It shows that the project was known and positively acknowledged at the time. If there were concerns regarding this type of integration, JoomShaper had an opportunity to raise them during the development and testing phase.

Therefore, the current issue is not about demanding a permanent compatibility guarantee or claiming that ODLF has a public SPPB API. The issue is that a previously working third-party integration was later restricted through an explicit local font-type check, without a clear technical explanation or documented extension path for affected developers.

Atick Eashrak Shuvo Staff

3 weeks ago

Hi Martin,

Thank you for the detailed clarification and for providing the additional context.

We understand your concerns and appreciate the fact that you disclosed your project and its intended SP Page Builder integration beforehand. We also understand that your concern is not simply about compatibility guarantees, but about the change in how local fonts are handled in newer versions of SP Page Builder.

That said, we would like to clarify a few important points regarding the role of third-party integrations.

SP Page Builder is developed and maintained as a standalone product. Our development decisions are primarily based on the requirements, architecture, stability, performance, security, and long-term maintainability of SP Page Builder itself. While we provide extension mechanisms and allow developers to build integrations around SP Page Builder, this does not mean that every existing behavior of the editor is intended to serve as a permanent extension point for third-party products.

When a third-party component or extension is developed to integrate with another product, the responsibility for maintaining that integration ultimately lies with the third-party developer. The underlying product will continue to evolve, and its internal implementation, interfaces, and behavior may change over time. Therefore, a third-party extension needs to adapt to those changes to remain compatible with newer versions. The responsibility of the core product is to continue developing and maintaining its own functionality; it is not to preserve previous internal behavior specifically for the continued operation of an independently developed third-party extension.

Regarding the specific local-font behavior you mentioned, we acknowledge that the behavior has changed between versions. However, we cannot consider the previous editor behavior as a commitment that the same behavior would remain available for third-party integrations indefinitely.

The fact that local fonts can be handled differently in some of our own templates or Quickstart packages does not necessarily mean that every aspect of that implementation is exposed as a supported third-party API or extension mechanism. Our own packages are developed and tested together with SP Page Builder and therefore may rely on functionality that is part of our internal product implementation.

We also want to clarify that the intention is not to prevent third-party developers from creating extensions for SP Page Builder. We welcome extensions and integrations that complement our products. However, third-party developers need to build against the supported functionality of the product and adapt their integrations when changes are made to the core product.

Regarding your specific questions:

Was the restriction of multiple weights for local fonts intentional?
The current behavior is part of the current SP Page Builder implementation. However, we do not treat the previous behavior as a guaranteed third-party extension point.
Was it introduced specifically to prevent ODLF or other third-party extensions?
No. This should not be interpreted as a restriction introduced specifically against ODLF.
Why is the implementation different in JoomShaper's own packages?
Our Quickstart packages and templates are maintained as part of our own product ecosystem and can use functionality that is not necessarily exposed as a supported third-party API.
Is there a supported extension point for overriding the current local-font weight behavior?
We do not currently provide a documented extension API that guarantees the ability to override this particular editor behavior. We would therefore not recommend relying on modification or interception of internal JavaScript behavior as a supported integration method.

We also want to emphasize that SP Page Builder already provides built-in local font functionality. Users can manage locally hosted fonts through the functionality provided directly by SP Page Builder, without requiring a third-party extension for basic local-font management.

Most importantly, we do not want to suggest that your work or the effort invested in ODLF was not legitimate. We understand that it was developed around functionality that was available at the time and that subsequent changes have created additional work for you and your customers.

However, the fact that an integration worked with a particular version does not transfer responsibility for maintaining that integration to the underlying product. If a third-party component depends on a particular behavior of another component, it is the third-party component's responsibility to accommodate changes introduced by the underlying product. This is a normal consideration when developing integrations against independently maintained software.

We appreciate your feedback and understand your request for greater clarity. Nevertheless, we cannot commit to preserving previous implementation behavior solely for the purpose of maintaining compatibility with a third-party extension.

We hope this clarifies the distinction between supported SP Page Builder functionality, internal product behavior, and third-party integrations.

Thank you for your understanding.

Martin Grunert Asked this

3 weeks ago

One short question remains: do you actually have a problem with OD Local Fonts because it delivers features that the community has been requesting for years, while JoomShaper has chosen not to implement them - or has been unable to do so? 😉

Atick Eashrak Shuvo Staff

3 weeks ago

Hi Martin,

No, we do not have any issue with OD Local Fonts providing features that users may find useful or that have been requested by the community.

The changes you are referring to are not related to OD Local Fonts or any other third-party extension. They are part of the internal development of SP Page Builder and are made based on our own product requirements, architecture, functionality, stability, compatibility, and security considerations.

Our decisions regarding how SP Page Builder handles local fonts are therefore made independently of whether a third-party extension provides similar or additional functionality. The intention is not to prevent ODLF from offering features that are not currently available in SP Page Builder.

As mentioned previously, SP Page Builder already includes its own local-font functionality, and we will continue to improve and maintain that functionality as part of the core product.

We also want to make it clear that you are welcome to adapt ODLF to work with the current SP Page Builder system. However, as a third-party developer, maintaining compatibility with changes introduced by the underlying product is part of the responsibility of the third-party integration. We cannot be expected to preserve previous internal behavior specifically to maintain compatibility with an independently developed extension.

We hope this clarifies that the changes were not made because of ODLF or because it provides functionality requested by the community. They are related solely to the ongoing internal development, functionality, compatibility, stability, and security of SP Page Builder.

Thank you for your understanding.

Martin Grunert Asked this

3 weeks ago

I understand that SP Page Builder is a standalone product and that JoomShaper does not want to guarantee compatibility with every third-party extension. However, this does not address the actual criticism.

The relevant functionality was not merely lost as an accidental side effect. In the code, the corresponding behavior was deliberately changed from enabled to disabled for local fonts. At the same time, Google Fonts continue to receive different treatment and retain access to multiple weights, even though their implementation requires requests to Google servers - a privacy concern in the EU unless the required legal conditions and user consent are properly met.

The repeated reference to APIs is also not applicable here. OD Local Fonts does not use a private SP Page Builder API or modify SP Page Builder core files. It uses Joomla’s extension mechanisms and the functionality that SP Page Builder previously exposed.

It is also disappointing that, apart from Paul, nobody from the development team publicly engaged with OD Local Fonts in the original discussion. This is particularly unfortunate because ODLF has been mentioned in several forum posts, users are already using it, and users have explicitly asked about this type of functionality. Despite that, there was no communication that SP Page Builder would introduce restrictions affecting those integrations.

Instead of considering cooperation with an existing extension that provides functionality requested by the community, JoomShaper has chosen to restrict that functionality and then place the entire responsibility for adapting the integration on the third-party developer. Saying that third-party extensions are welcome to improve or complement JoomShaper products, while silently restricting a previously working integration without providing a supported alternative, is contradictory.

The discussion continues to focus on responsibility and compatibility guarantees, but the fundamental question remains unanswered: why was this specific restriction introduced? General references to architecture, stability, compatibility or security are not a technical explanation. In particular, the security argument remains unsubstantiated, as no concrete security risk has been identified.

I therefore want to be clear: I do not agree with or accept this approach, and I do not consider the current explanation satisfactory. The communication surrounding this change and the treatment of third-party integrations have been disappointing.

It is now apparent that JoomShaper does not wish to provide a fundamental explanation for the actual reason behind this restriction.

You state that I am welcome to adapt ODLF to work with the current SP Page Builder system. However, you have also confirmed that there is no documented extension API or supported mechanism to override this specific editor behavior.

So please explain concretely: how am I expected to adapt ODLF to work around a hard-coded disabled restriction in SP Page Builder’s own JavaScript, without modifying or patching SP Page Builder itself?

I do not modify third-party core files, and I will not introduce a workaround that depends on altering SP Page Builder’s source code. If no supported extension point exists, then “you are welcome to adapt ODLF” is not a technically actionable solution. It simply means that the third-party developer is expected to work around a deliberate restriction without being given a supported way to do so.

This is precisely the contradiction I have been pointing out: third-party integrations are described as welcome, but when a deliberate internal restriction blocks one, no supported alternative or practical adaptation path is provided.

Atick Eashrak Shuvo Staff

3 weeks ago

Hi Martin,

Thank you for the clarification. We understand the distinction you are making between general compatibility and the specific implementation change you have identified.

To put our position very clearly, the same principle applies to the relationship between Joomla and extensions developed for Joomla. If Joomla changes an API, behavior, internal implementation, or functionality and that change affects a third-party extension, it is the responsibility of the extension developer to adapt the extension to the new Joomla version. It is not the responsibility of Joomla to maintain the previous behavior specifically to ensure that every third-party extension continues to function unchanged.

The same principle applies to SP Page Builder.

If you develop a third-party component or extension that integrates with SP Page Builder, it is your responsibility as the third-party developer to keep that integration compatible with changes made to SP Page Builder. It is not SP Page Builder's responsibility to preserve its previous behavior or implementation to guarantee that your component continues to work.

This does not mean that we have any issue with ODLF or with the functionality it provides. You are welcome to continue developing your component and adapting it to the current SP Page Builder system.

The changes you are referring to were not introduced specifically because of ODLF, nor were they intended to prevent your extension from providing additional functionality. They are part of the ongoing internal development of SP Page Builder, including functionality, stability, compatibility, maintainability, and security considerations.

Regarding the current local-font implementation, we do not provide a documented extension point specifically for overriding this particular editor behavior, and we would not recommend modifying SP Page Builder's core files. If the current implementation does not expose the functionality required by a third-party integration, the integration needs to work within the functionality currently provided by SP Page Builder or be redesigned accordingly.

We also want to reiterate that SP Page Builder already provides built-in local-font functionality. The implementation used in our own Quickstart packages does not establish a guarantee that every underlying implementation detail is available as a supported third-party extension mechanism.

We appreciate your feedback and understand that you may disagree with our approach. However, our position is straightforward: SP Page Builder will continue to evolve according to the requirements of the core product, and third-party developers who build integrations with it are responsible for adapting their integrations to those changes.

Thank you for your understanding.

Atick Eashrak Shuvo Staff

3 weeks ago

One additional point regarding your comparison with Google Fonts and GDPR/privacy concerns.

The Google Fonts functionality in SP Page Builder should not be understood as SP Page Builder continuously communicating with Google whenever a visitor uses a font. The Google Fonts API can be used to retrieve the available font information and download the required font resources. Once the required font files are downloaded and stored locally by SP Page Builder, the website can serve those font files from its own server.

Google's own documentation distinguishes between the Google Fonts Developer API, which provides font metadata, and the CSS API, which can be used to request font styles and weights. When the CSS API is used directly on a website, the browser can make requests to Google's servers to retrieve the stylesheet and font resources.

This is also why the privacy/GDPR consideration depends on how Google Fonts are being served. A website that directly references Google's hosted font resources may involve requests from visitors' browsers to Google and therefore needs to consider the applicable privacy requirements. On the other hand, downloading the required fonts and subsequently serving them locally is a different implementation because the visitor's browser does not need to retrieve the font files from Google's servers.

Therefore, the existence of Google Fonts functionality in SP Page Builder should not be interpreted as SP Page Builder requiring a visitor's browser to continuously communicate with Google. The implementation can involve obtaining the font resources and serving them locally.

Martin Grunert Asked this

3 weeks ago

The Google Fonts explanation does not address the actual issue. Through the SP Page Builder Font Book, Google Fonts can apparently only be uploaded or processed as individual styles. A complete variable Google Font is not handled as a variable font.

At the same time, the screenshots show that JoomShaper uses variable-font functionality internally. This means the capability exists within the JoomShaper ecosystem, but is not made available to users or third-party integrations.

Therefore, the issue is not simply whether Google Fonts can be downloaded and stored locally. The issue is that JoomShaper internally uses broader font functionality while restricting locally hosted third-party fonts to a single weight and providing no supported way to use or integrate the same capability.

In the end, one honest sentence would have been enough:

“Yes, it is technically possible. No, we have not identified a specific security issue. We simply do not intend to make variable fonts this easily available to customers.” 😉😉

And this would not even be about third-party extensions. The SP Page Builder Font Book itself should support variable fonts as a native feature, regardless of whether a third-party extension such as ODLF is involved. The required font data is already available - the restriction is imposed by the editor behavior.

Mon Amour Massage

3 weeks ago

Hello

I notice an arrogant attitude from the SPPB developers in this thread—much like three years ago when they removed the backend editor—an attitude that says: "We removed that feature because it's our product, because we want to, and because we can."

You might have an issue with the ODLF developer, but I don't understand why you have to make things difficult for those of us who pay for and use SPPB.

We've used SPPB for many years, but it isn't the only product on the market. Just as we temporarily stopped using the product three years ago—until you abandoned that "brilliant idea" of removing the backend editor—we'll do the same now. If SPPB removes features instead of improving them, we will consider dropping the product again.

Best regards

Atick Eashrak Shuvo Staff

3 weeks ago

Hello,

Thank you for sharing your concerns. We understand that changes to an established workflow can be frustrating.

However, we cannot stop improving SP Page Builder or keep its implementation unchanged simply to ensure that every third-party extension continues to work exactly as before. SP Page Builder must continue to evolve based on its own functionality, stability, compatibility, performance, and security requirements.

We also provide official developer documentation describing the supported areas and extension points that developers can build upon. These documented extension points are the areas we maintain and aim to keep compatible as the product evolves.

The local-font editor behavior being discussed is not a documented or guaranteed extension point. We intentionally do not expose every internal functionality as a permanent extension mechanism because some internal parts of SP Page Builder may need to change over time.

Therefore, if a third-party extension depends on such internal behavior and a future SP Page Builder update changes it, it is the responsibility of the third-party developer to adapt the extension to the new system—not the responsibility of SP Page Builder to remain at a fixed point for that extension.

We have no issue with ODLF or with you providing additional functionality. You are welcome to adapt your extension to the current SP Page Builder implementation.

Our responsibility is to continue improving and maintaining SP Page Builder, while your responsibility as a third-party developer is to maintain compatibility with the platform you are extending.

Thank you for your understanding.

Mon Amour Massage

3 weeks ago

Hello.

I was speaking for myself, while you gave a lengthy account of the issues and conflicts with other developers. I'm not interested in that.

To put it briefly and to the point, I am very annoyed that you've turned off the font weight field for local fonts, given that it worked until recently in SPPB.

This makes my work more difficult, and this restriction didn't exist when I renewed my SPPB licence.
My licence expires in October, and I probably won't renew it, given that SPPB is now making my work more difficult.

Best regards

Atick Eashrak Shuvo Staff

3 weeks ago

Hello,

Thank you for sharing your feedback. We understand that the change to the local-font weight field has made your workflow more difficult, and we are sorry for the frustration this has caused.

We respect your decision regarding your SP Page Builder renewal. Our intention is not to make things unnecessarily difficult for our users, nor do we want to dismiss the impact that product changes can have on existing workflows.

At the same time, SP Page Builder needs to continue evolving, and we cannot guarantee that every previous behavior will remain unchanged indefinitely. Our development decisions are made based on the ongoing requirements of the core product, including functionality, stability, compatibility, performance, and security.

We genuinely appreciate the many years you have used SP Page Builder and the feedback you have provided. We hope that future improvements to the product will better meet your needs.

Martin Grunert Asked this

3 weeks ago

In short, this is how your responses come across: “We do it because we can.” Everything else appears to be little more than an excuse, because security concerns and functional restrictions are not relevant in this case. JoomShaper simply does not want to enable it - and that is the end of the matter.

Sad and disappointing, dear JoomShaper team.

Martin Grunert Asked this

3 weeks ago

To close this discussion:

I am genuinely disappointed and frustrated by the way this issue has been handled, especially by the repeated argumentation from Atick. Instead of answering the two simple questions - why was this restriction introduced, and how can it be adapted without modifying SP Page Builder itself? - the responses repeatedly hide behind general references to functionality, stability, compatibility, maintainability and security.

The argument that local-font handling could be a security concern is not convincing. If handling local fonts with multiple weights were inherently a security risk, JoomShaper could not safely use comparable functionality internally in its own templates and Quickstart packages. Google Fonts continue to receive the full configuration options, while locally hosted fonts are restricted, even though local hosting is generally the more privacy-friendly approach.

The contradiction is also clearly expressed in Atick’s own response:

“You are welcome to adapt your extension to the current SP Page Builder implementation.”

versus:

“The local-font editor behavior being discussed is not a documented or guaranteed extension point.”

How exactly am I supposed to adapt ODLF to a hard-coded JavaScript restriction when there is no documented extension point and I explicitly refuse to modify SP Page Builder’s core files? The technical change itself is obvious. What is deliberately prevented is changing it externally.

I have always tried to be helpful and constructive toward both the community and JoomShaper. Products improve through cooperation, not through vague explanations and one-sided responsibility statements. In this case, however, the communication has been disappointing and the reasoning provided is neither technically actionable nor convincing.

A simple explanation of why this restriction was introduced and how legitimate third-party integrations are expected to work around it has been avoided throughout the entire discussion.

That is all that can reasonably be concluded from the responses so far. For me, the matter is therefore closed - not because the explanation is satisfactory, but because JoomShaper has made it clear that it does not wish to provide a fundamental explanation.

This is also not an isolated incident. Around three years ago, there were substantial customer complaints following the removal of the SP Page Builder backend editor. Regarding EasyStore, I do not need to say anything further - the community’s complaints are already well known. For more than a month now, there have also been increasing complaints about the way security-related issues affecting JoomShaper products have been handled. And now, regarding the restriction of local-font functionality, customers and developers are again receiving general excuses instead of a clear explanation or a meaningful response.

I fully understand that no company can or must accommodate every customer request. JoomShaper is free to develop its products as it sees fit. However, the way these decisions are communicated publicly remains a serious problem for JoomShaper. Customers and developers cannot simply be confronted with vague or unsupported explanations followed by the attitude: “This is our decision - too bad for the end users.”

In the case of the local-font restriction, this is exactly what happened. Instead of providing a clear technical explanation, the discussion was repeatedly redirected toward compatibility responsibility, while the actual reason for the restriction and a practical way to adapt were never explained.

Thank you. Atick, I hope you can understand your customers’ frustration and anger. Unfortunately, I cannot make any sense of your responses, because apart from excuses and the message “we do it because we can,” nothing meaningful came out of this entire discussion.

Atick Eashrak Shuvo Staff

3 weeks ago

Hello Martin,

Thank you for sharing your concerns. I understand that you are disappointed with the way this change has affected your extension and workflow.

I don't want to continue repeating the same points or turn this into an argument. I would just like to clarify one important aspect.

SP Page Builder provides official developer documentation that defines the areas and extension points that developers can use to extend the product. These are the interfaces we can maintain and consider when making changes to the core product. The local-font weight behavior discussed here is not one of those documented extension points.

SP Page Builder must also continue to evolve. We cannot stop improving the product or preserve every previous internal behavior simply because a third-party extension currently depends on it. When the underlying product changes, it is the responsibility of the third-party extension developer to adapt their extension to the current system.

This is the same principle that applies to Joomla extensions. If Joomla changes something in its core and an extension is affected, the extension developer needs to adapt to the new Joomla version. Joomla cannot remain unchanged to guarantee that every third-party extension will continue working exactly as before.

We have nothing against ODLF, and the change was not made to target your extension or prevent you from providing additional functionality. You are welcome to continue developing it and adapt it to the current SP Page Builder implementation.

I understand that you would prefer a different product decision, and you are of course entitled to disagree with it. However, our responsibility is to continue improving and maintaining SP Page Builder, while maintaining compatibility with the documented extension mechanisms we officially provide.

Thank you for your feedback and for your contribution to the Joomshaper community.

Martin Grunert Asked this

3 weeks ago

Let’s end this discussion once and for all. All I see are excuses, and that frustrates me even more than the original problem itself. I am no longer just disappointed by the way this has been handled - I am simply angry!!!

Atick Eashrak Shuvo Staff

3 weeks ago

Hello Martin,

I would like to make one final clarification regarding the main technical claim in this discussion.

You stated that ODLF could not be adapted to the current SP Page Builder implementation without modifying or patching SP Page Builder core. We have now demonstrated that this claim is incorrect.

We have prepared an updated version of ODLF that restores the font-weight selection for ODLF fonts without modifying any SP Page Builder core PHP or JavaScript files. The solution works entirely from the ODLF side through its own integration.

The implementation and documentation are provided with the fix so you can review exactly how it works. The solution explicitly leaves the SP Page Builder core untouched.

This demonstrates an important point: when you develop a third-party extension that integrates with SP Page Builder, it is your responsibility to maintain and adapt that integration when SP Page Builder changes. It is not the responsibility of SP Page Builder to preserve its previous internal implementation so that a third-party extension continues to work unchanged.

We also want to emphasize that we genuinely respect our community members and developers. Our community is an important part of our ecosystem, and there has never been any intention from my side to disrespect you or anyone else involved in this discussion.

At the same time, SP Page Builder is our product, and our development team is responsible for deciding how its architecture and functionality should evolve. We cannot treat every internal implementation detail as a permanent extension contract.

We provide official developer documentation that clearly defines the supported areas and extension points available to developers. These are the mechanisms we maintain as part of our developer ecosystem. The internal implementation of the local-font editor is not a documented extension point.

We also cannot publicly disclose every internal technical decision, implementation detail, or development consideration behind changes to a commercial product. Some decisions are part of our internal development process and need to remain flexible as the product evolves.

Most importantly, we have no issue with ODLF or with you providing additional functionality to SP Page Builder. You are welcome to continue developing your extension and adapting it to the current and future SP Page Builder implementations.

The attached solution demonstrates that the functionality can be restored from the ODLF side without modifying SP Page Builder core. Therefore, we believe the technical question regarding whether ODLF can be adapted has now been answered.

We appreciate your contribution to the ecosystem and your feedback. We hope you will find the provided solution useful and continue developing ODLF for users who need its additional functionality.

https://files.fm/u/wezkbpwxe54uf8uk

Martin Grunert Asked this

3 weeks ago

Thank you for taking the time to investigate this and provide a working solution. I genuinely appreciate that the issue was not simply dismissed and that you demonstrated how ODLF can restore the font-weight selection without modifying SP Page Builder core files.

I will implement these changes in an ODLF 2.0.1 patch and test them thoroughly.

My criticism is mainly about the communication. A clear explanation that the local type disables the weight selector, together with this ODLF-side workaround, would have avoided much of the frustration and the two-day discussion about security, APIs and compatibility. The workaround uses SPPB’s existing variant logic, while the actual font files remain locally hosted; it does not mean that ODLF uses Google Fonts.

I fully understand that not every internal implementation detail can or must be shared with third-party developers. However, when a developer raises a concrete technical issue, it might be possible to address it privately first - especially since there was already a private forum post where this could have been discussed constructively and without the pressure of a public thread.

I also acknowledge that my tone became increasingly direct during the discussion. A private technical exchange might have allowed both sides to approach the problem differently from the beginning.

I appreciate the solution and the documentation. I hope that future changes affecting third-party integrations can be communicated more clearly, and that a direct technical exchange can be considered before a public discussion escalates.

Atick Eashrak Shuvo Staff

3 weeks ago

Hello Martin,

Thank you for your response and for taking the time to test the workaround.

I would like to clarify one important point regarding responsibility for third-party integrations.

It is the responsibility of the third-party extension developer to verify that their component continues to work with each new version of SP Page Builder and to adapt their integration when changes are introduced. From the beginning of this discussion, I have mentioned this point several times: maintaining compatibility with changes in SP Page Builder is the responsibility of the third-party developer, not something we can guarantee for every external component.

What concerned me during this discussion was that, instead of looking for an alternative approach on the ODLF side, you repeatedly stated that the functionality could not be achieved without modifying SP Page Builder's core code. As the workaround I provided demonstrates, that statement was not correct. It is possible to adapt the integration without modifying the SP Page Builder core.

I would also like to clarify that the solution I provided should not necessarily be considered the final or 100% accurate implementation for ODLF. My intention was to demonstrate that the limitation can be worked around from the third-party extension side and that modifying SP Page Builder's core code is not a requirement. You should test the approach thoroughly and determine whether it is suitable for ODLF. There may also be other, and potentially better, approaches to achieve the same result.

Regarding communication about future changes, please do not expect individual notifications or advance notice whenever an internal implementation changes in a way that may affect a third-party integration. The local-font behavior in question is not a documented developer extension point that we maintain as part of our supported API. Our official developer documentation covers the extension mechanisms that we intend to expose and maintain.

SP Page Builder is also primarily a frontend-focused product. Our responsibility is to explain changes to the user-facing design, workflow, and functionality when customers ask about them. However, we are not selling or exposing the internal source code or development architecture as part of the product. Therefore, when a question concerns why a particular internal code structure, coding approach, or implementation flow was changed, we cannot be expected to provide a detailed explanation of every internal development decision.

We respect third-party developers and the integrations they build around our products. At the same time, the underlying product needs to remain free to evolve, improve, refactor, and change its internal implementation without being required to preserve undocumented behavior solely for compatibility with external extensions.

I believe the technical workaround has now established the important point: ODLF can adapt to the current SP Page Builder behavior without modifying the SP Page Builder core. From here, the appropriate approach is to test and refine the integration on the ODLF side.

Martin Grunert Asked this

3 weeks ago

Thank you for the clarification and for providing the proof of concept. It establishes the important practical point: ODLF can restore font-weight selection for its own locally hosted font families without modifying SP Page Builder core files. I will implement, test and refine an appropriate version of this approach for the ODLF 2.0.1 patch.

I have already completed an initial risk assessment of the proposed approach. It is a workable compatibility solution, but it depends on internal SPPB editor behavior rather than a documented extension point:

Hooking Array.prototype.concat globally can be affected by future editor changes and may have unintended side effects.
Rewriting Response.prototype.json depends on the current SPPB request and state-loading flow.
Detecting the exact "Local Fonts" group is potentially version- and language-dependent.
Rewriting type from local to google is necessary for the existing SPPB variant path, but is semantically only an editor-side workaround; the font files remain locally hosted.
An inline non-deferred editor script needs to be considered carefully for installations with strict Content Security Policies.
The additional stylesheet handling requires reliable synchronization and cleanup when fonts are changed or removed.

These are manageable risks, and the workaround will be limited strictly to ODLF entries. Nevertheless, they also show why the original integration was architecturally cleaner: ODLF families could remain local throughout the entire process while still exposing their available weights.

I accept that internal implementation decisions do not have to be disclosed in detail and that not every internal behavior can be treated as a permanent public API. My criticism was primarily about the communication: explaining earlier that the local editor path is intentionally restricted and demonstrating this practical workaround would have avoided much of the frustration on both sides.

I appreciate that a solution has now been provided. I will proceed with the ODLF-side implementation and validation for version 2.0.1.

Martin Grunert Asked this

3 weeks ago

One final clarification: my original ODLF integration did not rely on a private or undocumented SP Page Builder API. It used locally generated @font-face CSS, Joomla integration mechanisms and the font data managed by SP Page Builder.

The proposed workaround is different: it deliberately adapts to internal editor behavior because the current local classification disables weight selection. That distinction matters. The workaround is now necessary because of the restriction; it was not the basis of the original integration.