Search

I think I've got the basis in place of a multi-site installation where the sites are entry-based ("Versions" section) instead of the page-based ninja domains method. This suits this project as the different versions of the site will share the same basic structure, meaning each page will be served to multiple site versions, but their content will be filtered on the root parameter where necessary to provide the differences between the sites.

It is possible, though, that some sites will need to disable certain pages. So my question is: what field combination or method in the Symphony admin area can I use to enable an author/developer to disable pages per site?

I've created a section called 'Page deactivations' with these fields:

  • Version (Select Box Link)
  • Page (Page Select Box)

This does match up site versions with pages, so I could use the output from that to conditionally show page content and navigation links as necessary in the XSLT, but it doesn't make for a very intuitive interface for the client (or me).

Ideally, there would be a list showing all sites with all pages, where each page had a checkbox.

Site version A
- Page 1 (x)
- Page 2 ( )

Site version B
- Page 1 ( )
- Page 2 ( )

Or perhaps the Symphony Page page could have a list of site versions (from the Versions section) with checkboxes added to it somehow.

Any thoughts on possible approaches welcome. Thanks.

Why not simply add the site version to a page via the page type field and filter it on a datasource level? A hidden helper section could map the root-parameter to a shorter version handle.

Just out of curiosity, are all site-"versions" owned and managed by the same client? Or how did you set it up so a client doesn't have access to all the entries that belong to other versions/clients?

The answer to the original question, as well as @jensscherbl's, is rather complex. You bet that Symphony provides a lot of ways to do it.

I have built a web app which is generating hundreds of websites. There are client types (mapped to site structures), and every client can switch pages on and off. There is a very generic content model, which needs only a few "special sections" for the biggest websites. However, I won't explain my solution here, since it relies on too many details.

But that is not my point anyway. If you intend to build something like this, try and build extensions. Learn to love Symphony's delegates. Go back to the drawing board. What happens when Symphony creates a page? How can you influence this process by redirecting, setting params, injecting events, event filters, datasources, manipulating data etc.? In my web app there is one central extension which accompanies the process of page creation — do it differently, if you like, but you won't do it without understanding the frontend page creation process. Try and find a concept as generic as possible, then "hack" Symphony using extensions.

@ jensscherbl is right: If you start somethig like this, you should know that you will also need some sort of access control layer. Different websites should only be able to create/edit/delete parts of the content. That is the hardest part. You can either try this in the backend (which is very much work) or you can try to establish a publishing frontend (which is very much work as well).

(The amount of code is not the problem, it's still maintainable in my case. But it will be hard to get it right.)

Thanks, Jens.

Why not simply add the site version to a page via the page type field and filter it on a datasource level? A hidden helper section could map the root-parameter to a shorter version handle.

If I understand correctly, your suggestion would look like something like this?

Page deactivations

This section was what I'd created earlier, but I didn't think of making the 'Deactivated pages' page selection field allow selection of multiple options before I'd read your reply for some reason.

So the section would contain only one entry per site, which is quite manageable.

Just out of curiosity, are all site-"versions" owned and managed by the same client? Or how did you set it up so a client doesn't have access to all the entries that belong to other versions/clients?

Yes, they're all for the same client, so no special access control required.

Michael, thanks for the pointers and advice on approach. I'd definitely like to get into understanding Symphony's mechanics and page creation more.

I've a feeling that for this particular project, which is relatively simple as all sites are for the same client, I can get by with simply associating pages to sites via a section. But for a web app idea I have, which would serve lots of different customers (hopefully), I'll need to dig deeper.

as all sites are for the same client

Well, that might indeed reduce complexity a lot!

:-)

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