We've recently been having issues with a particularly large design file with many customisations. This was built following the advice from the Matrix 330 designs course: "try to only make 1 Design per site and use customisations for the different sections/page types".
However, the responses from Squiz support have pointed at a forum post http://forums.squizsuite.net/index.php?showtopic=8617, which advises keeping the number of customisations for a given design under 100. The design we're having problems with has only 32 customisations.
It's really frustrating that different, conflicting, advice is being given through different channels, all from Squiz.
Could someone from Squiz please work out a set of guidelines for this, and put them in the manuals site as a single point of reference to minimise this confusion - in the above post, Scott Hall mentions that it's been asked lots of times, which suggests that a reference would be very useful to lots of people, even if it is presented as a range of options for speed/convenience of editing/ease of use.
As far as I can tell:
1 design file per page, very fast, nightmare to work with
[*]1 design file per section, based on appearance, fairly fast, structural changes need applying in multiple places
[*]1 design file per site with direct customisations, slow, structural changes easy, initial set up of new sections a pain
[*]1 design file per site with nested customisations, slow, structural changes easy, initial set up of new sections trivial
In this case, we're getting PHP timeouts from attempting to make changes to higher level customisations, and have been told that this is down to too many customisations on the design.
We're running off a similar level of hardware to that - a pair of 4Gb servers which are mirrored. We know there are a couple of configuration issues with the setup, which are being looked at, but given that the advice on the forums from 2008 says less than 100 should be fine, the 30 or so we're using shouldn't be an issue even on relatively slow hardware.
[quote]
but given that the advice on the forums from 2008 says less than 100 should be fine, the 30 or so we're using shouldn't be an issue even on relatively slow hardware.
[/quote]
I think it is still good advice to create the fewest number of customizations as possible, but this advice from 2008 isn't entirely correct. In more recent version of Matrix (I think maybe started in 4.6.0?) saving the design or customizations will start up a hipo job which will run through all of the processing needed. Previously it didn't do this, and we too ran into PHP timeout issues because it was taking about 120 seconds to process our design.
[quote]
When you say slow, what are you basing this on? I would think this really comes down to the speed of your hardware.[/quote]
I'm not touching that with a 40ft pole!
[quote]We have about 60 customizations and it is fast. We are running on our internal cloud with only 4 gigs of RAM.[/quote]
The design Matthew alludes to is our standard "inner" page; we're an educational institution with many colleges, schools, etc.
So we have one design, then a master customisation of that, and then 30+ customisations of the master customisation. These 30ish might simply be adding some bespoke CSS, a widget, some Javascript. So often these customisations actually only customise a handful of things (although some are far more complex). Also some of these customisations have further customisations, often with just one or two changes (a CSS class, or Google Analytics for example).
As he states, we're only doing exactly what we were told to do in training from Squiz, and sadly that's now causing us some issues.
Sorry to butt-in to your post Matthew but I need to strongly voice support here B)
[quote]
The design Matthew alludes to is our standard "inner" page; we're an educational institution with many colleges, schools, etc.
So we have one design, then a master customisation of that, and then 30+ customisations of the master customisation. These 30ish might simply be adding some bespoke CSS, a widget, some Javascript. So often these customisations actually only customise a handful of things (although some are far more complex). Also some of these customisations have further customisations, often with just one or two changes (a CSS class, or Google Analytics for example).
[/quote]
We are very similar here. We are also an educational institution and have a similar customization setup as the one you described.
We're on 4.8.3, which is fairly recent. I would have thought that a HIPO job would have been immune from the timeouts, so I was quite surprised when we were getting them for some changes to customisations or parse files.
[quote]
We're on 4.8.3, which is fairly recent. I would have thought that a HIPO job would have been immune from the timeouts, so I was quite surprised when we were getting them for some changes to customisations or parse files.
[/quote]
Hmm, that is very strange. I know that it fixed the issue for us. Do you ever see the hipo run when saving a parse file?
[quote]
Could someone from Squiz please work out a set of guidelines for this, and put them in the manuals site as a single point of reference to minimise this confusion - in the above post, Scott Hall mentions that it's been asked lots of times, which suggests that a reference would be very useful to lots of people, even if it is presented as a range of options for speed/convenience of editing/ease of use.
[/quote]
I can understand your frustration, but only ballpark estimates of the number of design customisations can ever really be given. The reason for this is because there is no actual limit on the number of customisations defined by a system and this is mainly down to the following factors:
Configuration of the hardware (or virtual machine) the system is hosted on (database, speed, memory etc)
[*]Complexity of the design (The number of design areas and the relative complexity of each design area)
[*]The number of customisations
[*]The number of design areas that have been customised
There may be other factors that a Squiz developer can chime in with, but those are the variables I'm familiar with. With so many variables you can't come up with a magic number that will fit every system, but even still not being able to hammer out a guess at a number is going to make the process trial and error. If a certain approach doesn't work you have the option of trying something else.
What really needs to happen here is to figure out the [i]exact[/i] reason your design is timing out. Is it the choice of design areas? Database needs tuning? Can the 'customisation' be performed by a different method other than design customisations? Could certain parts be replaced with less process intensive design areas, or do you need to make the tougher decision to split your design into multiple parse files? The latter decision hasn't happened on Matrix systems for some time now, at least not with the systems I'm familiar with. One parse file per 'site' is the usual choice (even for reasonably complex sites). It works for many and I'd guess that is the reason for the advice offered in the 330 design course.
We've implemented incredibly complex designs before with a myriad of variations of different page layouts and not all of it uses a design area and associated customisations. In some cases single page, section or sub-site customisations that do things like add extra javascripts, customised CSS variants, or additional content have been done using alternatives like metadata, paint layouts, listing link values, etc. One of the great things about Matrix is that it is a swiss army knife where you can choose from a bunch of different tools for the job, unfortunately it's not always obvious which tool to pick, how to use it, or even which way it is best used. Some of the really tricky stuff with a product this modular comes down to experience.
Misconfigured server, for example PHP settings are too low, when the hardware can handle a modest (or big) increase.
[*]Recursive customisation in the design. The easiest way to check this is by checking the Dependants screen of the design. The dependants screen should be a very quick displaying screen, but if there is a recursion somewhere it will slow the screen down.
