How to Configure PluginCams Correctly

A reliable cam site is not created by switching on every option. PluginCams works best when imports, freshness rules, grid ordering, automatic cleanup and fallback pages are configured as one system. This guide explains how the parts fit together, with special attention to Home Grid Behavior, Mix by service (round robin) and Boost cams by views.

The correct PluginCams data flow

Think of PluginCams as five connected layers. Each layer has a different job:

1. Importers update the database. They add new models and refresh the status, viewer count, thumbnail and other available provider data for existing models.
2. The freshness filter decides which cams are eligible. The “Exclude cams older than” option hides models that have not been refreshed recently enough.
3. Home Grid Behavior orders the eligible cams. It can prioritize popular cams, mix providers, or use the normal order.
4. AutoPurger / AutoCleaner removes genuinely stale posts. This controls database growth; it should not be used as the first line of protection against offline cams.
5. JSON fallback protects removed cam URLs. It can preserve a useful landing page when an old webcam post no longer exists, but it is not a live-status system.

The order matters: import first, reject stale records second, order the remaining cams third, and clean old records later. A fallback is only the final safety net.

How many cams should you import?

More imported cams do not automatically create a better site. The useful target is a pool large enough to fill the homepage, archives, pagination and important filters while still being small enough to refresh reliably.

Every imported model can create or update a WordPress post, post meta and taxonomy relationships. A larger catalog also means longer API pagination, more database writes, heavier cleanup jobs and more data to process during imports. Full-page caching may make the frontend feel fast, but it does not reduce the work performed by the importer.

Start from the grid, not from the API maximum

A simple planning formula is:

Useful fresh pool = cams per page × pages to cover × rotation buffer

For example, a site displaying 24 cams per page and wanting five useful pages could start with:

24 × 5 × 2 = 240 fresh cams

The rotation buffer accounts for models going offline, filters and changes between imports. This is not a universal limit. A site with many country, gender or category archives will need a broader pool than a simple homepage. A multi-provider site using round robin also needs enough eligible models from each service, not only a large global total.

What happens when you import too much?

• API requests and pagination take longer to complete.
• The next cron can start before the previous import has finished.
• Providers may apply rate limits or return partial results.
• PHP processes consume more CPU, memory and execution time.
• The WordPress database accumulates more posts, metadata and taxonomy rows.
• Backups, admin queries and automatic cleanup become heavier.
• Early batches may already be aging while the final batches are still processing.
• A large part of the catalog may never be shown or visited.

Multiple categories can multiply API work

Importing the same provider through several categories can produce additional API calls and repeated processing. PluginCams may update an existing model instead of creating a duplicate post, but WordPress and the remote API still have to process that model again.

Use categories because they are important to the site, not simply as a way to multiply the total number of cams. Respect the request size, pagination and rate limits of each provider. A maximum number supported by an endpoint is not necessarily the best number for every cron run.

Let import duration determine the schedule

A new run should not begin while the previous run is still active. If importing 5,000 models takes eight minutes, scheduling that importer every five minutes is an incorrect configuration even if the first few runs appear to work.

Signs that the imported volume is too high

• Imports sometimes time out or finish with different totals.
• PHP or server load spikes at every scheduled run.
• One provider stops refreshing when several importers run together.
• Models exceed the freshness threshold before the complete cycle finishes.
• AutoCleaner repeatedly removes very large numbers of never-visited posts.
• Most imported models never reach a visible page or receive a visit.

When these signs appear, optimize the imported pool before increasing PHP memory or server resources. Import fewer pages or categories, stagger providers, lengthen the interval, and measure the complete run again.

Imports and cron jobs: keep the source data fresh

WordPress normally triggers WP-Cron when somebody visits the site. That is acceptable for testing, but it is unpredictable on a production site: a quiet period may delay imports, while a traffic spike can trigger unnecessary cron checks. A real server cron gives PluginCams a consistent schedule.

Recommended approach

1. Use the importer settings to configure each provider and verify one manual import first.
2. Run WordPress scheduled events from a real cron every five minutes.
3. If you run provider import URLs directly, stagger them instead of launching every provider in the same minute.
4. Check the importer logs after the first hour and again after a full day.

A standard URL-based WP-Cron call looks like this:

*/5 * * * * /usr/bin/curl -fsS "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1

If WP-CLI is available, running due events locally avoids an HTTP request:

