Gallery Rotation
There are several methods for gallery rotation in the system.
Spin%.
Clickperiods
HoldPeriod.
The first thing to be aware of is that rotation requires a LOT of galleries.
For example the standard set up will inject 1 gallery every 10 minutes, that means 144 galleries per day. If your template is trying to display just 3 days and a hall of fame, then you will need at least 4 days worth of galleries. IE 144 x 4 = 576 galleries. This is still not enough though, as you'll see below.. We say the minimum for good operation is 2000 galleries, and that's why we try to ship 2000 starter galleries for you.
The system maintains a quantity of galleries in an a 'ready to be listed', available pool. Once a gallery has been used, it goes into a used state, where it cant be pulled into the site again as a new gallery, until one of the release events happens (see below). The gallery will stay in this used state, and while in this state will age daily, enabling it to be listed in archives, daily sections and hall of fame, etc.
Once the time is up for a gallery and rotation kicks in due to a release event, the gallery has it's counters reset to 0, so it is removed from the galleries that can be listed on the site. It will fall off the hall of fame, archives and daily sections.
Spin% is the preferred method for gallery rotation, and is set within the [Categories] control section, it allows you to rotate on a per category basis.
Spin% allows you to set a % of your category to be held after it has been listed on your site. Once the used galleries within the category reaches the percentage equal to spin% of your total approved galleries, then the eldest galleries will be released to the available pool. This is the first type of release event.
Thus with a spin of 75%, if a category had 100 galleries in it, once it pulls in the 76th new gallery from this category, it will release the first gallery to the available pool for reuse.
The advantage to spin% is that it is less sensitive to the growth of your database, and allows your site to function and rotate, no matter how many galleries are in the system.
Clickperiods is also a setting found within [Categories] and allows rotation on a per category basis. This value will reset the counters on a gallery as soon as it the gallery hits the clickperiod specified. If you are running on a 10 minute build, you will have 144 click periods per day. So if you set your clickperiods to 200 your galleries will not age more than 2 days before having it's counters zapped and being released to the available pool again. This is the 2nd type of release event.
Holdperiods is found within the [Settings] page, this is like clickperiods but it applies to the entire database and it is applied on a per day basis. So instead of tracking the clickperiods registers, it tracks the daily age instead. This is the 3rd type of release event.
The rotation system runs on a first come, first served basis. Which means if a spin% release event happens before a holdperiod release event, then the spin% will take priority. And if a hold period release event happens before a spin% release event, then it will take priority.
TROUBLESHOOTING:
The most common problem associated with rotation, is where galleries are rotating too often.
The most common cause of rotating too fast is due to pulling too many galleries on a per build basis.
There are several reasons for pulling too many galleries..
Too many pages that are pulling new galleries.
Too many macros on the page that are set to pull new galleries.
Errors on the page.
Errors on the page can pull extra galleries and if the replacement rules are set to pull new, will choose alternate galleries in the event that there are shortages, and in this case in the event of errors the script can rapidly deplete galleries.
Too many pages pulling new galleries, this is common where the user creates extra pages and leaves the original example pages in place, this can cause extra gals to be pulled both for the new page you've created and the old page.
Too many macros on the page that are set to pull new galleries.
Standard macros when used with a {{allowdupes}} macro will pull new galleries. IE: {{all-thumb-1}} will pull new galleries.
Macros using the system standard, age0 or new queries, or with a setting that asks for periodsshown>-1 are macros that will pull new galleries.
Normally a gallery will pull new galleries only once per day (no matter how many builds you schedule throughout the day), but if the {{allowdupes}} macro is present it will pull new galleries on each and every build throughout the day, for each of the pages that it is listed on.
|
More on Gallery Rotation and manipulation.
There are basically 3 states for galleries.. 1. Disapproved / Pending / Waiting / Blacklisted (cant be displayed) 2. Approved and in the ready to be listed pool.. 3. Approved and listed already (galleries on site or archives) Galleries get imported and wait in a pending status until approved, once approved, they wait in an approved state in a 'ready to be listed pool of galleries', they stay here until they get released to the site and will stay in this status until reset as part of rotation (unless you disable rotation). Rotation can be triggered by spin% or the clickperiods setting inside [Categories], or it can be triggered by the holdperiod setting on the [Settings]pages. We dont recommend using holdperiod unless you have specific needs, as spin% will grow with us and is more dynamic. When listing new galleries, Comus pulls new galleries from the avail pool of ready galleries. Spin% Rotation works by ... Holding the used galleries on the site until the spin % of galleries for that category have been used. spin% is a percentage of the total galleries for that category. For example if you have 200 galleries and a spin% of 75 then comus will not rotate any galleries until 150 galleries hav been used. Once comus has reached the spin% quota, it will release the eldest galleries for re-use, (in future versions I might add the option to release the gallery based upon a custom rule, so you can rotate by CTR or some other set of variables.). More info on the 3 states of galleries..and some variables you can use in your queries. 1. Disapproved / Pending / Waiting / Blacklisted (cant be displayed) Will have accept='Pending' probably will have 2. Approved and in the ready to be listed pool.. with thumbs (needed to show a thumb link) with descriptions (needed to show a text link) These galleries will be in the database with periodsshown=0 Hence we can pull them in our macros via the 'periodsshown>-1' 3. Approved and listed already (galleries on site or archives) A few variables we can identify these galleries by... periodsshown will always be >0 for these galleries. periodsshown will increase by 1 for each day on site. clickperiods will always be >0 for these galleries and will increase by +1 for each build that occurs. If you build at 10 minute intervals then clickperiods will increase at 144 points per day. onpage will always be >0 for these galleries and will increase by +1 for each build that occurs, but ONLY if the gallery is actually used on a page. Once it falls off site.. the counter will freeze. onsite = 1 if the gallery was just used and is actually on the site. used is a counter for how many times a gallery has been released for use on the site as a 'new' gallery. It will always be >0 for new galleries, and will not reset after rotation actually occurs. You can use this variable to determine how many times a gallery has been rotated. clicks is the total clicks since this gallery was released as new. totalclicks is the total clicks for this gallery even across rotations. When galleries are rotated they have a number of their variables zapped to 0, which will remove the gallery from the pages and return the gallery to the ready to be listed pool. These fields in the database are all set to 0.... periodsshown,clickperiods, onsite,onpage all = 0 The fields, totalclicks and used are NOT set to 0 when galleries are rotated. |
||
|
I have one big hall of fame and one thumb per 10 munutes is adding. 7 the newtest thumb are placed in stage1. The problem is that if no new galleries (I didn't aproved it before) poll stage1 is static. I would like to reuse older galleries.
Now I have 1028 galleries aproved (used with thumbs) and 907 approved but without thumb (no used). My template is using only galleries with thumb. Spin for this category is 75%. My layout has 175 thumbs My template
I will be huppy for help. If this is not the cause..
Bad Queries that can stop gallery rotation then... -The most common cause for rotation problems is a spin% setting that holds galleries from being released again in combination with other factors which are stopping galleries from being used in the first place. -Lots of NON THUMBEd and APPROVED galleries can cause release of new galleries to stop where you are specofically requesting thumbs. The problem is caused where you might have > 50% of your galleries without thumbs, > Macros which only ever request galleries WITH thumbs. > A spin% setting that requires more than 50% of the galleries to be used, (IE: standard is 75%) In this case the rotation event never happens, the site uses the galleries until they are all used up, and then stops pulling new gals totally. SOLUTION: Move non thumbed to pending, thumb them or start using text links macros that pull new thumbs. -Activation of the Explicit controls, can withhold galleries. This tells the script not to list explicit galleries, just like the non thumbed problem the same thing can happen. > 50% of your galleries might be explicit > Macros and rules only ever request NON EXPLICIT thumbs > spin% setting might require that 75% of the galleries be used before triggering a rotation event. The event never happens. SOLUTION: lower spin% so that rotation can happen, but work out first how much of the database is non explicit. -Scheduling too many galleries can stop rotation, for example if you scheduled 3000 galleries to be released 1 month from now and had only 100 unscheduled galleries, the 100 galleries would freeze up until the month was up, and only then would the others start to come out. This problem can happen when.. > 50% of your galleries are scheduled for release in the future > spin% setting might require that 75% of the galleries be used before triggering a rotation event. > The builder uses up ALL NON SCHEDULED galleries. It is now dead in the water, until the scheduler releases more galleries. SOLUTION: Reschedule, or add more galleries. -Removing the macros that allow pages to build, can freeze the script. {{buildonce}} forces one build per day .. this can mess up a page which is expected to activate more frequently such as a page using {{allowdupes}} or {{prodbooster}}. The {{buildonce}} is an abort command for the builder and means, build the page once per day, regardless of what else is on the page. {{archivepage}} Adding this macro strips all build commands, tracking, footers and comus extras, so that you can make pages that are includable into other documents. The problem comes when you do this to ALL pages, it disables the builder from activating. {{manual}} this forces a page to only ever build from inside Comus admin at your command, it will never build automatically. |
||