CodeCanyon Apollo - WordPress Plugin

How to Set Up CodeCanyon Apollo for a WordPress Music Player

In this guide, CodeCanyon Apollo is treated not as just another catalog listing, but as a practical tool for websites where audio needs to stay front and center: a music blog, artist page, podcast section, album promo page, media archive, or editorial project built around track selections.

Below, you'll find setup instructions, initial checks, sticky mode configuration, playlist and category management, buy and download buttons, browser limitations, troubleshooting, and comparable alternatives. This guide is written for someone who already has the plugin ZIP file and wants to turn it into a clear, reliable result on the public-facing side of the site.

Special attention is given to the details short reviews often skip: how to verify audio file formats, why autoplay may still fail even when the setting is enabled, where the sticky player can conflict with a theme or cache, how to structure a playlist properly, and when it makes more sense to choose a different audio player instead of Apollo.

What problem this player solves on a website

Apollo belongs to the category of HTML5 audio players for WordPress. Its core idea is to display a full-width player with a playlist and let visitors keep listening without losing playback controls as they scroll through the page. Unlike a basic audio block, this type of player can be sticky, meaning it can stay fixed at the bottom or within the page, and it can also work as a standard embedded player.

According to the official description, the product supports .mp3 and .ogg audio files, two built-in themes, custom color settings, track categories, playlist search, social sharing buttons, a purchase link, a lyrics link, a download button on desktop devices, multiple player instances, and an option to build a playlist from a folder of MP3 files. In practice, that means the site gets more than just a play button - it gets a compact audio showcase.

Apollo delivers the most value when audio is part of the visitor journey. If someone is reading an artist page, browsing news, moving between posts, or exploring a media archive, the sticky bar helps them keep the current track playing. If all you need is one short sound clip in the middle of an article, this plugin may be more than you need.

Where Apollo makes the most sense

This plugin is worth considering when a site has a recurring audio collection and needs a controlled playlist. For example, a musician can showcase demo tracks with purchase links, a podcast project can present a list of episodes, an educational site can organize audio lessons by category, and an editorial site can pair tracks with a story or feature.

• For an artist page, album art or an artist image, a buy button, and lyrics can be especially useful.
• For a podcast, clear episode navigation, search, categories, and uninterrupted playback while reading the page matter more.
• For a media archive, multiple player instances across different pages and the ability to group tracks are helpful.
• For an album promo page, the sticky version works well because it stays visible as visitors scroll through the landing page.

When it is better not to overcomplicate things

If the site only has one audio file and does not need playlists, categories, search, or a custom visual style, the standard WordPress block or a simpler audio player may be easier to maintain. Apollo adds interface elements, scripts, settings, and its own playback logic. That makes sense for a dedicated audio section, but not always for a single embed inside an article.

What to check before installation

Before installing the plugin, make sure the site is ready for audio not only technically, but editorially as well. The player itself will not solve problems with file quality, access permissions, oversized cover images, an undefined playlist structure, or theme conflicts. The better the preparation, the less troubleshooting you will need after activation.

Files and formats

The official Apollo description lists support for .mp3 and .ogg. In practical terms, that means your source audio files should be brought into a predictable state: clear filenames, correct MIME types on the server, reasonable file sizes, no spaces or special characters in URLs, and stable storage either in the WordPress Media Library or in a preconfigured folder.

If you plan to use the download button, test more than just playback. Check how the link behaves in the browser. Different servers and CDNs can send different headers for audio files, so sometimes a file opens in a new tab instead of downloading. That is not necessarily an Apollo issue - often the cause is the way the file is being served.

Theme, bottom bar, and fixed-position elements

A sticky player takes up a noticeable horizontal area. Before turning it on, check whether the theme already has a fixed bottom bar, floating chat, cookie notice, mobile menu, back-to-top button, or ad unit using the bottom part of the screen. If several elements compete for the same space, visitors will see overlap instead of a usable audio interface.

A solid prep workflow looks like this: open the homepage, a typical post, a page with long content, and a mobile-width layout in developer tools. If there are already important elements at the bottom, decide in advance which one has priority. In some cases, using Apollo in its standard embedded mode on a specific page is a better choice than enabling a sticky player site-wide.

Cache, optimization, and script bundling

