CodeCanyon Luna Web Radio Player - WordPress Plugin

Guide to Setting Up and Using CodeCanyon Luna Web Radio Player

CodeCanyon Luna Web Radio Player is not just about adding a play button. In real website work, what matters more is connecting the stream correctly, choosing the right metadata method, avoiding playback failures caused by HTTPS, CORS, or mobile restrictions, matching the player to your site design, and making sure listeners see a clear, usable result.

This guide walks through a practical WordPress setup: preparing the stream, installing the plugin, generating and manually editing the shortcode, choosing the right mode for Shoutcast, Icecast, Radiojar, Radio.co, or HLS, configuring cover art, the visualizer, colors, mobile behavior, and troubleshooting common issues. This is not a reworded product listing. It is a working guide for a webmaster, online radio owner, or developer who is already preparing a page for a live audio stream.

Some settings depend not on WordPress, but on the streaming server. That is why this guide clearly separates what the plugin controls in the player output from problems that usually come from the stream URL, metadata, CORS policy, mixed HTTP/HTTPS content, or browser settings.

What This Plugin Solves on an Online Radio Website

The main purpose of CodeCanyon Luna Web Radio Player is to place a live radio stream on a WordPress page so visitors do not have to leave your site for a third-party player or open the stream through a separate link. The plugin accepts parameters through a shortcode and builds an HTML5 player with controls, station name, current track, cover art, a visualizer, and custom styling.

That is especially useful when your station already broadcasts through Shoutcast, Icecast, Radiojar, Radio.co, HLS, or another compatible server, and your website needs to become a clear entry point for listeners. A visitor opens the page, presses play, and stays on your site. Meanwhile, the content manager can place the player inside a post, page, widget area, or page builder block, as long as the chosen editor saves the shortcode correctly.

One of Luna Web Radio Player's strengths is that it does not stop at a bare stream URL. The developer documentation lists a wide range of parameters: dimensions, rounded corners, colors, font, station name, offline text, scrolling station and track names, cover art, visualizer mode, metadata method, volume, local storage of user preferences, live icon display, and the visualizer button. That flexibility is useful, but it also demands careful setup: one incorrect parameter can leave you with working audio but no track title updates, or a player that looks great on desktop but feels awkward inside a narrow layout block.

A key point for the first launch: first make sure a simple stream plays reliably without a complex visualizer or custom cover images. Only after that should you add styling, metadata modes, automatic track updates, and additional player instances.

Who Luna Web Radio Player Is For, and When Another Approach Makes More Sense

This plugin is a strong fit for websites where the primary use case is live online broadcasting rather than a library of uploaded audio files. That could be a radio station page, a DJ website, a music project, an educational media site with a live broadcast, a local station, an event page with a temporary stream, or a promotional broadcast landing page.

When It Is a Good Fit

Luna Web Radio Player is worth considering if you already have a working streaming server and understand what type of stream you are using. It is especially useful in the following situations:

• You need a compact or large HTML5 player for a live stream, not a standard list of MP3 files.
• You want to display artist - title when the server provides metadata in a supported format.
• You need control over colors, fonts, dimensions, cover art, and visual behavior so the player matches your site design.
• You plan to use multiple players across different pages or blocks, with each one having its own stream and styling.
• You need support for Shoutcast, Icecast, Radiojar, Radio.co, HLS, or a custom metadata source through a plain text URL.

When the Plugin May Be More Than You Need

If your goal is simply to play one standard MP3 file, the built-in WordPress audio block or a simple audio player will often be easier. If you need a full radio website with show schedules, host profiles, archives, and separate broadcast pages, a player plugin alone will not be enough. You will need a dedicated scheduling system or a broader broadcasting plugin.

You should also evaluate how important uninterrupted playback is when users move between pages. In the developer FAQ, it is clearly stated that the radio can keep playing during navigation only if the site uses AJAX and the player area is not reloaded. On a standard WordPress site, moving to a new page usually reloads the entire document, which means the stream stops.

If what you need is a truly continuous sitewide player, check your theme and navigation architecture first. Luna Web Radio Player can be placed in a persistent area, but by itself it does not turn a standard WordPress site into a single-page app.

What to Check Before Installation and Your First Shortcode

The most common mistake in setting up a radio player is starting with the design. A visually polished block will not help if the browser cannot access the stream, the server does not provide metadata, or your page runs over HTTPS while the stream is still on HTTP. Before installation, it is better to put together a short technical profile of the station.

Minimum Stream Details

