Import screen redesigned to adapt to what a file actually contains - fixes two real gaps where content simply couldn't be imported at all before: posts with no category, and files built from "\ubbf8\ub514\uc5b4\ub9cc \ub0b4\ubcf4\ub0b4\uae30" with no posts\/pages.<\/p>","2.3.0":"
Source sites now request "\uc815\uc2dd(full)" by default (matches the product being sold as a source+destination pair) instead of defaulting to export_only and requiring a manual click - requires decoblocks-marketplace 5.6.0+ on the server side. Sites already recorded as export_only from an earlier version need one "\uc815\uc2dd \uc804\ud658" click to move past that.<\/p>","2.2.2":"
Fixes export download links themselves erroring out (a nonce mismatch was showing an unrelated WordPress error page) - the nonce requirement is removed for this read-only, capability-gated download, and failures now say exactly what went wrong.<\/p>","2.2.1":"
Fixes "\uc815\uc2dd \uc804\ud658" appearing to do nothing (the result was rendering on the wrong screen), and replaces export auto-download with plain click-to-download links - every automated download trick tried so far has been silently blocked by some browser under some condition.<\/p>","2.2.0":"
Fixes stale-cache reads that could make a valid license appear unverified (e.g. on Redirect Manager) and could make a finished export silently fail to download - 13 option reads across the plugin now bypass the object cache consistently. Also removes the local-folder-picker export option; both export buttons now just download to your browser's normal downloads folder.<\/p>","2.1.1":"
Licensing server domain changed to wpcm.luxdigest.com - update if you were on an earlier version and license checks stop working after the old domain is retired.<\/p>","2.1.0":"
Renamed to LUX Content Migration. "\uc774\ubbf8\uc9c0 \uc8fc\uc18c \uc7ac\uc801\uc6a9" is now hidden entirely on a full license (already automatic) and, on the free tier, explains the license requirement instead of silently doing nothing useful.<\/p>","2.0.1":"
Replaces wp_handle_upload() with the direct temp-file copy that established migration plugins use for proprietary archive formats (likely the real import blocker), and removes the leftover blank browser tab after export.<\/p>","2.0.0":"
File format rearchitected to eliminate base64 encoding of media (the root design flaw behind the recurring import memory failures), and the two-step export flow collapsed into a single click-and-download. Existing .wpmpx files must be re-exported.<\/p>","1.9.7":"
Fixes auto-download after export being silently blocked by the browser (synthetic click several async steps after the real click no longer counted as a user gesture) - now uses a pre-opened tab pattern that isn't subject to that blocking.<\/p>","1.9.6":"
Fixes the actual cause of every import (regardless of size) crashing - a leftover PHP parse error introduced in 1.9.5 that no amount of error-handling could have caught, since it broke the file at compile time. This is the fix that should resolve the recurring "\uc2ec\uac01\ud55c \uc624\ub958" screen.<\/p>","1.9.5":"
Fixes the real memory-crash cause on import (true streaming decompression, not just post-processing), adds an individual "\uae00 \uc120\ud0dd" post picker, and makes exports auto-download instead of requiring a second click.<\/p>","1.9.4":"
Fixes the real cause of the blank "\uc2ec\uac01\ud55c \uc624\ub958" screen on import (embedded-file memory blowup) and a regression that silently ignored full-backup embedded images. Errors are now shown on-screen directly - no server log access needed.<\/p>","1.9.3":"
Fixes "\uc804\uccb4 \ubbf8\ub514\uc5b4 \ubc31\uc5c5" failing with a license-slot error on legitimately licensed single-site accounts - it no longer tries to consume a second 'full' activation slot for what is a one-time export action.<\/p>","1.9.2":"
Adds a visible red-banner alert for any JavaScript error on the export screen - if a button still appears to do nothing, this version will show you exactly why instead of failing silently.<\/p>","1.9.1":"
Fixes "\uc804\uccb4 \ubbf8\ub514\uc5b4 \ubc31\uc5c5" appearing to loop on the folder picker with no feedback - folder selection and starting the backup are now separate steps, and failures show a real error message instead of silently resetting.<\/p>","1.9.0":"
Export selection redesigned into four clear modes (\uc804\uccb4\/\uce74\ud14c\uace0\ub9ac\ubcc4\/\ud398\uc774\uc9c0 \uc120\ud0dd\/\ubbf8\ub514\uc5b4\ub9cc) - choosing a category or page now automatically includes its actual images\/video, no separate media checkbox needed, and a real individual-page picker replaces the old all-pages-only toggle.<\/p>","1.8.0":"
"\uc644\uc804 \ud3ec\ud568\ud615" renamed to "\uc804\uccb4 \ubbf8\ub514\uc5b4 \ubc31\uc5c5" and moved out of Settings into its own button next to the normal export - was previously unreachable for most users due to a license-state check almost no source site satisfies. Now auto-upgrades the license when clicked, and (Chrome\/Edge) offers to save parts directly into a chosen local folder.<\/p>","1.7.0":"
New full-license "\uc644\uc804 \ud3ec\ud568\ud615" export embeds actual image\/video files (read from local disk, not re-downloaded) so the source site can be deleted immediately after export - includes a live per-site disk-space pre-check (no fixed assumption like 2GB) and clear warnings for all three image-handling modes.<\/p>","1.6.0":"
Export Prep now has real content-type and category selection (was previously all-or-nothing with no options), plus an item count on the completed export so you can sanity-check file size against actual post\/page\/media counts.<\/p>","1.5.3":"
Fixes site role settings that appeared to reset\/re-ask repeatedly - forces a cache-bypass on every read and verifies the save actually landed, addressing likely object-cache staleness. Diagnostics page now shows raw DB value vs. cached value side by side.<\/p>","1.5.2":"
Menu registration switched from a same-slug trick to WordPress's standard documented method (each submenu has its own slug now), plus a hidden diagnostics page for troubleshooting menu issues without guesswork.<\/p>","1.5.1":"
UI cleanup: Export Prep is now just the export button (license\/redirect clutter removed), Settings split into two real tabs instead of one long page, role picker collapsed to "current role + change" instead of always showing the full form, and a stray "XML \uc5c5\ub85c\ub4dc" label corrected to match the actual .wpmpx format.<\/p>","1.5.0":"
Export generation is now fully batch\/streaming-based (safe for any site size, won't hit memory\/time limits regardless of hosting), with a visible progress bar and "don't navigate away" notice while it runs. .wpmpx format marker bumped to v2 - re-export any file you haven't imported yet.<\/p>","1.4.0":"
Split export\/import for large sites (was completely missing before) - export now breaks into numbered parts under a configurable size, and the import screen accepts all parts at once and reassembles them automatically.<\/p>","1.3.0":"
Exports are now this plugin's own exclusive .wpmpx format (no longer standard WordPress WXR\/.xml, no longer readable by other tools), and attachments with unrecognized extensions (notably all video files) are no longer silently mislabeled as .jpg.<\/p>","1.2.0":"
Navigation redesign (page-switcher vs. in-page section rail no longer mixed) and one-click export directly from the plugin's own screen instead of handing off to WordPress's generic Tools \u2192 Export screen.<\/p>","1.1.3":"
Fixes Import\/Export Prep screens loading with no CSS\/JS at all (wrong hook-name guess in 1.1.1\/1.1.2), and makes the stuck-license-role fix from 1.1.2 fully automatic instead of requiring you to resubmit the role form.<\/p>","1.1.2":"
Fixes source-site license verification getting permanently stuck requesting the paid "full" role instead of the free "export_only" role after any prior full-role request - update if your export\/source site's license shows "\ud655\uc778\ub418\uc9c0 \uc54a\uc74c" despite a correct key.<\/p>","1.1.1":"
Fixes a dead first menu item and missing CSS\/JS on the Import\/Export screens (both introduced in 1.1.0's menu restructuring) - update if clicking the top menu item did nothing, or the screens looked unstyled.<\/p>","1.1.0":"
Source-site "Export Prep" screen added (was missing since 1.0.0) - update if the old site's menu only showed Redirects with nothing about exporting.<\/p>","1.0.0":"
Initial release.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3679234,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3679234,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["3.0.6"],"block_files":[],"assets_screenshots":[],"screenshots":{"1":"Role selection on first activation.","2":"Category-by-category import screen with live progress."}},"plugin_section":[],"plugin_tags":[1859,87,84,4155,727],"plugin_category":[50,59],"plugin_contributors":[275590],"plugin_business_model":[],"class_list":["post-360356","plugin","type-plugin","status-publish","hentry","plugin_tags-export","plugin_tags-import","plugin_tags-media","plugin_tags-migration","plugin_tags-redirect","plugin_category-media","plugin_category-utilities-and-tools","plugin_contributors-luxsnap","plugin_committers-luxsnap"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/lux-content-migration\/assets\/icon-128x128.png?rev=3679234","icon_2x":"https:\/\/ps.w.org\/lux-content-migration\/assets\/icon-256x256.png?rev=3679234","generated":false},"screenshots":[],"raw_content":"\n
LUX Content Migration is installed on both<\/strong> sides of a WordPress-to-WordPress migration:<\/p>\n\n This plugin is fully functional with no limits on the number of posts, pages, or sites - there is no license key, no usage cap, and no locked feature anywhere in this codebase.<\/p>\n\n This plugin does not connect to any external service. All processing (reading the export file, creating posts\/pages\/comments\/authors, custom field reconnection) happens entirely on your own WordPress site's server.<\/p>\n\n\n Yes - install and activate it on both the old (source) site and the new (destination) site. The source site builds the .wpmpx export file that the destination site then imports.<\/p><\/dd>\n The URLs referencing images in your migrated posts\/pages are kept exactly as they were on the old site - this plugin does not download or re-host image files. As long as the old site stays online, those images continue to display normally on the new site.<\/p><\/dd>\n No. Every feature in this plugin - export, import, comments, author linking, custom field\/ACF reconnection, dry-run preview, rollback - works with no count limit, no time limit, and no license key required.<\/p><\/dd>\n\n<\/dl>\n\n\n\n
What this plugin does<\/h4>\n\n
\n
Security notes<\/h4>\n\n
\n
<!DOCTYPE><\/code> declaration is stripped before parsing and external entity\/network loading is disabled) to prevent XXE-style attacks from a malicious export file.<\/li>\nis_uploaded_file()<\/code> and moved through the WordPress Filesystem API into a non-listable, non-executable private folder that is cleared automatically after each file is processed.<\/li>\n<\/ul>\n\nExternal services<\/h3>\n\n
\n
\n
Do I need to install this on the old site too?<\/h3><\/dt>\n
Will my images move too?<\/h3><\/dt>\n
Does this plugin have any limits on the number of posts, pages, or sites?<\/h3><\/dt>\n
3.0.6<\/h4>\n\n
\n
fwrite()<\/code> return values are now checked when writing the split .wpmpx export parts in WPMP_Exporter::finalize_job()<\/code>. A partial write is retried; if the disk genuinely can't be written to, the export aborts, deletes the partial part files, and returns a clear error instead of silently producing a truncated\/corrupted export archive.<\/li>\n$_POST['source_category']<\/code> \/ $_POST['category_name']<\/code> are now passed through sanitize_text_field()<\/code> before use in WPMP_Import_Admin<\/code> (category-start, rollback, and preview handlers), consistent with the rest of the plugin's input handling.<\/li>\nN<\/code> format code (two halves) instead of the 64-bit J<\/code>\/P<\/code> codes, to remove any ambiguity about byte order for future readers\/reviewers. Output bytes are unchanged, so this is fully compatible with .wpmpx files created by earlier 3.0.x versions.<\/li>\n<\/ul>\n\n3.0.5<\/h4>\n\n
\n
WPMP_Importer::process_attachment_batch()<\/code> passes its $global<\/code> state (the URL-rewrite map and the old-attachment-ID \u2192 new-attachment-ID map) into apply_filters( 'lux_content_migration_process_attachment_batch', ... )<\/code> - but PHP\/WordPress break by-reference passing across apply_filters()<\/code>, so the add-on's own callback (which correctly re-reads and re-saves this state on every batch) was having its save immediately overwritten by this plugin's own caller, which was still holding - and re-saving - the state exactly as it was before<\/em> that batch ran. This happened on every single batch tick, so the URL map and attachment-ID map could never actually accumulate any entries, no matter how many images the add-on successfully rehosted. Fixed by re-reading the freshly-saved state back into this function's reference parameter immediately after a filter callback reports it handled the batch, so this plugin's own follow-up save can no longer clobber it. Free-plugin-only fix - no change needed on the add-on side, and no change for anyone running the free plugin standalone (which never populates this state in the first place).<\/li>\n<\/ul>\n\n3.0.4<\/h4>\n\n
\n
ajax_export_start()<\/code> AJAX handler unconditionally rejected any request that button sent (embed_files: 1<\/code>), regardless of whether the paid add-on was installed or licensed - so that button never actually worked for anyone, including fully-licensed paying customers of the add-on. It's been removed, and the underlying handler now asks the add-on (via a new filter, lux_content_migration_embed_files_available<\/code>) whether the request should be allowed before rejecting it - the same request that used to always fail now succeeds when the add-on is present and licensed for full access.<\/li>\nlux_content_migration_render_embed_files_option<\/code> action, lux_content_migration_set_embed_files_preference<\/code> action to persist the choice) - otherwise this plugin shows a \"log in to your license\" or \"learn about the Pro add-on\" link depending on whether the add-on is installed at all (reusing the lux_content_migration_pro_addon_installed<\/code>\/lux_content_migration_pro_settings_url<\/code> filters from 3.0.2).<\/li>\nrender_screen_switcher()<\/code> now also shows a \"\uc790\ub3d9 \ub9ac\ub514\ub809\ud2b8 \ucd94\ucc9c\" (automatic redirect suggestions) pill on the destination-site role, linking to the same redirect-management screen the source role already links to - the add-on renders different content there depending on which role visits it. Previously this cross-screen link only appeared for the source role.<\/li>\n<\/ul>\n\n3.0.3<\/h4>\n\n
\n
3.0.2<\/h4>\n\n
\n
lux_content_migration_pro_addon_installed<\/code> and lux_content_migration_pro_settings_url<\/code> (both default to false\/empty when no add-on is present, so standalone use of this free plugin is unaffected), and when an add-on is detected, shows a direct link to its actual license\/settings screen instead of the promotional copy.<\/li>\n<\/ul>\n\n3.0.0<\/h4>\n\n
\n
lux_content_migration_is_pro<\/code>, lux_content_migration_process_attachment_batch<\/code>, lux_content_migration_embed_attachment_file<\/code>, lux_content_migration_export_embed_item<\/code>, lux_content_migration_post_imported<\/code>, lux_content_migration_retry_failed_attachment<\/code>, lux_content_migration_render_admin_notices<\/code>, lux_content_migration_role_saved<\/code>, lux_content_migration_deactivate<\/code>, lux_content_migration_reset_all<\/code>, lux_content_migration_pro_addon_installed<\/code>, lux_content_migration_pro_settings_url<\/code>, lux_content_migration_embed_files_available<\/code>, lux_content_migration_render_embed_files_option<\/code>, lux_content_migration_set_embed_files_preference<\/code>) - the same extensibility pattern used by other WordPress.org-hosted freemium plugins for their paid add-ons.<\/li>\n.po<\/code>\/.mo<\/code> files and the load_plugin_textdomain()<\/code> call - translations for WordPress.org-hosted plugins are handled automatically via translate.wordpress.org since WordPress 4.6.<\/li>\nsanitize_file_name()<\/code> bug, already fixed separately).<\/li>\n<\/ul>\n\n3.0.1<\/h4>\n\n
\n
WPMP_Store::reset_all()<\/code> still called WPMP_Importer::disable_background_mode()<\/code>, a method that had already been deleted from WPMP_Importer<\/code> when background processing moved to the Pro add-on. Replaced with a lux_content_migration_reset_all<\/code> action so a Pro add-on can clean up its own background-processing state on reset, without the free plugin needing to know anything about it.<\/li>\nembed_files<\/code> as false: the value returned by the lux_content_migration_export_embed_item<\/code> filter was computed per-batch but never written back onto the persisted export job, so finalize_job()<\/code> could never see it. A Pro add-on embedding attachment bytes into the export file is now correctly reflected in the finished manifest.<\/li>\nuninstall.php<\/code>: it still dropped the wp_redirects<\/code>\/wp_redirect_404_log<\/code> database tables and deleted license\/redirect\/usage-limit options left over from the removed features. This plugin no longer creates any of that data (it belongs to the separate Pro add-on now), so uninstalling this plugin no longer touches it - each plugin only cleans up what it actually created.<\/li>\n<\/ul>\n\n2.8.2<\/h4>\n\n
\n
wp-content-migration.php<\/code>) instead of the current one (lux-content-migration.php<\/code>) - harmless (comments aren't executed), but corrected for accuracy.<\/li>\n<\/ul>\n\n2.8.1<\/h4>\n\n
\n
move_uploaded_file()<\/code> (a forbidden direct filesystem function) with the WP_Filesystem API's move()<\/code> method for handling uploaded .wpmpx files - the is_uploaded_file()<\/code> security check that verifies the file genuinely came from this request's upload is kept in place, since WP_Filesystem doesn't perform that check itself. Also updated \"Tested up to\" from 7.0 to 7.1 (current WordPress release).<\/li>\n<\/ul>\n\n2.7.3<\/h4>\n\n
\n
Contributors<\/code> in readme.txt was set to luxdigest<\/code> (the display name) instead of the actual WordPress.org login username (luxsnap<\/code>) - required to match the account submitting this plugin for review.<\/li>\n<\/ul>\n\n2.7.2<\/h4>\n\n
\n
2.7.1<\/h4>\n\n
\n
2.7.0<\/h4>\n\n
\n
languages\/wp-content-migration-en_US.po<\/code>\/.mo<\/code>) covering all 407 translatable strings in the plugin - on an English-locale WordPress install, every screen now displays in English instead of the Korean source text, which matters for WordPress.org review (typically done on an English test site) and for this plugin's primarily English-speaking market. The Korean source strings in the code itself are unchanged - this is purely an additional translation layer, loaded automatically by WordPress via load_plugin_textdomain()<\/code> based on the site's locale. Verified the compiled .mo<\/code> file parses correctly with Python's own gettext<\/code> module before shipping.<\/li>\n<\/ul>\n\n2.6.8<\/h4>\n\n
\n
wp-media-porter<\/code> throughout the codebase (plugin header, load_plugin_textdomain()<\/code>, and all 477 translation function calls) even though the plugin was renamed to wp-content-migration<\/code> back in 2.1.0 - WordPress.org requires the text domain to exactly match the plugin slug, and a mismatch here would fail automated review. Corrected everywhere.<\/li>\nwp-media-porter-*.mo\/.po\/.pot<\/code> translation files - they referenced the old (now wrong) text domain and, being from before roughly half of this plugin's current screens existed, covered only a fraction of today's actual strings. Regenerated languages\/wp-content-migration.pot<\/code> from scratch against the current codebase (407 unique translatable strings) using a custom extractor built for this session (no gettext toolchain was available to run wp i18n make-pot<\/code>). Translated .po<\/code>\/.mo<\/code> files for specific languages (en_US, ja, etc.) are not included - see the note below.<\/li>\n<\/ul>\n\n2.6.7<\/h4>\n\n
\n
2.6.6<\/h4>\n\n
\n
2.6.5<\/h4>\n\n
\n
2.6.4<\/h4>\n\n
\n
2.6.3<\/h4>\n\n
\n
2.6.2<\/h4>\n\n
\n
2.6.1<\/h4>\n\n
\n
2.6.0<\/h4>\n\n
\n
collect_needed_attachments()<\/code> decided whether an image was \"needed\" by checking if the exact original attachment URL string appeared in post content. Since WordPress normally inserts a resized variant into content (not the original), this exact-match check failed for the majority of real in-content images - meaning they were never even queued for download in the first place, so there was nothing for the URL rewriter to work with regardless of how good it was. Detection now also matches by filename (independent of any resize suffix), and separately scans post content directly for src=<\/code>\/srcset=<\/code>\/Gutenberg-block image URLs pointing at any other host - including images that were never registered as a WordPress attachment on the source site at all - and queues those too as on-the-fly entries.<\/li>\nrewrite_urls()<\/code> to replace any old-host reference to a given filename (with or without a resize suffix) with the new site's plain original URL, rather than trying to reconstruct a matching resize suffix on the new site (which may not exist). Guarantees a working image over a possibly-broken exact-size match.<\/li>\n<\/ul>\n\n2.5.2<\/h4>\n\n
\n
rewrite_urls()<\/code> only replaced post content URLs that matched an attachment's original URL exactly<\/em>. But WordPress normally inserts a resized variant into post content when you add an image via the editor (e.g. photo-300x200.jpg<\/code> for \"Medium\" size), not the raw original filename - so the one case this whole feature exists for (images actually appearing in post content) was frequently left pointing at the old site, while only exact-match references (like a featured image, which does store the original URL) got rewritten correctly. Added a second pass that recognizes the filename-WxHeight.ext<\/code> resize pattern and rewrites it to the same size suffix on the new site's uploaded copy (WordPress regenerates the same intermediate sizes automatically on upload, so this size normally exists). The existing srcset-stripping safety net still runs afterward for anything neither pass caught.<\/li>\n<\/ul>\n\n2.5.1<\/h4>\n\n
\n
NEWS-LUX-...-074327.wpmpx.part1of2<\/code> becomes part1of2-NEWS-LUX-...-074327.wpmpx<\/code>. The old suffix placement buried the only thing that differs between parts at the very end of an already-long, mostly-identical filename, making multiple parts hard to tell apart at a glance in a file picker or folder view. The import side still recognizes both the new prefix format and the old suffix format, so parts already exported with an earlier version can still be uploaded.<\/li>\n<\/ul>\n\n2.5.0<\/h4>\n\n
\n
2.4.1<\/h4>\n\n
\n
2.4.0<\/h4>\n\n
\n
.wpmpx<\/code> built from \"\uae00 \uc120\ud0dd\" or any export containing uncategorized posts had no way to import them. They now get their own \"\ubbf8\ubd84\ub958 \uae00 \uac00\uc838\uc624\uae30\" section, importable as one flat batch like pages already were.<\/li>\n2.3.0<\/h4>\n\n
\n
export_only<\/code>, requiring a manual \"\uc815\uc2dd \uc804\ud658\" click before Redirect Manager would ever unlock - but the product itself is sold as a pair (source + destination both become full on a single-tier purchase; see the matching marketplace fix). The default requested role is now full<\/code> for both site roles - entering a valid key activates both sites automatically, no separate step. A source site that already has an export_only<\/code> success recorded from an earlier version still needs one manual \"\uc815\uc2dd \uc804\ud658\" click to move off that recorded state, after which this no longer applies.<\/li>\ndecoblocks-marketplace<\/code> 5.6.0 changes SINGLE_MAX_ACTIVATIONS<\/code> from 1 to 2 to actually grant both slots on a single-tier purchase - this client-side default alone does nothing without that.<\/li>\n<\/ul>\n\n2.2.4<\/h4>\n\n
\n
sanitize_file_name()<\/code> a second time. WordPress's own filename sanitizer inserts an underscore when it sees a multi-dot name with an unrecognized \"middle extension\" (exactly what name.wpmpx.part1of2<\/code> looks like to it) as a defense against extension-spoofing attacks - so the requested filename silently became name.wpmpx_.part1of2<\/code>, which never matched the real file. The actual security boundary here is the whitelist check against the export manifest (already present), not sanitization, so the redundant second pass was removed entirely.<\/li>\n2.2.3<\/h4>\n\n
\n
2.2.2<\/h4>\n\n
\n
check_admin_referer()<\/code>) - if it didn't match for any reason, WordPress shows its own generic \"\ub2e4\uc2dc \uc2dc\ub3c4\ud574\uc8fc\uc138\uc694\" page completely unrelated to this plugin, which just looked like \"clicking gives an error.\" Removed the nonce requirement for this action (capability check alone still protects it - it's a read-only download of the admin's own data), eliminating this failure mode outright. The three distinct failure cases inside stream_part()<\/code> (no manifest, filename not recognized, file missing from disk) also no longer share one generic message - each now states exactly what it found, so a future failure is diagnosable from the screen alone.<\/li>\n<\/ul>\n\n2.2.1<\/h4>\n\n
\n
2.2.0<\/h4>\n\n
\n
update_option()<\/code> - the same class of bug already fixed once for get_site_role()<\/code>. It turned out 13 other option reads across the plugin had the identical exposure, including the two most consequential ones: WPMP_License::get_key()<\/code>\/get_state()<\/code> (the single source of truth for every \"is this license valid\" check in the plugin, so a stale read here could make a freshly-verified license look invalid on the very next screen, e.g. Redirect Manager) and WPMP_Exporter::get_manifest()<\/code> (read by the hidden download iframe moments after the export job finishes - a stale \"no export found\" read meant the download silently never happened, even though the UI showed a completion message). Rather than patching each call site individually, added one shared wpmp_get_option_fresh()<\/code> helper (cache-bypassing get_option()<\/code>) and moved every one of this plugin's own option reads through it.<\/li>\n2.1.1<\/h4>\n\n
\n
API_BASE<\/code> constant, Plugin URI). This is the address this plugin contacts to verify a license key - see \"External services\" above.<\/li>\n<\/ul>\n\n2.1.0<\/h4>\n\n
\n