*/5 * * * * cd /var/www/vhosts/example.com/httpdocs && /usr/local/bin/wp cron event run --due-now --quiet

Paths differ between servers. In Plesk, use Scheduled Tasks and the correct document root and PHP/WP-CLI path for that subscription. If your PluginCams version exposes manual importer URLs, copy the exact URL or provider key shown by the plugin rather than guessing it.

Stagger direct provider imports

Starting several large imports at exactly 00, 10, 20 and so on can cause PHP timeouts, API rate limits and short load spikes. A safer ten-minute example is:

• Provider A: minute 0, 10, 20, 30, 40 and 50.
• Provider B: minute 2, 12, 22, 32, 42 and 52.
• Provider C: minute 4, 14, 24, 34, 44 and 54.
• Cleanup: once or twice per day, outside the busy import window.

There is no universal perfect import frequency. It depends on the provider, API limits, number of categories or pages imported, and server capacity. Five to fifteen minutes is a practical starting range for many sites, but a full import must be able to finish before the next run begins.

A real setup: 200 cams from four providers

On one of my own sites, I import approximately 200 cams from each of four different providers. That gives the site a working pool of up to 800 webcam posts before normal turnover and cleanup, which is more than enough for the homepage, pagination, provider diversity and the main category archives.

The important part is that I do not launch all four imports at the same time. Each provider runs at a different minute, allowing one job to make progress or finish before the next begins.

I then use the freshness and cleanup settings as two separate protections:

• Exclude cams older than: set to around 2,400 seconds (40 minutes) in this example, so stale models leave the visible grid before they can remain at the top through an old viewer count.
• Boost cams by views: enabled only after the freshness filter, so the most popular eligible cams rise without promoting old records.
• Mix by service (round robin): rotates the four providers instead of allowing a single large network to dominate the first page.
• AutoPurger: webcam posts that have not been refreshed for one hour are removed automatically.
• JSON fallback: old webcam URLs can still produce a useful themed landing page after the original WordPress post has been purged.

This example is not a mandatory configuration for every installation. A slower provider, a larger import or a low-resource server may require wider gaps and a longer purge window. The useful lesson is the relationship between controlled volume, staggered crons, freshness filtering and regular cleanup.

Home Grid Behavior: filter first, then order

The Home Grid Behavior options affect what visitors see on the homepage. The most important option is not the sort itself; it is the freshness rule that decides whether a cam may enter the grid.

Exclude cams older than X seconds

This option temporarily hides cams whose last successful refresh is older than the configured threshold. It is reversible: if the next import sees the model online again, the post can return to the grid without being recreated.

Set the threshold from the longest normal interval between successful imports, not from the ideal cron interval. The duration of a complete import also matters, especially with large catalogs. A safe starting rule is:

Exclusion threshold = 2 × cron interval + maximum complete import duration

The table assumes relatively short imports. Add more time when a complete run takes several minutes. For example, with a ten-minute cron and a four-minute maximum import duration, a practical starting threshold is approximately 24–30 minutes. If the threshold is shorter than a normal import cycle, online models will disappear between imports. If it is much longer, offline models can remain visible.

Boost cams by views: use it only with a freshness limit

Boost cams by views (show most viewed first) is useful because popular rooms often receive more clicks. It can also expose stale data more aggressively than any other grid option.

The viewer value stored for a model is the value from its last successful update. If a popular cam goes offline and its record is not refreshed or excluded, that old high value can continue pushing it to the top. The boost is doing what it was asked to do; the eligibility rules are the part that needs correcting.

Safe sequence for enabling the boost

1. Run each importer manually and confirm that current online cams receive a fresh update time.
2. Configure the real cron and observe at least several successful cycles.
3. Enable “Exclude cams older than” using the table above as a starting point.
4. Clear the page cache, object cache and CDN cache if they contain an older grid.
5. Enable “Boost cams by views”.
6. Open several of the first results and verify that they are online and were recently updated.

If offline cams appear at the top, first check the last successful importer run and the exclusion threshold. Do not immediately blame or disable the sort. Also ensure that the page-cache lifetime is not longer than the freshness window, or purge the relevant cache after imports.

Mix by service (round robin)

Without mixing, the first page can be dominated by whichever provider supplies the largest audience or highest viewer counts. Round robin interleaves eligible cams by service, producing a sequence similar to:

Chaturbate → Stripchat → BongaCams → Chaturbate → Stripchat → BongaCams…