Prepare not just a link you can open in a browser, but also the type of streaming server. For Shoutcast and Icecast, the URL often needs to be split into a base address, mountpoint, path, or stream ID. In the Luna Web Radio Player documentation for Shoutcast, streamurl is shown without the path, while the path and ID are passed separately through shoutcastpath and shoutcastid. For Icecast, icecastmountpoint is just as important.

Check the following:

• The stream opens directly and actually plays in a browser or an external audio player.
• You know the server type: shoutcast2, icecast2, radiojar, radioco, hls, or other.
• For Shoutcast, you know the required shoutcastpath and shoutcastid, if your server uses them.
• For Icecast, you know the mountpoint that should go into icecastmountpoint.
• If the site runs over HTTPS, the stream must also be available over HTTPS or through another securely configured option.
• If you need the real visualizer or direct metadata reading, the stream must allow CORS requests from your website domain.

Domain and Token

The official documentation states that after activation, you need to obtain a token for the site and include it in the shortcode. In the FAQ, the developer also specifically asks users to verify the domain carefully, including the subdomain and whether it uses www or not. This article does not need to cover the commercial access process in detail, but for troubleshooting it is important to understand one thing: if the player does not work on a new domain or test subdomain, the issue may not be WordPress at all, but a mismatch with the domain for which the token was created.

Use a Test Page Instead of Editing the Live Homepage

Create a private or non-public test page and insert a short working shortcode there first. That lets you check audio playback, metadata, mobile behavior, and cache conflicts without risking your main page. If the site uses aggressive JavaScript optimization, delayed script loading, or file merging, temporarily disable those features for the test page and turn them back on one by one.

Installing in WordPress and Running the First Check

The official documentation describes two standard installation methods: using the regular WordPress plugin installer or copying the archive contents into /wp-content/plugins. For most users, the WordPress admin method is safer because it makes it easier to catch installation errors, activate the plugin, and return to the extensions list.

Basic Setup Flow

1. Open Plugins in the WordPress admin area and upload the plugin ZIP file using the standard WordPress installer.
2. Activate the plugin through Activate.
3. Prepare the token for the domain where the player will run.
4. Build the shortcode using the developer's generator or manually from the documentation.
5. Paste the shortcode into the test page and save it.
6. Open the page in a private browser window and confirm that the player appears without errors.

On the first run, do not enable every feature at once. It is better to use the minimum parameter set: width, height, token, station name, stream URL, stream type, and basic volume. If that works, future changes become much easier to diagnose because you will know exactly which parameter caused the failure.

Short Starter Shortcode

The snippet below is not a universal ready-made code block for every station. It is a safe starting framework. Replace mytoken, My Radio Name, https://stream.example.com, and the stream parameters with your own values. Interface items and parameter names are left exactly as they appear in the documentation so they are easy to compare.

[lunaradio
  width='100%'
  height='70px'
  token='mytoken'
  userinterface='small'
  radioname='My Radio Name'
  streamurl='https://stream.example.com'
  streamtype='shoutcast2'
  shoutcastpath='/live'
  shoutcastid='1'
  volume='80'
  autoplay='false'
  debug='false'
]

After saving the page, check three things: whether the player itself is visible, whether the stream starts after a click, and whether the interface changes state. You can test metadata and cover art later, because they depend on a separate data-reading mechanism.

Configuring the Shortcode: Size, Interface, Colors, and Behavior

In Luna Web Radio Player, nearly all configuration happens through shortcode parameters. That makes it easy to move between pages, but it also requires discipline. The longer the shortcode gets, the higher the chance of a typo. It is best to keep one proven reference version in your project notes and use verified copies on actual pages.

Dimensions and Interface Type

The width and height parameters control the player size. For a standard in-content block, 100% width usually makes the most sense because the player adjusts to the theme column. Choose the height based on the interface mode. userinterface='small' works well for a compact strip, while userinterface='big' makes more sense for a station page with cover art and a visualizer.

How to Choose the Height Without Breaking the Layout

If height is set in percentages, remember the core CSS rule: percentage height is calculated from the parent container's height. In the FAQ and documentation, the developer specifically explains that for a fullsize layout you need to define height for all parent elements or use an appropriate option such as 100vh. If you do not, a large player may take up much less space than expected or fail to show the intended height.

Colors, Fonts, and Readability

To match the player with your site design, backgroundcolor, fontcolor, and hightlightcolor matter most. Do not choose them by taste alone. Check contrast first: the station name, artist - title, and control buttons must remain readable against the actual theme background. If the site uses a dark design, a bright accent can help the play button stand out, but an overly neon palette will start fighting the rest of the interface very quickly.

The fontname and googlefont parameters should be used carefully. If the site already loads a branded font, it is often better to leave that field empty and inherit the theme font. Loading an extra font just for one player may not be worth it, especially on a page where first-render speed matters.

