CodeCanyon COVID-19 Coronavirus - WordPress Plugin
The plugin allows adding statistics table/widgets via shortcode to inform site visitors about changes in the situation about Coronavirus pandemic.

Plugin Features
The COVID-19 statistics plugin for WordPress offers real-time tracking of pandemic data within WordPress websites. With a user-friendly interface, it seamlessly integrates live statistics on COVID-19 cases, deaths, recoveries, and more. Users can easily customize the display to suit their websites design, keeping visitors informed with up-to-date information. The plugin fetches data from reliable sources, ensuring accuracy and reliability in presenting essential COVID-19 statistics for online audiences.
For website owners seeking to provide valuable pandemic information to their visitors, integrating CodeCanyon COVID-19 Coronavirus enhances user experience and engagement. By displaying live updates on COVID-19 statistics directly on their WordPress sites, website owners contribute to spreading knowledge and awareness during these challenging times. The plugins dynamic features enable easy customization of data representation, making it a versatile tool for various types of WordPress websites.
Upon installation, the COVID-19 statistics plugin for WordPress empowers website administrators to present crucial pandemic information effectively. The plugins responsive design ensures seamless performance across devices, providing a consistent user experience. Its ability to display statistics in different formats, such as charts, graphs, or tables, allows for a visually appealing representation of complex data, enhancing user comprehension and engagement.
The plugins intuitive dashboard enables users to effortlessly manage and update the displayed COVID-19 statistics without the need for technical expertise. With regular updates and new features, website owners can continually enhance their COVID-19 information hub, ensuring that visitors have access to the latest data. The plugins robust framework guarantees stability and security, offering a reliable solution for WordPress users looking to incorporate real-time pandemic statistics into their websites.
In conclusion, the COVID-19 statistics plugin for WordPress provides an essential tool for website owners to inform and educate their audience about the ongoing pandemic. Its seamless integration, customizable features, and reliable data sourcing make it a valuable asset for any WordPress site aiming to contribute to the dissemination of accurate and pertinent COVID-19 information. By leveraging this plugin, website owners can proactively engage visitors and help raise awareness about the global health crisis.
Specifications:
| Release date: | 12-07-2019 | |
| Last updated: | 04-01-2022 | |
| Type: | Paid | |
| License: | GPL | |
| Subject: | Miscellaneous | |
| Compatibility: | W5.x | |
| Includes: | Plugin | |
| Language packs: |
|
|
| Developer: | CodeCanyon | |
| Rating: | ||
Share with your friends!
How to Use CodeCanyon COVID-19 Coronavirus on a WordPress Site
This guide to CodeCanyon COVID-19 Coronavirus will help you determine whether the plugin is suitable for your informational section, prepare a safe place to publish data, configure the map and widgets, create a clear way to present statistics, and confirm that visitors are not being shown a misleading page. We will cover the path from reviewing the data source and installing the plugin in WordPress to placing a map, table, compact indicators, and diagnosing the situation where only a shortcode remains on the page.
This product has a narrow purpose, so it is best viewed not as a universal analytics tool but as a ready-made presentation layer for COVID-19 information. Based on the available descriptions, the plugin displays an interactive situation map, a statistics table, and a set of widgets, all of which can be inserted into page content with the [COVID19] shortcode. The descriptions also mention light and dark themes, background and color settings, sidebar blocks, and different ways to present information. That makes it a practical candidate for an archive reference page, an organization section, a school project, a medically reviewed portal, or a historical publication where the map is one element of the page rather than the sole source for decision-making.
This kind of widget has an important limitation that good design cannot hide: maps and numbers can look authoritative, but their quality is not determined by their appearance. The plugin retrieves or displays data from an external source, and that source may change, slow down, stop responding, rename a territory, or close access. That is why a sound setup starts not with choosing colors, but with an editorial policy: what caption readers will see, who is responsible for publication, how often an editor reviews the block, and what should appear when the response is outdated.
What the Map Is For and Where It Does Not Belong
The plugin is useful when visitors need to quickly understand numbers that have already been prepared and reviewed. On a news project page, that may be a compact world map with an explanation of the reporting period. On a local community site, it may be a sidebar block focused on a selected country and linked to a detailed official report. On an educational page, it may be a visual aid that helps explain the difference between a map, a table, and a note about where the data came from. In every case, the product is responsible for displaying information on the website, not for medical advice, diagnosis, forecasting, or validating a third-party database.
The strength of a map is that visitors can see geographic distribution without reading a long table. A table, by contrast, is useful when people need to compare territories without losing exact values. A compact widget works well in a sidebar, where the reader is already engaged with an article. The shortcode connects these formats to the normal WordPress publishing workflow: an editor creates or opens a post, inserts a shortcode block, saves a draft, and reviews the public-facing page. There is no need to build a separate page template for a single informational block if the theme correctly renders post content.
Three Safe Publishing Use Cases
The first use case is an archive or educational page. Here, the map accompanies material about how public statistical datasets are visualized. The snapshot date, a link to the original source, and an explanation of the methodology matter more than the appearance of live updates. If the external source stops working, the page can remain available with a neutral note explaining that the interactive block is unavailable, rather than replacing it with random figures.
The second use case is an editorial information block. It is appropriate when the site team has assigned someone to verify the data. The map should not stand alone: it needs nearby text explaining what is being measured, which territory is selected, and where readers can find the original source. For this type of page, decide in advance whether a broken widget should be hidden or replaced with a clear message when the data stops updating.
The third use case is a local sidebar module. Instead of a large map, the author places a compact summary where it supports the article. This option puts less load on the page and does not distract from the main text. However, it should not be used as an unnamed decorative number: a short caption must provide context, and the link should lead to material that includes the source and supporting explanation.
Who May Find the Plugin Useful
- An information-site editor who can distinguish displaying figures from verifying them and is ready to monitor the visible output regularly.
- A community or institution administrator who needs a compact topical block in an article, post, or sidebar without developing a map from scratch.
- An educator or reference-content author who explains how to work with public indicators and supplements the visual with a link to official information.
- A WordPress developer who needs a ready-made element for a temporary or archive page and can check for conflicts with the theme, caching, and security settings.
When Another Approach Is Better
This plugin should not be the foundation of a site if you need a modern epidemiological system with guaranteed support, an in-house observation database, editor roles, an audit trail, an API contract, and legally significant reporting. Based on the available descriptions, the product is designed around a map, table, widgets, and content insertion. It does not replace an institution's internal database or turn third-party statistics into a verified medical conclusion.
It may also be unnecessary on a page where the audience only needs one manually updated link to an official organization. An interactive block adds dependencies: the theme must load its styles correctly, the browser must run scripts, and the external source must be available. If those conditions do not create a meaningful benefit for the reader, a straightforward editorial link will be more honest and reliable.
Practical rule: publish a map only when you are prepared to explain where the numbers come from, what their limitations are, and what happens when the data is unavailable. A polished widget without context creates a false impression of precision.
Evaluate the Data Source and Publication Lifecycle First
Before installing anything, it helps to separate four layers. The first is the source that collects the information. The second is the channel through which that information becomes available to the plugin. The third is the plugin configuration and its shortcode in WordPress. The fourth is the page visitors see. A problem at any level can look the same: an empty map, an old figure, missing styles, or a broken block. When an administrator does not separate these layers, they may start changing colors and templates even though the cause is an external response.
Available descriptions associate the product with public medical and statistical sources. Do not repeat that description on your page as a permanent guarantee. Source lists and the availability of historical data can change, and some early services may no longer be updated. Before publishing, open the page in a regular browser, compare the country name and several indicators with the original source you are willing to recommend, and save a short internal note: who checked it, when, and what they saw.
A Minimal Editorial Record
Create an internal record for every page that includes a map, even on a small site. Record the page URL, widget location, selected display type, intended source, responsible editor, and the condition that makes the block outdated. You do not need to show the full record to visitors. However, it should make clear why the map is on the page, who decides whether to disable it, and where to find fallback material.
Keep the text around the map separate from its automated content. The introductory paragraph should be written by an editor and should not depend on an external response. It can honestly state that the interactive block is for reference only. Place a link below the map to the main official resource for your subject. If the plugin includes a title or caption field, use it for a neutral label rather than an unverified promise of current information.
Pre-Publication Check
- Open the future page while signed out and make sure visitors can actually see the map or widget.
- Compare one global indicator and one territory with your chosen original source, taking methodological differences into account.
- Check the caption, the source link, and readability at a narrow screen width.
- Clear the cache only after you have seen the correct output in the draft, then repeat the check in a separate browser window.
- Document how quickly an editor can hide the block or replace it with a standard text message if the external response becomes questionable.
Do not publish automatically updated medical statistics without a clear path to the original source. This does not prevent you from using CodeCanyon COVID-19 Coronavirus in informational material, but it establishes the right boundary for its role.
Prepare WordPress Before Installation: Compatibility, Backup, and Page Placement
Once the plugin's role is clear, prepare WordPress as you would for any extension that depends on external services. Start with a copy of the site, a test post, or a restricted environment rather than the live homepage. This is especially important for a map with dynamic data: you need to check more than activation. You also need to review style loading, scripts, editor behavior, cache responses, and behavior at small screen widths. If you make changes directly on the live site, it becomes difficult to distinguish a plugin issue from caching effects or theme edits.
Create a backup of theme files and the database using the method already established for your site. There is no need to invent a separate process just for this widget. What matters is confirming that the backup is genuinely usable: it is stored somewhere accessible, a responsible person is identified, and the rollback procedure is known. Then capture the current page or sidebar in a screenshot. This simple comparison point will show whether the layout changes after the map is connected.
What to Check Before Uploading the ZIP File
Compare your current WordPress requirements with those listed in the plugin package and on its original product page. Early descriptions of the product may refer to WordPress and PHP versions typical of its release period. Do not turn those details into a compatibility promise for every modern configuration. Treat them as a signal instead: install the extension on a copy first, enable hosting error logs through your usual process, and check whether any warnings appear after opening the map page.
Make sure the administrator has permission to install plugins and that the server allows an archive of the required size to be uploaded. On managed hosting, a security policy may restrict uploads or activation. If that happens, do not try to work around the restriction through unverified file operations. Ask the person responsible for the server for the standard safe method of installing an archive you have already obtained. For a normal WordPress site, the built-in upload screen in the admin dashboard is sufficient.
Also review your existing extensions. Extra attention is needed not because the map will necessarily conflict with all of them, but because the page may already use chart, map, or table libraries, script optimizers, external-request blockers, or plugins that force JavaScript to load late. If the interactive part disappears after activation while the shortcode text remains, this list will make diagnosis much faster.
Choosing the First Display Location
Before installation, decide where the first instance will live: in a draft of a dedicated page, in a regular post, in a widget area, or in a prepared template. For the initial check, a separate test page is usually the best location. It does not compete with a heavy homepage, lets you change the shortcode freely, and makes the output easy to remove. Once the display is confirmed, you can move the same approach into the live material.
| Location | When It Fits | What to Check Most Carefully |
|---|---|---|
| Test page | You need a safe place to configure the map and table without affecting primary content. | Shortcode rendering, style loading, source caption, and the absence of browser errors. |
| Article | The map explains the topic of a specific piece of content and is not a standalone service. | Content-column width, the paragraph before and after the widget, and mobile readability. |
| Sidebar | You need a compact summary rather than a large map. | Block height, wrapping of long names, and avoiding clutter near navigation. |
| Page template | One tested block is needed across several similar pieces of content. | Display conditions, shortcode duplication, and the ability to quickly disable the block in one location. |
Do not place the first instance in both a post and a sidebar at the same time. If a problem occurs, it will be unclear whether it is related to the display format, theme, or repeated script loading. One test block gives you a clean outcome. You can test a second format afterward.
Caching, Optimization, and External Responses
Caching is useful for normal articles, but live or potentially live indicators create a separate question: exactly what will visitors see, and for how long? Server-side caching may store a previously rendered page. An optimization plugin may combine files or delay loading. A CDN may serve an old HTML copy. None of these mechanisms is automatically a problem. The problem starts when an editor believes the block has been updated while visitors see a different state.
Document the verification path in advance: first open the page in a new private window, then check the response while signed out, then compare the time and values with the editorial source. If the site uses aggressive JavaScript optimization, temporarily exclude only the file or rule that is documented as related to the plugin, and test the change on a copy. Do not disable all caching on the live site for a single widget. That would reduce performance without providing a useful explanation of the cause.
Minimum Conditions for the First Launch
- A backup exists, and the plugin can be rolled back without editing WordPress core files.
- An empty or restricted test page is ready with a standard shortcode block.
- You know which plugins manage caching, file compression, and policies for external connections.
- An editorial original source has been selected for comparison with the public-facing output.
- A failure response has been decided: hide the block, keep explanatory text, or temporarily use a link to the original source.
Quick takeaway: preparation does not guarantee that an external feed will remain available forever, but it turns a possible failure into a manageable check. You can now install the plugin on a test page and immediately see which layer needs attention.
Installation and the First Check Without Unnecessary Assumptions
Use an archive obtained legally through your own account or from an authorized administrator. Do not unzip it in advance unless the package instructions require a different order. In WordPress, open Plugins, choose Add New Plugin, then Upload Plugin, select the ZIP archive, and wait for the standard installation to complete. After installation, WordPress will offer to enable the extension using the Activate Plugin button. The exact submenu labels may differ slightly depending on the dashboard language, but the process remains the same.
Do not publish the map immediately after clicking Activate. First return to the Plugins list and make sure the extension is marked active with no system warning. Then check whether a new menu item, settings screen, or help page has appeared. Available descriptions mention the shortcode [COVID19], but specific fields and screen names may vary between builds. Do not invent a navigation path from memory: use the menu, the documentation included with the package, and only the settings you can actually see in your installation.
First Test on a Separate Page
- Create a new page with a clear internal title, such as "Map Test." Do not add editorial content or complex builder blocks yet.
- Insert a
Shortcodeblock or a standard text block that supports shortcodes, then add[COVID19]without additional attributes. - Save the page as a draft or open a preview. Do not use a view available only to a signed-in administrator as your only test.
- Confirm that the expected information block appears instead of raw text. If it renders but looks unpolished, wait for the page to load completely before judging the styles.
- Open the same page in a separate signed-out window and check whether the visible output matches.
If you see the literal text [COVID19], do not try to solve it by replacing it with a random similar shortcode from another product. The most likely explanations are simpler: the plugin is not active, the editor block does not process shortcodes, the code was inserted with extra characters, the page uses an unusual template, or the current package version uses another display method. Return to the vendor documentation and check whether the same test works in a standard WordPress post.
How to Tell Whether the First Launch Succeeded
A successful first launch does not mean every number matches expectations. It means the output renders consistently in two modes: for an administrator and for a guest. The map or other element appears without an error message, does not break the theme's main container, leaves the page title readable, and does not create new critical entries in the hosting log. After that, you can move from confirming its presence to configuring appearance and content.
Configure the Map, Table, and Widgets After Activation
After a successful test, do not copy the shortcode into a dozen pieces of content. First build one reference block and break it into components: what readers see prominently, what remains secondary information, where the original-source link sits, and how the fallback state will appear. Available descriptions of CodeCanyon COVID-19 Coronavirus confirm a map, table, sidebar widgets, and the ability to change presentation. They do not justify claiming that every option exists in every build. The settings below are therefore described as a decision-making sequence: compare each step with the actual screen in your installed version.
Start with a basic display that works without fine styling. If the settings screen lets you choose a block type, keep the map or main widget in its default state first. If width settings are available, use the post container width instead of a fixed large value. Excessively rigid widths often become visible only in the mobile version of a theme: the map spills past the edge, the table gets horizontal scrolling, and the sidebar becomes taller than the main content.
Start With Meaning, Then Refine the Appearance
Every element should have its own purpose. A large map answers the question, "Where are the differences between territories most visible?" A table answers, "Which values should be compared?" A small widget says, "What context does this article have?" Trying to squeeze everything into one block has the opposite effect: visitors do not know where to look, and on a small screen they get a long, unhelpful scroll.
A recommended sequence for a full information page is a short editorial explanation, a map for geographic orientation, a table or list for precise comparison, and then a link to the primary material. Keep only one compact format in a sidebar. If the map takes up substantial space and there is already a table nearby, do not repeat the same figures in four cards. That does not make the page more informative, but it increases the number of places where readers may see conflicting or outdated values.
Settings to Check First
| Setting Group | Practical Decision | How to Verify the Output | When to Roll Back |
|---|---|---|---|
| Display type | Select one primary format for the test page: a map, table, or compact widget. | A guest sees the selected format rather than shortcode text or an empty container. | If the block disrupts the theme layout or duplicates primary content. |
| Territory and scale | Show the world or a territory that is clear from the article, without presenting a local slice as a global view. | The title and page text match what is shown in the map or table. | If the source does not provide an unambiguous explanation of the selected territory. |
| Captions and title | Use neutral wording and add a link to the original source nearby. | A reader can understand what the block displays without reading the code. | If the caption promises accuracy or urgency that you cannot verify. |
| Colors and theme | Apply the standard option first, then align contrast with the site theme. | Labels, borders, and states remain visible against both light and dark page backgrounds. | If a color is interpreted as a medical conclusion rather than a visual hierarchy. |
| Size and responsiveness | Allow the block to shrink within the content column. | At phone width, names are not cut off, buttons do not shift away, and the entire page does not scroll horizontally. | If fixed dimensions break the post or sidebar. |
This sequence matters more than looking for "the best settings" in isolation from the site. A value that works well for a wide news theme may be poor for a narrow educational page. Establish meaning and stability first, then change one setting at a time. After every change, review the public-facing page, not just the admin screen.
The Map: Avoid Turning a Visualization Into Decorative Background
A map is useful when users can genuinely distinguish a geographic pattern. To make that possible, it needs a title, a clear legend if the plugin displays one, and a short explanation of what it means. Do not add assumptions about the coloring method if they are not available in the documentation or visible in the interface. It is enough to state honestly that the map displays data from a connected source and is intended for reference.
If the plugin lets you choose a light or dark theme, assess more than aesthetics. On a light website, a dark map can create emphasis, but it can also make surrounding text feel heavy. On a dark theme, a light block can look like an unrelated ad banner. Compare both options in the actual column where the map will live. Review label contrast, the borders of popup elements, and link behavior. One consistent choice is better than randomly changing the palette on every article.
Do not hide unavailable information behind a saturated color, a placeholder with invented numbers, or a long animation. If the map does not receive data, visitors should see a clear editorial message and a link to the original source. Depending on the plugin's capabilities, that may mean manually hiding the shortcode on the page or temporarily replacing the test block with standard text. Prepare this fallback while everything is still working.
Tables and Country Lists: Accuracy Matters More Than Column Count
A table may seem neutral, but it quickly becomes unreadable when it contains too many indicators. Keep only the data that supports the publication's purpose. If the material explains a historical snapshot, a limited set of fields with a careful caption is enough. If the purpose is to compare several territories, readers should understand why those territories were selected. Do not add columns simply because the widget makes them available.
Check three conditions: a wide desktop page, a narrow column, and a phone. On a phone, a table may either scroll neatly inside its container or become a long list. Both formats are acceptable if visitors retain the title and context. It is undesirable when a table expands the entire document or covers navigation. If the theme already styles tables well, use its standard rules first and avoid layering complex third-party styling over them.
Editorial Caption for a Table
Add two short lines of regular text beneath the table: what the indicators represent and where to find the methodology. Do not replace this with a lengthy legal disclaimer. The purpose of the caption is to give readers context and give editors a quick way to update the link. If you cannot explain where the fields come from, do not present the table as a source for decision-making. Limit it to a map used as an illustration, or remove the block until the data is clarified.
Sidebar Widgets and Repeated Output
The product descriptions mention sidebar widgets. Use them as a supplement rather than as a second full statistics panel. Open Appearance and then Widgets if your theme uses a classic widget area. In a block theme, the corresponding location may be managed through Appearance and Editor. First find the specific area provided by the theme, then add one plugin element there if it is available in the list.
Give it a neutral title, check its order next to search, navigation, or subscriptions, and view the page with browser extensions disabled. The widget should not interfere with navigation and should not be the only place where important information is published. If visitors collapse the sidebar on mobile or the theme moves it below the content, the main article text should still retain its meaning.
Quick takeaway: configuration is complete when the format fits the page's purpose, the title does not promise more than it can support, and the map, table, or widget behaves correctly for a guest at the real screen width.
The [COVID19] Shortcode: From Editor to Visible Block
A shortcode is not merely a fragment in square brackets. In WordPress, it acts as a command the content system recognizes when rendering content. Available product listings identify [COVID19] as the way to insert the display into posts and pages. This is useful because it separates the plugin from a specific theme: the same tested block can be placed wherever the theme renders content.
Treat it as an editorial component. Start by creating a sample page, put the shortcode on its own line, and write normal context around it. Do not wrap it in random HTML tags, place it inside a link, or duplicate it several times on one page before you have tested a single instance. In the block editor, use the Shortcode block. In the Classic Editor, insert the line where WordPress processes shortcodes, not in a field that escapes code as ordinary text.
Shortcode Testing Sequence
- Save the original version,
[COVID19], without unclear attributes. - Open a preview and the guest version of the page.
- Confirm that the block has not appeared twice because of a widget, template, or repeated insertion.
- Once it works, add only one needed setting in the plugin interface or in confirmed documentation.
- Record the sample page URL and purpose in the editorial record so you do not need to search for the working version again.
If you use a page builder, first place the shortcode in its built-in text or dedicated shortcode module and test the output on a regular WordPress page. Do not conclude that there is an incompatibility until you have separated builder problems from plugin problems. With a complex theme, it can sometimes be wiser to keep the map in a standard post rather than placing it in a decorative section with animation and a constrained height.
Practical Example: A Reference Page With a Map, Table, and Editorial Review
Consider a focused example that does not attribute unsupported features to the product. Imagine that a public-interest website is creating a section called "How to Read Historical Pandemic Data." The purpose of the page is to give readers geographic orientation by country, show a limited set of indicators, and direct them to the original source. The site does not collect its own medical data, forecast risk, or promise updates at a specific minute. CodeCanyon COVID-19 Coronavirus is used as a presentation layer, while the editor is responsible for context.
Goal and Prerequisites
Before you begin, you should already have one working test shortcode and a draft page in WordPress. Prepare three short text fragments: an introductory sentence explaining that the block is for reference, a link to the chosen official organization, and a note for cases where the interactive content cannot be verified. Do not copy lengthy data into the page text itself. The idea is for the static content to explain the purpose while the plugin provides visual access to the display.
Also designate a responsible person. On a small site, that may be a single editor. On a project with several authors, establish a rule: only the assigned person changes display settings and approves publication. This is not bureaucracy. If multiple authors take turns changing colors, captions, and shortcodes, visitors receive different interpretations of the same block, and finding the cause later becomes difficult.
Step 1. Build the Page Around a Clear Question
Create a page with a title that does not promise "the most accurate data" or a "live medical summary" unless you can prove those claims. In the first paragraph, explain that the map and table help readers orient themselves within the presented indicators. In the next paragraph, state the limitation: figures and methodology must be checked against the primary source. Then insert the shortcode as a separate block.
This framing changes how the block is perceived: readers see not an unnamed widget but part of a reference resource. Do not put the shortcode before the explanation, especially at the top of an article. A large interactive element without introductory text can look like an ad banner or create the false impression that the site itself maintains official statistics.
Step 2. Choose One Primary Visible Output
For the first version of the page, choose only one main format. If the primary task is comparing territories, use a map. If readers need to compare values, begin with a table. If the page already includes a large infographic and only needs context, choose a compact widget. The decision should be based on the question the page answers, not on the number of available presentations.
After choosing a format, open the plugin settings and review the available options without trying to change everything at once. If you see light and dark modes, choose the one that does not conflict with the theme. If colors are available, establish text and border contrast first, then align the palette with the site design. Color should have a visual purpose, not an emotional one: saturated red can draw attention, but around a medical subject it may be read as an alarm signal without explanation.
Step 3. Add the Exact Insertion Format
In the WordPress block editor, use the Shortcode block and insert exactly [COVID19]. Open a preview after saving. If your build of the product uses other parameters, take them from the built-in documentation or the screen that is actually available after activation. Do not copy attributes from alternative statistics plugins: a similar purpose does not make them compatible.
At this stage, verify two outcomes. First, does the content render rather than the literal shortcode string? Second, does the article structure remain intact when the block loads in the standard theme? If everything is working, keep the original version as your recovery point. During the next edit, you can return to it instead of guessing which parameter set was stable.
Step 4. Give Visitors a Way to Verify the Context
Below the interactive block, add a short subheading and a link to the source your editorial team uses for verification. The link should not disguise a lack of review. Use plain language: "Check the methodology and current status at the source." If the publication is historical, explain the period covered instead of trying to maintain dynamic updates, and keep the external source as a reference destination.
It is important not to mix roles. A link does not alter plugin content, and a widget does not validate a link. Together, they create a transparent path: the map draws attention to distribution, the text explains what readers are seeing, and the original source lets them clarify the meaning. This combination makes the page more useful than simply inserting a shortcode.
Step 5. Check the Page as Both a Guest and an Editor
Visit the page after clearing the specific cache that serves that URL. Then open it in a private browser window. Do not consider the output successful if it appears only in a preview for a signed-in user. Deferred scripts may not load for guests, a CDN may serve a different copy, and mixed-content blocking policies may behave differently.
Check at least five conditions: the map or selected block appears; neighboring text has not shifted; the original-source link is clickable; the block does not overflow the screen; and the page does not show the old shortcode. If any condition fails, do not move on to decorative refinements. Return to diagnosing the specific layer: activation, shortcode, plugin settings, theme, or cache.
A Commonly Missed Detail
Everything may look normal on the test page but fail in the actual article. The cause is often content width, builder blocks, a sidebar, or post styles. When moving the content into publication, transfer not only the shortcode but also the tested context: the title, explanatory paragraph, source link, and fallback rule. Repeat the guest preview after moving it. Do not assume that the same line will always create the same layout in different templates.
Use Different Display Formats Without Repeating the Same Meaning
The plugin is interesting not because of a single map, but because it combines formats: a map, a statistics table, and sidebar widgets serve different purposes. However, broader functionality does not mean all of them should be displayed on every page at once. Good implementation follows one principle: "one main question, one main format." Additional formats should be used only when they help move from the general view to the specific details.
Map for Orientation, Table for Comparison
The upper part of a detailed reference page is the best place for the map. It quickly shows that territory matters for understanding the topic. Place the table lower on the page, after an explanation. Visitors receive geographic structure first, then an exact list. Between them, you can include one paragraph explaining that the map and table show the same dataset at different levels of detail, if that accurately reflects the visible output.
Do not try to make visitors treat a table like a map. If precise comparison matters more on a small screen, it is better to link to a page with a full table than to fill it with text that is too small. In WordPress, you can create a separate child reference page for that purpose and add a regular link in the main article. This does not require an invented integration with the product and helps preserve readability.
A Compact Widget for Related Content
A sidebar widget is appropriate when the article already contains an explanation and the reader needs a brief point of reference. For example, several articles in a section can display one neutral block that leads to the complete map page. Do not place the same full map in every category article. It slows pages down, repeats content, and makes it harder to manage changes in the data source.
If the theme collapses the sidebar below the article, make sure the widget does not become the first large element after comments or repeat itself in the mobile template. Give it a title that preserves its meaning independently of the article title, such as "Reference Data for This Topic." Avoid wording that promises continuous updates unless you have a procedure for confirming them.
One Source Page for Multiple Articles
A practical editorial option is to maintain one tested page with the main shortcode and link to it contextually from related articles. The plugin remains installed in one understandable location, verification happens at one URL, and editors do not multiply copies of settings. If necessary, you can temporarily hide just one block without editing dozens of older publications.
This approach is especially useful when the map serves as a historical reference supplement. Main articles retain stable text, while the interactive portion is managed centrally. If external data stops responding, an editor changes one page and explains the situation clearly. This is not an automatic plugin feature, but a safe way to organize content with WordPress.
Output check: five minutes after publication, ask someone who did not configure the page to open it on a phone. If they can explain what the block shows, where to verify the information, and where to go next, the structure is well chosen.
What Happens Between the Source, the Plugin, and the Public Page
Understanding the chain helps prevent unnecessary edits. An external source produces the data. The plugin retrieves or uses that feed through its own internal behavior. WordPress processes the shortcode and builds the page HTML. The theme provides containers, dimensions, fonts, and behavior at different screen sizes. A cache stores one version of the response. The visitor's browser loads styles and scripts. If the map is missing, the question "Is the plugin broken?" is too broad. You need to determine at which point the expected output disappeared.
For example, if the shortcode is visible as text, the issue is usually closer to WordPress and the editor than to external data. If the map container is present but remains empty, the cause may be scripts, browser policy, or an unavailable external response. If the block is correct for an administrator but outdated for a guest, caching is more likely. If the map appears but overflows its container, check theme styles and container width. This breakdown does not give an instant answer, but it prevents chaotic changes to every setting at once.
Verify the Output: Data, Accessibility, and Behavior Across Devices
Configuration does not end when the map appears in the editor. It ends when the output can be reproduced and explained. This is especially important with CodeCanyon COVID-19 Coronavirus: the plugin visualizes information readers may perceive as current and official. Verification should cover more than appearance. It should include the meaning of the message, the source, element loading, and the user's path to additional information.
Split the review into three passes. The first is editorial: do the page title, block caption, and selected territory align? The second is technical: does the output appear for guests, are there browser errors, and does the map break the layout? The third is operational: does the site team know when to recheck the widget and what to do when figures are disputed? If you skip the third pass, even a perfect layout remains risky.
Editorial Verification Without False Precision
Open the chosen original source and compare not only the number but also the indicator name. Similar datasets can differ in methodology, update timing, included territories, data status, or rounding method. Do not manually correct a discrepancy in the plugin if you do not understand why it exists. Record it and determine whether the output still fits the purpose of the page. Sometimes it is wiser to replace an overly definite caption with a more accurate reference statement. Sometimes it is better to temporarily hide the interactive block.
Do not use the map to provide medical advice, assess individual risk, or make urgent recommendations. It can be a useful part of informational navigation, but it should not become a substitute for an official notice. It does not need alarming emphasis, prominent calls to action, or wording that encourages visitors to make decisions based solely on a region's color.
A Review Question for the Editor
Before publishing, ask yourself: "Can the reader distinguish between what the widget drew and what the source confirmed?" If the answer is no, add one clear line above or below the block. It can be short, but it should be visible on the same page. This does not reduce the value of the map; it places it properly within the article.
Technical Review in Three Conditions
The first condition is a regular desktop browser while signed out. Here, you confirm that WordPress processed the shortcode, styles are present, and the interactive element is not hidden by a consent notice or theme overlay. The second condition is a narrow width. You do not need a dozen devices: resize the browser window, then open the page on a real phone. Review captions, the table, scrolling, interactive-area size, and neighboring blocks.
The third condition is the cached path. Open the page in a new window, refresh it after the standard cache purge, and, if necessary, compare the visible HTML with what a signed-in editor sees. If guests continue to see the old block, do not change the shortcode immediately. First identify which layer is storing the old page: WordPress cache, server cache, CDN, or browser cache. Change a rule only after locating the cause, and document it for future publications.
Accessibility and Clear Text Around the Visual
An interactive map should not be the only carrier of meaning. Some users browse with a keyboard, some increase zoom, some use assistive technologies, and some simply do not want to interpret color gradients. That is why the text before and after the block must explain the essentials. A table or short list may be more useful for comparison, while a link to the original source gives people the option to choose a format that works for them.
Review the page heading hierarchy. The map should sit beneath a subheading that describes its purpose. Avoid empty headings such as "Data." Instead, phrase the question the block answers: "Comparing Indicators by Territory" or "Reference Map in Article Context." Such wording improves navigation and does not depend on the interactive portion loading successfully.
Watch contrast and do not rely on color alone. If the plugin offers themes, choose one where labels remain distinguishable. If the issue comes from the site's general styles, check the theme settings first. Add local styles only when you can identify the specific element and test them on a copy. Do not write CSS for guessed class names from an unknown plugin version: after an update, it may stop working or affect other blocks.
A Safe Improvement Without Editing Plugin Files
This product has no confirmed public API for custom output changes, so there is no need to invent hooks or edit extension files. It is safer to improve the surrounding content using WordPress tools. Create a reusable block or template fragment with a neutral explanation, a link to the original source, and fallback text. Insert it above or below the shortcode on pages that need the same editorial context.
For example, in the block editor, you can prepare a group containing a heading, short paragraph, and link, then save it as a synchronized pattern if your WordPress version and editor permissions allow it. In a classic theme, you can keep the same text in a draft sample page and copy it only after review. This does not change the CodeCanyon COVID-19 Coronavirus code and can be rolled back easily by removing or updating a regular content block.
How to Test and Roll Back This Improvement
- Create the explanatory block on a test page without changing the original shortcode.
- Open the output as a guest and make sure the source link is visible without covering the map.
- Check phone width: the text should remain above or below the widget rather than overlapping it.
- If the theme styling changes, remove only this content fragment and return to the working sample page.
This approach is better than risky edits inside plugin files. When WordPress or the extension is updated, standard content remains under your control, and rolling back does not require code restoration.
Performance, Caching, and External Connection Policies
For visitors, not only contextual accuracy but also page speed matters. Maps, tables, and interactive elements can add styles and scripts. On a small reference page, that is usually acceptable when the element is genuinely needed. On a long homepage with several galleries, advertising blocks, and analytics, another interactive layer may become noticeable. Do not judge by feel alone: compare the page before and after in the same browser and check for a noticeable delay or layout shift.
Do Not Put the Full Block Everywhere
The safest way to limit load is not to duplicate a large map across all pages. One reference page with the main output and contextual links from articles is usually more useful than a dozen identical inserts. If you need a compact sidebar element, choose the most concise available format and check that it does not also appear on pages where it is unrelated to the topic.
The "put it across the entire site" approach may seem convenient, but it creates two problems. First, it is difficult to check the external feed on every page. Second, one styling issue spreads immediately to archives, posts, and search pages. Controlled output through one or several topic-specific pages gives the editor a clear area of responsibility.
How to Work With Cache
Do not disable caching completely. First decide how quickly visitors truly need to see a new state. For reference or historical material, it is reasonable to prioritize page stability rather than create the appearance of instant updates. If freshness requirements are high, the plugin and its source must be independently verified for that mode. Do not treat the ability to configure caching as proof that external data is timely.
When you do not see the result after changing settings, use this sequence: save the changes, open the page as an author, clear the cache layer responsible for the page, then check the guest view. If the output does not change, stop and identify the source of the old version. Repeatedly saving at random can overwrite a useful configuration and has no effect on a CDN or server-side copy.
External Requests and Security Policy
A modern site may block external requests through security rules, content policies, browser extensions, or hosting settings. That is not necessarily a plugin problem. During diagnosis, first check whether a container appears on the page, then review browser messages and the hosting log using normal administrator tools. Do not weaken global security rules for one test on a live site. Instead, perform the check on a copy and determine which specific domain or script is associated with the output.
Practical conclusion: the fastest page is one where the interactive block genuinely answers the reader's question. If the map only decorates the article, keep the text and official link instead of adding another dependency.
Post-Publication Review and a Monitoring Log
After publication, do not forget the page indefinitely. Create a short review schedule that matches the subject. An archive article may only need occasional editorial review. For an active section, define an interval the team can realistically maintain. Do not promise a review frequency on the page if no one is available to fulfill it. An internal log matters more than a polished statement.
In the log, record the review date, page address, visible output, link to the original source, and editorial decision. If values begin to look questionable, do not simply write "not working." Record the precise symptom: the map does not render, the table is empty, numbers differ, the block does not load for guests, or the theme design breaks. This log is not a medical database, but it helps the technical team and editor avoid starting an investigation from scratch.
Diagnosis and Fixes: Why the Map, Table, or Shortcode May Not Work
With this type of plugin, the same visible failure can have different causes. An empty block may mean the external channel is unavailable, or it may result from script optimization. A literal shortcode indicates a content-processing problem, not a color-scheme issue. Old figures for guests are more often related to caching than reinstalling. Start by naming the symptom, check one layer, and only then change a setting. This sequence preserves the working configuration and makes the solution reproducible.
The Page Shows [COVID19] Text Instead of a Map
Symptom: after saving the article, visitors see the literal string in square brackets. This does not prove that external data is broken, because WordPress has not reached that stage yet. First check whether the required plugin is active in Plugins. Then make sure the shortcode is inserted in a block that allows it to be processed. In the block editor, this is usually Shortcode, not a code block or a fragment displayed as preformatted text.
Possible cause: the plugin is disabled, the editor escapes the shortcode, extra quotation marks or spaces entered the line, or the particular build uses another display mechanism. What to do: create a clean test page, insert only [COVID19], save it, and open it while signed out. If the clean page works, compare it with the problematic page: block type, page template, builder, and content filters. If it does not work there either, consult the package documentation rather than inserting syntax from another coronavirus widget.
When to roll back: if changing the block makes the widget render but breaks the article layout, restore the original content structure and try a separate test page. Do not change theme or plugin files to process one shortcode.
The Container Is Present, but the Map or Data Remains Empty
Symptom: the heading, area, or border appears, but the interactive content does not populate. First distinguish an external-response problem from a script-loading problem. Open the same page in another browser and in a private window. If the behavior differs, a browser extension, local cache, or blocker may be affecting the output. If it is empty everywhere, review the normal browser messages and hosting log available to the site administrator.
Possible cause: the external source or a dependent script is unavailable, a security policy blocks the connection, an optimizer delayed a required file, or the response format changed. Available early product descriptions do not justify guaranteeing the availability of external services years later, so do not hide the problem behind fictitious numbers. What to check: whether an error appears during loading, whether the block works on a clean page, and whether the issue disappears when you temporarily exclude a specific optimization rule on a site copy.
How to fix it: if the cause is a clearly identified rule for combining or delaying scripts, exclude only the corresponding element according to your optimizer's documentation and repeat the guest test. If the external response is unavailable or cannot be verified, hide the interactive block, keep an editorial explanation, and provide a source link. Rollback: restore the optimizer exclusion if it does not affect the output, and return to the tested sample page.
Everything Is Visible for the Administrator, but Visitors See an Old or Different Version
Symptom: the map has updated in preview, but visitors see an old block, old title, or previous design. This is a classic reason to check caching rather than reinstall the plugin. Administrators often receive an uncached page, while guests receive HTML from a server cache or CDN.
What to check: open the URL in a new private window, then compare it in another browser. Check whether separate caching is enabled at the host, in the theme, in a performance plugin, or through an external delivery layer. List the layers, then clear only the one responsible for that URL. Repeat the same guest test after each purge.
How to fix it: first wait for the standard cache purge to complete, then check the page. If an exclusion is necessary, make it for a specific route or script only after testing on a copy. When to roll back: if the exclusion reduces performance across a broad section or does not change guest output, remove it and continue investigating another cache layer.
The Map Overflows the Screen or the Table Breaks the Article Layout
Symptom: the element looks acceptable on a desktop computer, but a phone shows horizontal scrolling, clipped labels, or an excessively tall sidebar. Possible cause: a fixed width, an unusual post template, a conflict with the theme's global styles, or too dense a set of table fields. This is not a reason to hide the issue by shrinking text until it becomes unreadable.
What to check: open the test page in a normal content column and compare it with the live post. Temporarily remove adjacent decorative blocks to see the container boundary. If the display has a width setting, restore the default or flexible value. If the issue remains, check theme settings for tables and built-in blocks. Do not write CSS for guessed class names or edit the plugin's source files.
How to fix it: reduce table content, move the full table to a separate page, or replace a large map with a compact sidebar widget. Rollback: return the page to one map or to the tested shortcode on a dedicated page. A simple readable block is better than an impressive but broken layout.
The Data Looks Questionable or Does Not Match the Chosen Source
Symptom: the territory name differs, an individual indicator does not match the official page, or the data format is unclear. Here, a technical "fix" can be more dangerous than the failure itself. Possible cause: different methodologies, an external-feed delay, a historical dataset, a change in the original source, or discontinued support for a source that the early product version expected.
What to check: compare the indicator name, time context, and several values rather than one number. Record the discrepancy in the editorial log. Do not manually change figures if the site does not maintain its own verified database. How to fix it: clarify the explanatory text, temporarily hide the widget, or move the page into archive mode with clear dating of the material. If the product no longer receives a verifiable external response, do not present it as an active monitoring system.
When to roll back: if you have already changed a caption or visual setting to hide the mismatch, restore neutral text and remove the interactive block until confirmation is available. A transparent pause is safer than a convincing but unclear map.
The Block Appearance Changed After a Theme or WordPress Update
Symptom: the map appears, but fonts, spacing, buttons, or the table look different after an update to the surrounding system. Possible cause: the theme changed global styles, the builder changed its markup, or an older extension was not designed for the new combination. Do not conclude that the entire setup is incompatible based on one screen.
What to check: reproduce the issue on a test copy using a standard WordPress theme or a default post template. If the block looks correct in a simple environment, the problem lies at the intersection of the theme and content. If not, record the exact symptom and consult the documentation or support for the source from which the product was obtained. How to fix it: use a simpler container, disable a conflicting decorative block on that page, or restore the tested post template. Rollback: restore the copy if the update disrupted not only the map but other site elements as well.
Short Table for Initial Diagnosis
| Symptom | First Step | Do Not Do This Immediately |
|---|---|---|
| Shortcode is visible | Check activation and the editor block type. | Do not insert unknown parameters or code from another plugin. |
| Empty interactive area | Compare guest mode and browser messages. | Do not publish invented fallback figures. |
| Guest sees old output | Locate the cache layer. | Do not reinstall the plugin without a reason. |
| Mobile display is broken | Check the container and reduce the display format. | Do not shrink text until it is unreadable. |
| Questionable figures | Compare methodology and temporarily remove the block if needed. | Do not hide the issue with a cosmetic edit. |
Quick takeaway: diagnosis is successful when you can name the symptom, the layer causing it, and a reversible action. Reinstallation, disabling every plugin, and editing files should remain last responses, not first reactions.
Product Limitations and the Decision to Keep Using It
The main limitation of CodeCanyon COVID-19 Coronavirus is inherent to its purpose. It is a WordPress plugin for displaying maps, tables, and widgets, not a primary medical information service. External channels used when early pandemic solutions were created may change availability and format. The plugin should therefore be treated as a component of an already reviewed editorial process, not as a standalone data source.
Another limitation is the age of the ecosystem. If the product has not received confirmed updates for a long time, you cannot promise in advance that it will work with the current theme, optimizer, browsers, and server configuration. Testing on a copy of the site matters more than any general advice. If testing requires broad security changes, mass script exclusions, or complex manual edits, the widget's benefit may be lower than its maintenance cost.
At the same time, the product can remain reasonable for a limited role: an archive page, educational material, an editorial block with a responsible author, or a temporary reference publication. In these situations, it is easier to manage one URL, explain the source, and quickly hide the block when doubts arise. The decision should be based not on how attractive the map looks, but on whether the site can support it honestly.
Frequently Asked Questions About Setup and Use
Can I install the plugin directly on the site's main page?
Technically, that is possible only after testing, but it is more practical to start with a test page or a site copy. This lets you see how the shortcode, map, table, and styles behave without the influence of a complex homepage. After a successful guest review, move the tested block into live content together with its explanation and source link.
What should I do if the page only shows [COVID19]?
Check that the extension is active in Plugins and review where it was inserted. In the block editor, use the Shortcode block rather than a code block. Then test a clean page containing one shortcode line. Do not change the syntax using examples from another plugin: similar products use different commands and parameters.
Can the map be considered an official source of medical information?
No. The plugin displays data in WordPress, but it does not confirm the methodology, current status, or legal standing of that data. The page should include clear context and a link to an original source selected by the editorial team. If the external response looks questionable, it is more honest to hide the block temporarily than to publish it as final truth.
Why does the map work for an administrator but not for a guest, or why does the guest see an older version?
A common reason is the difference between an administrator's uncached view and a guest's cached page. Open the address in a private window, then check server caching, the optimization plugin, and the CDN. Clear only the layer responsible for the page, and repeat one guest test after every action.
Do I need to display the map, table, and widget on every page?
No. A map is useful for geographic orientation, a table for comparison, and a widget for brief context. Choose the primary format for each page and add a second one only when it provides new information. Repeating identical data creates load and makes editorial verification more difficult.
Can I match the colors to my site theme?
Available product descriptions mention appearance and color-scheme settings. Start with the standard option and change colors one at a time, checking text contrast and phone behavior. Do not use color as the only way to communicate meaning, and do not create alarming emphasis without an explanation.
Will the plugin work with a modern WordPress version without testing?
That would be an unreliable promise. Early COVID-19 products depend on the WordPress version, theme, PHP, optimization, and availability of external data. Install it on a site copy, run the shortcode test, check the guest view, and review the error log. If operation requires broad security changes or complex manual edits, it is better to choose another option.
When is it better to avoid an interactive map?
Avoid it if you cannot explain where the numbers come from, verify the external response, ensure readability on a phone, or maintain the block after publication. In that situation, a standard reference page with careful text and a link to official material is more useful and reliable.
When CodeCanyon COVID-19 Coronavirus Is a Good Choice
The plugin can be a good choice when you specifically need a WordPress-based way to display a reference map, table, or compact widget within a limited, controlled page. Its strongest role is giving an editor a shortcode-based element that can be tested on a dedicated URL, supported with clear text, and verified as a guest. For this purpose, one stable and explainable output matters more than the maximum number of blocks.
Before you get the WordPress version, prepare a site copy, test page, editorial source, and rollback plan. Then install the extension through the standard workflow, test [COVID19] on a clean page, configure one format, evaluate the guest and mobile views, and maintain a brief review log after publication. This sequence protects both visitors and the site: the plugin remains a useful display tool, while responsibility for meaning and data verification stays where it belongs - with the editorial team.
If the required page needs its own interactive geography, an internal database, or guaranteed operation with a modern data feed, evaluate a specialized solution rather than trying to make a ready-made widget perform someone else's job. But when the purpose is modest and honest - helping readers see reference context and move to the original source - CodeCanyon COVID-19 Coronavirus can be included in a WordPress site as a clear, verifiable component.