An audio player depends on JavaScript and playback state. Aggressive optimization can move a script to the wrong place, delay initialization, or bundle files in a way that makes the player behave unpredictably. This is especially noticeable in sticky mode, playlist search, category switching, and continuous playback scenarios.

Before enabling minification and deferred loading, run a clean test without optimization plugins. First make sure Apollo works properly on a normal page, then turn caching back on and check which exact setting changes the behavior.

Installing the plugin and running the first check in WordPress

A commercial ZIP plugin is installed through the standard WordPress screen. In the admin panel, go to Plugins - Add New, click Upload Plugin, select the ZIP file, install it, and activate it with Activate Plugin. If the server does not allow ZIP uploads through the admin area, WordPress also supports manually uploading the plugin folder to wp-content/plugins and activating it afterward, but that method is better left to an administrator or developer.

After activation, do not start changing every setting right away. First create a minimal test: one audio file, a clear title, one page, and the default player output. This simple check confirms that the plugin loads, the audio is reachable by URL, the theme does not block the output, and the browser can actually play the file.

What to check after activation

1. Open the plugin screen in the admin panel and make sure you can see the player, playlist, or settings management area.
2. Add one test MP3 file from the Media Library or another supported file that you know opens directly in the browser.
3. Save the player and insert the shortcode generated by the plugin into a test page using the Shortcode block.
4. Publish the page in a private or test context, open it in a new tab, and start playback manually.
5. Check the browser console and the Network tab if the audio does not start or the cover image does not load.

At this stage, it is important not to confuse two different goals. The first is confirming that the plugin is installed and displays correctly. The second is building a styled, sticky player connected to a full playlist. If the issue appears in the minimal test, it is much easier to identify before categories, buttons, cover art, and sticky behavior are added.

Shortcode and the block editor

The official product page mentions support for multiple player instances, and WordPress provides the standard Shortcode block for this kind of embed. Use the exact shortcode Apollo gives you in your admin panel. Do not rewrite it manually or paste JavaScript fragments into the post editor.

If the site uses a page builder, first test everything on a standard WordPress page. Then move the shortcode into a builder widget or HTML block that is known to execute shortcodes properly. Some visual editors display the shortcode while editing, but do not actually run it until the published page is viewed.

Settings map after installation

It helps to think of Apollo configuration in layers: player behavior, visual style, playlist structure, extra buttons, and analytics. Do not start with colors. First decide where the player should live on the site and how visitors are expected to use it.

Sticky or standard output

Sticky mode makes sense when the player should remain accessible while users scroll or navigate around the site. Standard output is a better fit for pages where the audio block is part of the content and should not distract people on other pages. The official description says sticky behavior can be set for a single page or the entire site, and that you can also disable it and embed the player directly into the content of a page or post.

For the first launch, choose the safest route: standard output on a test page. Then enable sticky mode on just one page and check whether it overlaps the footer, cookie notice, signup form, or mobile navigation. If everything looks fine, you can consider expanding it site-wide.

Appearance and color scheme

Apollo includes two base themes - black and white - along with color settings. The practical sequence is simple: first choose a theme that contrasts well with the site background, then set accent colors, then check whether the title, author, buttons, and search field remain readable. Do not style the player only for a nice screenshot - it needs to stay usable on real pages with different backgrounds and different content lengths.

For most sites, a neutral starting point is safest: a dark panel on a light site, or a light panel in a darker visual section. Colors that are too close together reduce accessibility, and bright accents on every element quickly turn the player into visual noise.

Playlist, categories, and search

The playlist is the most important part of the setup. Apollo can group items by category, and a single audio file can belong to multiple categories. That is useful if one track belongs to an album, a genre, and a curated collection at the same time. But that kind of flexibility requires discipline in naming.

Before adding tracks in bulk, create a short category vocabulary. For a podcast, that might be Interviews, News, and Deep Dives; for a musician, Singles, Live, and Instrumentals; for an educational site, Lessons, Practice, and Review. If categories are created randomly, search and filtering will lose their value very quickly.

Purchase, download, and lyrics buttons

The official product page confirms support for purchase, download, and lyrics buttons. These elements should only be enabled when they actually help the visitor. A purchase button makes sense for a track that links to a release page or store. A lyrics link is useful for vocal tracks, language lessons, or any material where the text is part of the experience. Downloads should be enabled intentionally, especially if the audio is subject to distribution restrictions.