Scrolling Station and Track Names

The scroll, scrollradioname, scrolltitle, scrollradionamespeed, and scrolltitlespeed parameters help when names are too long to fit inside a small interface. But marquee-style scrolling should not become annoying. For a compact bar, use a slower speed and make sure the text does not jitter when metadata updates.

Cover Art and What Happens When No Cover Is Available

coverimage can be used as a fallback station image. That is useful when the stream does not always provide data the plugin can use to fetch track artwork. You should enable onlycoverimage only when you intentionally want to always show the station logo instead of track covers. Otherwise, you lose some of the visual variety that makes this kind of player appealing in the first place.

Autoplay and Local Preference Storage

The autoplay parameter is usually best left off by default. Modern browsers restrict automatic media playback without user interaction, and behavior can vary on mobile devices. If you enable autoplay='true', treat it as a best-effort attempt, not a guarantee. In user-facing guidance, it is better to explain that audio should start after the user clicks play.

uselocalstorage saves user preferences such as volume and the selected visualizer. That is convenient for returning listeners, but it can also interfere with testing: you change volume in the shortcode, while the browser keeps using an older value from local storage. During troubleshooting, use a private window or clear site data.

Streams and Metadata: Why Audio Plays but the Track Title Does Not Appear

For a radio player, playback and metadata are two separate jobs. The stream may play while artist - title never appears. Or the metadata URL may be available while the audio stream itself is blocked by the browser because of HTTPS or CORS. That is why in Luna Web Radio Player it is important to choose both streamtype and metadatatechnic correctly.

Shoutcast 2

For Shoutcast 2, the documentation recommends setting streamurl without the path and moving the path and stream ID into shoutcastpath and shoutcastid. By default, the player expects metadata through an endpoint like /currentsong?sid=.... If that capability is disabled on the server or the ID is wrong, audio may still work while the track title never appears.

Icecast 2

For Icecast 2, the mountpoint is critical. The documentation states that streamurl should be set without the mountpoint, while the mountpoint itself is passed through icecastmountpoint. Metadata is usually read through /status-json.xsl. If Icecast is configured in a non-standard way, it is useful to open that URL directly and confirm that the data is actually available.

Radiojar, Radio.co, and HLS

Radiojar and Radio.co use their own station status schemes, so some parameters work differently. For HLS, you need to specify the full .m3u8 URL and use the appropriate method for reading the title if the stream provides that information. Do not copy Shoutcast settings into HLS or Radio.co mechanically. Each stream type has its own structure.

Fallback, Direct, Stream-Icy-Meta, and OwnMetadataUrl

The metadatatechnic parameter controls how data is read. The documentation lists fallback, corsproxy, directly, stream-icy-meta, hls, and ownmetadataurl. In practice, the choice looks like this:

• directly is useful when the streaming server properly allows cross-origin requests.
• fallback can help when requests are routed through PHP on your server, but that also means your site server takes on extra load.
• stream-icy-meta is needed to read metadata directly from the stream if the server supports it.
• ownmetadataurl fits non-standard servers when you can provide plain text in an artist - title format.
• hls is the right choice for an HLS stream when the title can be read from M3U8.

How to Change Metadata Mode Without Creating Chaos

If you use fallback or stream-icy-meta, verify the requirements on your site server first. The documentation mentions PHP, allow_url_fopen, cURL or file function availability, and firewall restrictions. In more recent updates, the developer also removed file_get_contents from the fallback logic and switched remote requests to cURL, so older advice from random discussions should always be checked against the current changelog.

Visualizer, Cover Art, and Mobile Limitations

The player's visual features are best treated as a layer on top of already working audio playback. Luna Web Radio Player supports several visualizer effects, fake and real modes, multicolor settings, transparency, blur, and a ghost effect. But real mode depends on whether the browser is allowed to access audio data with the required permissions.

When to Choose the Fake Visualizer

usevisualizer='fake' is a practical, safe starting point. It gives you visible motion without requiring full access to the stream's audio data. It is especially appropriate if you do not control the streaming server, cannot configure CORS, or want to avoid different results across listener devices.

When It Makes Sense to Try the Real Visualizer

usevisualizer='real' should be enabled only after you verify CORS. The official product page and FAQ both stress that the real visualizer requires a valid CORS policy on the streaming server. Without it, you can end up in a situation where the stream plays, but the visualizer does not work or automatically falls back to fake mode on some devices.

iOS, Safari, and Volume Control

