Screenly Cast

Use ?srly when the URL has no other parameters:

• https://www.mydomain.com/some-page?srly

• https://www.mydomain.com/?somevar=1&anothervar=2&srly

From their request: the X-Screenly-* metadata headers a Screenly player can send, the Android package name several other players identify themselves with, and user agent tokens that name a player and nothing else: Screenly, Anthias, BrightSign, IAdea, Slideshow and Unifi Connect. Detection is deliberately cautious, because the two kinds of mistake are not equally bad. A player it misses still works if you add ?srly. A device it wrongly claims would show a signage render to somebody who was just browsing, with no explanation and no way back. So a signal has to name a player and nothing else. Notably absent: LG webOS and Samsung Tizen, which run signage displays and every LG and Samsung smart TV, and QtWebEngine, which signage players embed and so does any desktop Qt application. Search engines, signed-in users and meeting-room devices are excluded too: a room calendar is not signage. A detected player is sent to the same URL with ?srly added rather than being shown signage on the original URL, so that a page cache or CDN never has to serve two different pages for one URL. Only the redirect itself is uncacheable. Turn it off under Settings → Screenly Cast if you would rather add ?srly yourself, or use the screenly_cast_is_signage_player filter to widen or narrow which requests count.

No. A signage request renders through the plugin's own template for that one request. Your active theme, and what every other visitor sees, is unaffected. Versions up to 1.0.5 did switch the site's theme, and could leave a site stuck on the bundled Screenly Cast theme. On upgrade this plugin detects that, switches your original theme back, and tells you it has done so.

Assume a couple of hundred characters will be comfortably read at a distance. Longer content is trimmed to what fits rather than overflowing or scrolling. If you need a different limit, filter it: add_filter( 'screenly_cast_character_budget', fn() => 900 );

Yes, via the screenly_cast_allowed_tags filter. The default set is small on purpose, and links are reduced to their text because there is nothing to click on a screen.

The featured image if the post has one. Failing that, the first image in the post content that comes from your media library, so adding a picture with the "Add Media" button is enough, and you do not have to set a featured image as well. Images hotlinked from other sites are ignored. On an image's own media URL, that image is the subject of the render.

Yes: add_filter( 'screenly_cast_show_date', '__return_false' ); The line above the title then shows your site name instead, so the render still says where it came from.

The design is built on CSS custom properties, so overriding a handful of them is usually enough. Add your own stylesheet after ours by attaching it to the screenly-cast handle: add_action( 'wp_enqueue_scripts', function () { wp_add_inline_style( 'screenly-cast', ':root{--color-ground:#101820;}' ); }, 100 ); The tokens worth knowing are --color-ground, --color-ink, --color-ink-soft, --color-ink-dim and --color-brand, plus --root-min, --root-gain and --root-max, which together drive the whole type scale. Over a photograph there are two more: --srly-ground-deep-rgb, the scrim color written as R G B channels, and --srly-text-shadow.

Since WordPress 6.4, attachment pages are disabled by default and redirect to the image file itself. This plugin keeps them renderable for signage requests only, so casting a media URL still works without re-enabling attachment pages for ordinary visitors.

No, by design. On a large, non-interactive display, fixed unmoving content reads better than anything that moves.