Do not turn every playlist row into the same bundle of buttons. If some tracks do not have a purchase page or lyrics page, it is better to leave those fields empty or hide the corresponding element than to send users to nonexistent pages.

Google Analytics and playback events

Apollo also advertises Google Analytics tracking so you can see how many times each audio file has been played. Use this feature only after the player is already working reliably. Otherwise, your analytics will mix real listening activity with tests, page reloads, and setup errors.

Before enabling analytics, decide what you actually consider meaningful: playback starts, repeat listens, category popularity, or interest in a specific episode. After turning it on, verify that events appear in your analytics system and separate the test page from public traffic data.

How to build a playlist without creating chaos

A playlist in an audio player is like a small catalog. If it is organized cleanly, visitors can immediately tell what to listen to next. If it is full of inconsistent titles, mismatched covers, empty author fields, and random categories, even a good player will feel like a technical afterthought.

Minimum track card

For each track, prepare the title, artist or source, audio file URL, artist image or cover art, category, purchase link if needed, and lyrics link if available. Not every field has to be filled, but missing fields should be intentional. For example, an instrumental demo may not need lyrics, and a free podcast does not need a purchase link.

If you are using an artist image instead of the vinyl animation, keep the covers visually consistent. Mixed aspect ratios, oversized files, and random photos lead to interface shifts and slower loading. For a page with a large playlist, it is better to prepare images at the same size and compress them to a sensible weight.

Categories as navigation, not a tag dump

Because one audio file can appear in multiple categories, it is tempting to add lots of labels. But visitors experience categories as navigation. If there are too many, they stop being helpful. A smaller number of clear groups works better, while search can handle more precise queries by title or artist.

Test categories against real user questions. If someone asks, "Where are the live recordings?" then a Live category is useful. If they ask, "Which episodes are for beginners?" then a Beginner category helps. A category like Miscellaneous almost never helps because it does not promise a clear outcome.

Read Folder and bulk file import

The Read Folder option can speed up playlist creation from a folder of MP3 files. It makes sense when you already have a prepared folder, the files are named consistently, and the structure does not require manual editorial work for every item. But if each track needs its own buttons, categories, lyrics, and artwork, manual entry may be slower at first yet more reliable in the final result.

After using Read Folder, always verify track order, titles, duration, file availability, and search behavior. Bulk generation only saves time when the source material is clean. If the files are organized inconsistently, the plugin will not turn them into a strong editorial structure on its own.

Continuous listening and behavior between pages

In the developer's official description of Apollo, the continuous playback scenario is emphasized separately: the visitor can move through the site menu while the player preserves the feel of uninterrupted listening. For a site owner, this is not just a nice feature - it is a separate part of the user journey that needs testing. If the player works on one page but resets after navigation, users will experience the site as a regular page with an audio embed, not as a real audio section.

It is important to distinguish expected behavior from impossible promises here. Browsers still control when audio can start, mobile platforms restrict autoplay, and page transitions depend on how the plugin preserves state and how the theme loads content. So do not test only the play button. Test the actual path: open a page, start a track, move to the About page, return to the album, open a popup, close it, and check the current track again.

Testing path

Create a small set of pages that reflects a real listening journey. For a music site, that could be the homepage, an album page, a track page, and an article about the release. For a podcast, it could be the episode archive, a single episode, an author page, and a text-based show note page. The point is to test not an ideal demo page, but the path where people will actually listen.

What counts as a successful result

Success is not just the fact that audio plays. A successful result means the visitor understands which track is active, sees the controls, does not get unexpected playback without interaction, can open another page, and does not run into overlap at the bottom of the screen. If the player still appears visually after navigation but the track title resets or the buttons stop responding, that is still a journey problem.

Where failures usually appear

Failures often show up at the boundary between the plugin and its environment: a caching plugin changes script order, the theme adds its own fixed bar, the page builder inserts the shortcode into a block that updates differently, or a cookie banner covers the bottom of the screen. That is why testing should happen in two phases: first on a clean test page, then on the real site template with surrounding UI elements enabled.

Popup as an extra mode, not a replacement for the player

A popup window is useful when a listener wants to separate the player and keep navigating the site. But the popup should not be the only way to interact. Some visitors block popups, some do not expect a separate window on mobile, and some simply want to control the track in the current tab.