This is useful when you want provider diversity, more balanced affiliate exposure, or a grid that feels less repetitive. Round robin does not guarantee that every provider will occupy exactly the same number of positions. Filters, category availability and the number of fresh cams per service still matter.

How round robin interacts with other options

• With stale-cam exclusion: only recently updated models should enter the service rotation.
• With Boost cams by views: popularity can determine the best candidates inside each eligible service while round robin controls service distribution.
• With category, country, gender or sidebar filters: a service with no matching fresh cams is skipped; round robin cannot invent results.
• With a failed importer: that provider will gradually disappear when its cams cross the freshness threshold. This is safer than continuing to display stale rooms.

AutoPurger / AutoCleaner: remove old records after hiding them

The freshness option and automatic cleanup are deliberately different:

• Exclude cams older than hides a cam quickly and reversibly.
• AutoPurger / AutoCleaner permanently removes webcam posts after a longer period.

Do not set the purge age close to the import interval. Providers can have temporary API errors, maintenance windows or rate limits. A purge that runs too early creates deletion-and-reimport churn, changes stored data unnecessarily and can remove valid URLs during a short outage.

Recommended cleanup workflow

1. Configure cleanup per provider where that option is available.
2. Start with a generous grace period, then shorten it only after several reliable import cycles and a successful Dry Run.
3. Run Dry Run first and inspect the number and age of posts that would be removed.
4. Review the cleanup log for unexpected providers or unusually large batches.
5. Schedule cleanup away from active import jobs. A short purge age may justify more frequent checks, while a multi-day policy normally needs only one or two runs per day.
6. Keep a recent database backup before the first live cleanup or a major rule change.

A useful principle is: hide first, delete only when the cleanup window is proven safe. On the tightly controlled site described above, the four imports are small, staggered and monitored, so a one-hour AutoPurger window keeps the database compact. A new installation, a slower importer or an unstable provider should begin with a longer window—possibly one or more days—and reduce it only after reviewing the Dry Run and logs. Increase the purge period whenever preserving returning model URLs is more important than maintaining a very small active database.

JSON fallbacks: protection for removed and legacy URLs

JSON fallback is designed for the final stage of the lifecycle. When AutoPurger removes an old webcam post, an indexed or externally linked URL may still receive visits. If matching fallback data is available, compatible PluginCams themes can render a useful page in the theme’s design instead of leaving the visitor with an empty result.

A JSON fallback can help preserve:

• legacy webcam permalinks and search-engine landing pages;
• basic model or provider context when the WordPress post is gone;
• a route toward current live cams and properly configured affiliate links.

It should not be treated as proof that a model is currently live, a replacement for provider imports, or a source for the live homepage grid. Keep affiliate IDs and provider settings correct, make sure the fallback data is refreshing, and test an intentionally old URL after cleanup.

Recommended configuration profiles

Balanced multi-provider site

• Import providers every 5–15 minutes and stagger their start times.
• Exclude cams after roughly 2–3 successful import intervals.
• Enable Mix by service (round robin).
• Enable Boost cams by views only after freshness is verified.
• Run cleanup daily with a grace period measured in days.
• Keep JSON fallback enabled for old webcam URLs.

Popularity-first site

• Use frequent, reliable imports.
• Use a strict but realistic stale-cam threshold.
• Enable Boost cams by views.
• Disable round robin if pure global popularity is more important than provider balance.
• Keep cache lifetimes short enough for the grid to reflect the latest import.

Low-resource server

• Import fewer pages or categories per run where appropriate.
• Use a 10–15 minute schedule instead of overlapping five-minute jobs.
• Stagger every provider and confirm one run finishes before the next begins.
• Increase the exclusion threshold to match the slower schedule.
• Run cleanup during the quietest period of the day.

Quick troubleshooting

Final checklist

• Every provider completes a manual import successfully.
• A real server cron runs consistently and provider jobs do not overlap.
• The freshness threshold is based on the real import interval.
• Boost cams by views is never used without stale-cam protection.
• Round robin is enabled when provider diversity is a goal.
• AutoPurger / AutoCleaner uses Dry Run, logs and a generous grace period.
• JSON fallback is tested on an old URL and is not mistaken for live status.
• WordPress, object and CDN cache lifetimes are compatible with the import schedule.

Once these layers are synchronized, PluginCams can keep a large cam grid fresh, diverse and useful without pushing stale offline models to the most valuable positions.

For option-specific help, visit the PluginCams documentation or contact support.