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.

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.

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.

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.

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.

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? 😉

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.

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.

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.

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.

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

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.

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.

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.

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.