The practical approach is this: the main player should make sense without the popup, while the popup remains an extra option. Make sure the open button is visible, the action happens after a click, the window does not look like an ad, and the user can return to the page without losing context. If the popup confuses your audience, it is better to leave it disabled and strengthen the normal sticky mode instead.

How not to break the journey with optimization

After a successful journey test, enable optimization gradually. Start with page caching, then CSS minification, then script-related settings. After each step, repeat the exact same path. If a problem appears after one specific setting, do not start changing the player or playlist - the cause is most likely the optimizer or the file loading order.

For a production site, it helps to keep a short checklist: which pages to test after a plugin, theme, or cache update, which track to use as a test case, which buttons should be visible, and where to look for console errors. That kind of note saves time when the site is maintained by someone other than the person who originally configured Apollo.

Sticky player, popup, and continuous playback

Sticky mode and the popup window are Apollo's most visible differences from a basic audio block. They solve the same user need: letting the listener move around the site without losing control of the music. But both features need to be tested on different pages and devices.

What sticky means for the visitor

When the player is fixed in place, it becomes part of the site's interface. Visitors see playback controls not only where the audio started, but as they continue through the page. That works well for long-form content, album landing pages, and media archives. At the same time, this block competes with navigation, ads, cookie banners, and mobile panels.

Start by testing the sticky player on pages of different lengths: a short page, a long article, a page with a form, a post archive, and a mobile layout. If the player covers a form submit button or bottom navigation, that is not a cosmetic issue - it is a real UX problem.

Popup window and site navigation

The official Apollo description mentions a button for opening the player in a popup window. This mode is helpful when the listener wants the music to continue while browsing through the menu. But popups depend on browser behavior, popup-blocking settings, and user expectations. Do not make the popup the only way to listen.

A practical setup is to keep the main player on the page and treat the popup as an optional mode for people who want a separate listening window. Make sure the window opens after an explicit click, is not blocked by the browser, and does not feel like a promotional popup.

Autoplay and mobile limitations

Apollo's sources specifically note that autoplay does not work on iOS and Android, and that autoplay with sound is restricted by browser policies in Safari and Chrome. This is not a settings bug you can fix with a checkbox. Modern browsers require user interaction before audible audio can start because unexpected sound creates a poor experience.

Design the experience as if the first playback always starts with a human action. A visible play button, a clear track title, and a player that is easy to find matter more than trying to force audio to start automatically. If the interface includes an autoplay setting, treat it only as a secondary behavior for situations where the browser allows it.

Practical example: an album page with a sticky player

Let's look at a realistic scenario: a musician's site has a page for a new release, and visitors need to be able to listen to several tracks, click through to buy, open the lyrics, and keep the player available while reading the description. This is not an abstract "use case" - it is a working setup that matches Apollo's feature set.

Goal

Create an album page where the top section contains a release description, the player with tracks appears below it, and playback controls remain available during scrolling. The playlist should include categories, search, either an artist image or vinyl animation, a purchase button, and a lyrics link for the appropriate tracks.

Preparation

Before configuring the player, upload or prepare your audio files in a supported format, images at consistent dimensions, a list of titles, authors, categories, and links. If the tracks will be sold on separate pages, have those URLs ready in advance. If the lyrics live on your site, create those pages before filling out the playlist.

Setup steps

1. Create a new player in the Apollo admin panel and add 2-3 test tracks instead of the full discography.
2. Select standard output mode and insert the shortcode into a draft album page.
3. Check playback, track switching, and the visibility of titles and images.
4. Add categories such as Singles, Live, or Instrumental, then test filtering.
5. Enable playlist search and verify that tracks can be found by title and author.
6. Add purchase links and lyrics links only where those pages actually exist.
7. Enable sticky mode for that page and test scrolling all the way to the footer.
8. Once the setup is stable, add the remaining tracks and repeat the test in a private browser window.

Result check

The result can be considered successful if a visitor opens the page, sees a clear player, manually starts a track, switches between songs, uses search, opens the purchase or lyrics link, and does not lose the control bar while scrolling. On mobile, audio should start only after user interaction, not automatically.

Quick takeaway: first build a small working player, then enable sticky behavior and expand the playlist. That order makes it much easier to identify which setting caused a problem if something stops working.

Practical usage ideas for different types of sites