For mobile users, it is important to accept browser limitations up front. The official materials state that iOS devices do not support JavaScript volume control the way desktop browsers do, so the user adjusts sound with the device's physical buttons. The real visualizer is also limited on iOS, Safari, and older browsers, where fake mode may be used instead.

Practical takeaway: do not build your core user experience around the real visualizer or software volume control on mobile devices. The essentials are a clear play button, station name, stream status, and current track.

Practical Example: A Station Page with a Compact Player and Track Verification

Let us walk through the scenario that most radio station owners actually need: create a "Listen Live" page, place a compact player below the intro text, show the station name, current track, and fallback cover image, and confirm that the stream works on both desktop and phone.

Goal

Create a page where the visitor clicks play, hears the live stream, and sees the radio station name plus artist - title if the server provides metadata. The player should fill the width of the content column, stay within the theme layout, and never start unexpectedly without user interaction.

Preparation

• You have a working HTTPS stream, or a clear plan for avoiding mixed content.
• The server type is known, for example shoutcast2 or icecast2.
• A fallback station image has been prepared for coverimage.
• A token has been created for the correct site domain.
• Cache and JavaScript optimization on the test page are not interfering with validation.

Setup Steps

1. Create a test page in WordPress and add a short introduction to the live stream.
2. Insert the Luna Web Radio Player shortcode into a dedicated shortcode block or the Classic Editor.
3. Set userinterface='small', width='100%', and a height around 70px if the player should appear as a compact bar.
4. Add radioname, offlinetext, coverimage, and your theme's base colors.
5. Select the streamtype and related parameters that match your streaming server.
6. Keep autoplay='false' and debug='false' for the public version.
7. Save the page, open it in a private window, and click play.

Expected Result

The player appears as a clean single-line bar, stays within the content area, changes state after you click play, and starts streaming audio. If the metadata settings are correct, the current artist - song title appears in the title area. If current track artwork is unavailable, the station image or the empty state you configured is used instead.

A Common Point of Failure

If an HTTP stream is loaded on an HTTPS page, the browser may block it or behave unpredictably. This is not a WordPress editor problem. Check the browser console and network requests: if you see mixed content warnings, fix the stream protocol first instead of changing colors, dimensions, or interface type.

Practical Use Cases Across Different Website Types

The same radio player can be used in very different ways. The important thing is not to drop it in "somewhere," but to connect it to the purpose of the page. That way, the player feels intentional rather than random, and it helps users understand what they can do right now.

The "Listen Live" Page

The classic option is a dedicated station page. Here, a large interface with cover art and a visualizer makes sense if the page is designed around listening. Add the schedule, a link to the program lineup, or a short note explaining what to do if the stream does not start. Check not only the desktop version but also the mobile layout: a large player may look great on the homepage while taking up too much space on a phone.

A Compact Bar in the Header or Footer

If listeners need quick access to the stream, a compact userinterface='small' player can be placed in a persistent area of the theme. But this depends on the layout. If the header reloads on every page change, the music will stop. On a standard WordPress site, that is expected behavior, not a plugin bug.

An Event Page or Temporary Broadcast

For a conference, festival, or temporary broadcast, the player can sit next to the event schedule. In this scenario, offlinetext is especially useful: visitors should understand that the stream starts later or is temporarily unavailable. Do not leave an empty area if the stream is offline.

A Directory of Multiple Stations

The documentation allows multiple player instances on one page, and each one can have its own appearance and stream. But the more streams you place on a page, the more UX matters. Do not make users stare at five active visualizers at once. It is better to show a station list and activate only the player the listener needs right now. Also keep in mind that multiple calls to the streaming server and metadata endpoints can increase load.

Result Checks, Performance, and Security

After setup, do not stop at "it plays on my machine." Before publishing, you need a short validation path that confirms the player works for a normal visitor, does not produce obvious errors, and is not relying on stale cached JavaScript.

Browser Validation

• Open the page in a private window to rule out old localStorage data.
• Check the browser console for CORS, mixed content, and JavaScript errors.
• Open the network tab and confirm that the audio stream and metadata URL are not returning blocks or error statuses.
• Test the first play click, pause, mute, and the visualizer button if it is enabled.
• Compare the page on desktop and phone, especially if you are using the large interface.

Cache, CDN, and Updates

In the changelog, the developer mentioned cache busting for JavaScript files so browsers load the latest version after an update. But on a live website, cache plugins, a CDN, and script optimizers may also be involved. After updating the plugin, clear the site cache and CDN cache, and if behavior looks strange, temporarily exclude the player scripts from file merging or deferred loading.

Security should not be ignored either. The product history includes fixes related to file reading and XSS through shortcodes. There is no need to alarm users in the article, but the correct recommendation is obvious: keep the installed plugin up to date, review the changelog, do not allow untrusted authors to insert arbitrary shortcodes on public pages, and test updates on a copy of the site.

