Search

Hey David, I've been thinking about this issue for a while but I haven't found time to implement anything yet.

I'm a bit busy these days because of exams, but if your problem is not urgent I think I could carve out some time this weekend to update the README and, perhaps, implement a new custom delegate (which seems to be the cheapest/quickest solution at the moment).

Perhaps you can manually try this temporary fix (SSM 2).

@Simone thanks. That would be great. It's not very urgent.

@Vlad Thanks. I'm not exactly sure what this does: will this allow the SSM assets to load? If so it looks like an easy quick-fix. Thanks.

will this allow the SSM assets to load?

Yeap. You're welcome.

[...] implement a new custom delegate (which seems to be the cheapest/quickest solution at the moment).

Unfortunately I was wrong: a custom delegate is just not enough to solve the problem. Because of the way Subsection Manager 2 works, it's impossible to load its fields outside of the "publish" area without patching the core or the extension itself (as Vlad suggested).

In plain words, SSM2 checks for the correct context inside buildPublishPanel which is the method responsible for showing a field in a Symphony backend page. There are no other ways to display a field in the backend, so Custom Preferences relies on the same method for its own pages as well.

Almost every page in the backend has its own "context" (that is, a string) and SSM only works if that string is publish, which is not the case for Custom Preferences pages. Since the context cannot be modified and is automatically built by looking at the page URL, it's impossible to load SSM in a place which is not the publish area.

A custom delegate would work if context checks were placed outside buildPublishPanel, which is the case for some fields (e.g. Subsection Manager 1.x) but not for others (e.g. Subsection Manager 2).

My suggestion is to stick with Vlad's patch until a new core-level system for loading extension assets is devised (and needed by other extensions). In the meantime, I'll talk to Nils to see what can be done SSM-wise.

Cool, thanks for the update Simone.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details