Apollo's feature set supports more than a single music page. Below are scenarios based on the player's confirmed capabilities: playlist, categories, search, sticky mode, extra buttons, cover art, multiple instances, and analytics. Not every idea fits every site, but these examples make it easier to choose a structure before you start configuring anything.

Podcast or audio series

For a podcast, Apollo can serve as an episode playlist. Categories can separate interviews, news, deep dives, and special episodes, while search by title or author speeds up navigation. Sticky mode is especially useful on long episode-description pages because the listener can keep reading without losing access to controls.

The test is simple: open an episode from the middle of the list, scroll the page, switch categories, and make sure the user never loses track of what is currently playing. If the playlist gets too long, consider using separate players by season or topic.

Music promo section

For a musician or label, cover art, purchase links, lyrics, and brand alignment matter most. You do not need to enable every feature at once. It is better to build a clean release page with a few tracks, clear links, a disciplined color scheme, and confirmation that the sticky bar does not cover the subscribe button or contact form.

If there are multiple versions of the same track, use categories or separate players: studio version, live version, instrumental. That keeps visitors from getting lost in a long list of similar titles.

Educational audio archive

In an educational project, Apollo can present lessons, dictations, exercises, or audio examples. Categories by level, topic, or exercise type matter here, along with clear track naming. A download button can be useful if local saving is allowed, but it should only be enabled after you verify the distribution rights.

Check more than just playback - check sequence and clarity. A learner should understand which file belongs to which lesson. If titles are too similar, add a lesson number or topic to the track name.

Editorial feature with an audio selection

For an article built around a curated selection of tracks, the standard embedded player may be the better option, with sticky mode left off. That keeps the audio as part of the article instead of turning it into a global site interface. Multiple player instances on the same page should be used carefully: each one needs a clear purpose, or users will not understand which list they are listening to.

Checking the result after setup

After configuration, do not stop at viewing the page in your own browser. An audio player touches the frontend, the Media Library, JavaScript, mobile restrictions, cache, and external links. What you need is a short but systematic test.

Public-facing check

• Open the page in a private window to avoid interference from your logged-in admin session.
• Start the first track manually and switch to the next one.
• Test search by title and author if search is enabled.
• Switch categories and make sure the expected tracks remain visible.
• Scroll the page to the footer and check the sticky bar.
• Open the purchase link, lyrics link, and download link if those buttons are enabled.
• Repeat the test at mobile width and do not expect autoplay without a click.

Console and network check

If something does not work, open developer tools. In the Network tab, check the statuses of audio files, images, and scripts. 404 errors point to a bad URL, access errors suggest permissions or file protection issues, and JavaScript errors often appear after minification, deferred loading, or a theme conflict.

Do not try to fix the issue blindly by changing several settings at once. Disable script optimization, test the page again, then restore settings one at a time. That way you will identify the real cause instead of stumbling into a combination that only appears to work.

Compatibility, security, and safe improvements

There are several areas where Apollo should be handled carefully: outdated versions, caching, third-party page builders, mobile limitations, cookie notices, and permissions for audio files. None of these issues make the plugin bad, but they do require normal operational discipline.

Updates and old archives

The official changelog shows ongoing updates, and the Wordfence database notes that older versions up to and including 3.4 had a reflected XSS vulnerability that was fixed in version 3.6.4. The practical conclusion is simple: do not deploy an old ZIP file from a local project archive if you have access to a newer version of the product. After updating, test the player on a test page and clear the cache.

You do not need to describe the vulnerability details to visitors on the public page. For an administrator, one rule is enough: use an up-to-date archive from a trusted source, do not keep old active copies of the plugin around, and verify that the update did not break the playlist.

Cookie notice

The official product page specifically notes that the product uses cookies and that the site should include a consent notice. The site owner should handle the legal wording based on their jurisdiction, but from a technical perspective, this is an easy thing to overlook when rolling out audio features and analytics.

Safe CSS for the standard output mode

If you are embedding the standard non-sticky version of the player inside a long page, you can wrap the shortcode in your own container and adjust only the outer spacing. This does not modify Apollo's code and is easy to roll back. The method relies on normal WordPress and CSS practice, not on hidden internal plugin classes.

<div class="apollo-player-shell">
  [apollo_shortcode_from_admin]
</div>