A Safe CSS Tweak Without Editing Plugin Code

If the player sits inside a content block and needs extra spacing, do not edit the plugin files. Wrap the shortcode in a container through the editor or theme template, and add the CSS to a child theme or the site's built-in custom CSS area. This approach does not depend on the plugin's internal classes and is easy to roll back.

.radio-player-panel {
  margin: 24px 0;
  max-width: 960px;
}

.radio-player-panel + .radio-note {
  font-size: 14px;
  line-height: 1.5;
  opacity: 0.82;
}

The check is simple: reload the page without cache and make sure only the outer spacing around the block changed, while the buttons and internal player elements remain clickable. To roll back, remove that CSS and the wrapper itself. The shortcode stays the same.

Why the Player Is Not Working and How to Find the Cause Quickly

The best way to troubleshoot is to move from simple to complex: first verify the stream itself, then the protocol, then the server type, then metadata, then CORS, cache, and device-specific behavior. If you change ten shortcode parameters at once, you will never know which edit actually helped.

The Player Is Visible, but the Radio Will Not Start

Symptom: the interface appears, but after clicking there is no sound, or the stream stops immediately. Possible causes include an incorrect URL, an extra trailing slash, the wrong streamtype, mixed content on an HTTPS page, or an unavailable streaming server.

What to Check Before Editing the Shortcode

What to verify: open the stream URL directly, then check the browser console and network requests. For Shoutcast and Icecast, confirm that the mountpoint or path was not placed in the wrong parameter. If the site uses HTTPS, use an HTTPS stream or another valid delivery method.

Audio Plays, but Artist - Title Does Not Appear

Symptom: the stream plays, but the current track line is empty, static, or displays the wrong text. Possible causes include the server not returning metadata, the wrong metadatatechnic setting, an unavailable /status-json.xsl or /currentsong endpoint, missing CORS permission, or an own metadata URL that is not returning plain text.

Where to Confirm the Problem

What to verify: open the metadata URL directly if you know it. For Icecast, check the JSON status endpoint. For Shoutcast, check the currentsong endpoint with the correct stream ID. If you use ownmetadataurl, do not return XML or JSON if your setup expects a simple artist - title string.

The Real Visualizer Does Not Work

Symptom: the player streams audio, but the visualizer does not respond or switches to another mode. The cause is often CORS: the browser does not allow JavaScript to analyze audio data from a third-party source without permission. On iOS, Safari, and older browsers, there may also be limitations described by the developer.

How to fix it: first switch to usevisualizer='fake' and confirm that the base playback scenario works. If you specifically need real mode, configure CORS on the streaming server and test it with a separate request. If the server belongs to someone else and you cannot change the headers, keep fake mode as the stable public option.

Volume Control Does Not Work on iPhone or iPad

Symptom: the volume slider works on desktop, but on iOS the user cannot control volume inside the player. This is a platform limitation: sound is adjusted with the device's physical buttons. There is no point trying to fix this with shortcode parameters.

What to do: do not promise users an in-player volume control on iOS. Make sure play/pause works and that the interface does not look broken if the volume control is hidden or effectively useless.

The Fullsize Player Does Not Take Up the Expected Height

Symptom: height='100%' does not produce a fullscreen-style block. The reason is pure CSS: percentage height works only when parent containers have an explicit height. Use a height the browser can understand directly, such as 100vh, or set height for all parent containers in your theme.

Behavior Did Not Change After the Update

Symptom: you updated the files, but the browser still seems to be using the old version. Check the WordPress cache, CDN, JavaScript optimizers, and a private browser window. If script merging is enabled, temporarily exclude the player files from optimization and repeat the test.

When CodeCanyon Luna Web Radio Player Is the Right Choice

Luna Web Radio Player is a good fit when you already have a clear live stream and need a flexible embeddable player format inside WordPress. Its main strength is the large number of shortcode parameters: you can control appearance, interface type, metadata, cover logic, visualizer behavior, and how the player works on the page. But that is exactly why setup should be handled step by step rather than by blindly copying an oversized shortcode.

Before publishing, verify the stream, HTTPS, CORS, metadata endpoint, mobile behavior, cache, and that the installed version is current. Once those checks are done, you can move to the download section and get the WordPress version to test the plugin on your site copy or staging page.

If instead your goal is show schedules, host profiles, archives, a continuous sitewide player with AJAX navigation, or a large audio file catalog, evaluate neighboring solutions before implementation. That way, you will not force a player to solve a problem that really calls for a different class of tool.