.apollo-player-shell {
  margin: 28px 0;
  max-width: 100%;
}

.apollo-player-shell + p {
  margin-top: 20px;
}

Check: refresh the page and make sure the embedded player now has clean spacing around it, while sticky mode and buttons remain unchanged. Rollback: remove the container or the CSS. Do not use this example to alter the plugin's internal structure, and do not replace the shortcode with custom HTML.

Where a precise Apollo video helps

The product has two relevant videos listed on the official page: one for installation and one for using the plugin. For this guide, the second video is more useful because it supports the practical discussion around player setup, playlist building, and result validation rather than simply showing the basic fact that a ZIP plugin can be installed.

Watch the video after reading the sections on playlists and sticky mode. That makes it easier to connect the interface steps with the logic explained above. The most useful parts of the video are naturally the settings workflow and the player-building process. I am not listing exact timestamps because the source may be displayed differently over time, but the video's value here is specifically in showing how Apollo is used after activation.

Why the player may not work and how to find the cause

It is best to troubleshoot Apollo from simple to complex: the file, the shortcode output, scripts, the sticky layer, browser restrictions, then cache. If you immediately start changing the theme, plugins, and every player setting at once, the real cause will disappear in the noise.

The player does not appear on the page

Symptom: the shortcode appears as plain text or there is no player interface on the page. Likely cause: the shortcode was inserted into a block that does not execute it, the plugin is not active, the cache is showing an old version of the page, or the page builder is escaping the embed.

Check whether the same shortcode works in the standard Shortcode block on a simple test page. If it works there, the problem is not Apollo itself but the insertion point. If it does not work there either, go back to the Plugins screen, confirm activation, and clear the cache.

Audio does not start

Symptom: the interface is visible, but the track does not play. First open the direct audio file URL in the browser. If the file does not open directly, the player will not be able to play it. If it does open, check the format, MIME type, server response status, and any JavaScript errors.

If the issue only appears after enabling an optimization plugin, temporarily exclude the player scripts from bundling, deferred loading, or minification. Restore settings one at a time and test after each change.

Autoplay does not work

Symptom: autoplay is enabled, but the audio does not start on its own. For audible audio, this is expected behavior in many browsers and on mobile devices. The fix is not to work around the restriction, but to make the first click easy: a visible play button, a clear track title, and no overlapping interface elements.

The sticky bar overlaps the footer or mobile menu

Symptom: the player is visible, but it covers a button, form, cookie banner, or bottom navigation. Check the page at several widths, temporarily disable other fixed elements, and determine which component is occupying the bottom screen area.

The fix depends on the theme: sometimes it is enough to disable sticky mode on a specific page, sometimes the cookie banner position needs to be changed, and sometimes Apollo should remain in standard mode. Do not blindly raise the z-index: that can hide another important part of the interface.

Search or categories show strange results

Symptom: search does not find an obvious track, a category appears empty, or one file shows up where it should not. Check the title, author, and category fields for that track. The official description says search works by title and author, so stray spaces, inconsistent artist naming, and chaotic categories will affect the result immediately.

The fix is to normalize names and the category vocabulary, then save the playlist again. If Read Folder is being used, make sure no extra or test files were pulled into the folder.

The appearance or behavior changed after an update

Symptom: after an update, the player loads differently, an element disappears, or the order changes. Clear the site and browser cache, review the changelog, and test a minimal player on a separate page. If the issue is tied to the theme or an optimizer, temporarily disabling those layers will help narrow the search.

When CodeCanyon Apollo is the right choice

CodeCanyon Apollo is a strong option if you need a prominent HTML5 audio player with a full-width bar, playlist, categories, search, purchase button, download button, lyrics link, and sticky display capability. It is especially useful for music pages, podcasts, audio archives, and promotional content where visitors should be able to listen while continuing to move through the site.

Before launch, check the files, the minimal shortcode setup, the theme, sticky positioning, mobile behavior, cache, and the age of the plugin archive. If all of that looks solid, you can download the latest version of CodeCanyon Apollo and test the plugin on a site copy or a private page.

If, however, you only need one simple audio block, a more advanced WooCommerce audio store, podcast RSS logic, or deep integration with a specific page builder, compare Apollo with the alternatives listed above. The right choice here depends less on the number of features and more on the path you want visitors to take from the first click to playback and the next action.