Landing Page Manager v1.0.16

Changed

• The required-fields notice stays until the fields are filled in, instead of disappearing after a minute. It names each field with its label and the tab it is on. While a draft is being built it is a reminder; after a refused publish or schedule it is an error; on a live page it says the page stays published.
• Scheduling an incomplete landing page keeps it as a draft, as publishing already did. Previously the check ran only when the scheduled time came.
• The Landing Pages list names pages that were kept as drafts, for example after Quick Edit, bulk edit or a scheduled publish, with a link to each.
• Editors see "Landing page published", "Landing page draft updated" and so on, instead of WordPress's generic "Post …" messages.
• Previews open on the main site, where you are logged in, for drafts and published pages alike. Previews on a client subdomain didn't work on most sites, because login cookies don't reach subdomains: a published page's preview showed the live page or "Sorry, you are not allowed to preview drafts", and a new draft's preview went to a broken address.
• A landing page opens only on its own client's subdomain. Its address on another client's subdomain, on the main domain, on www. or on a subdomain that is no client's (for example after a client's slug was renamed) redirects to the page's own address, keeping the query string so ad tracking survives. Before, those addresses showed the page. On the main domain this happens only where WordPress has nothing at that address, so its own pages, posts, feeds and sitemaps still win. A link through ?p= or ?landing_page= on another client's subdomain shows the not-found page.
• API keys are shown as dots (password fields) on Settings → API Keys, and password managers are asked not to fill them. Each field's help says which saved key it holds (its last four characters). To change a key, clear the field and paste the new one. The keys are hidden on screen; they are stored as before.
• Client colors: when Brandfetch has no colors for the client's domain, or no Brandfetch key is saved, new clients get colors from their logo instead of the generic blue and red. Existing clients keep their saved colors; to pick up logo colors, clear Primary and Secondary color and update the client. Brandfetch answers are reused for a week per domain.
• Client addresses are looked up again only when the client's name or address changes. Saving a client for any other reason no longer makes three Google calls.
• Saved map coordinates are refreshed every 28 days. Google Maps Platform terms limit how long latitude and longitude from the Places API may be cached (30 days at the time of writing); the place ID may be kept. A daily background task refreshes older coordinates from the saved place ID, using about one billed Place Details request per client per month on the Google Maps server key. If a refresh fails and the coordinates are past 30 days, they are deleted and retried for three days. Uninstalling the plugin always deletes them. While the plugin is deactivated they aren't refreshed; within a day of reactivation they are refreshed or deleted.

Fixed

• Most errors in a template's fields file no longer take down wp-admin. Administrators see a notice that names the template and the error. (A few fatal errors, such as a function declared twice, can't be caught.)
• A new draft's View and Preview links no longer point to https://<client>.<domain>//.

Security

• Only hosts that end in . plus the site's domain, and whose subdomain is a client's slug, are treated as client subdomains (previously, for example, evilexample.com counted as a subdomain of example.com). The client can no longer be chosen with a URL parameter.
• The plain-text copies of the Google and Brandfetch keys that each Settings save kept in the carbon_fields_theme_options_container option are deleted.
• Brandfetch requests accept only a valid domain name, and are skipped when no Brandfetch key is saved.

Upgrade notes

• Sites on 1.0.13 or earlier: install this version once by hand. Their updater can't install updates (fixed in 1.0.14). Download landing-page-manager.zip from the 1.0.16 release (not "Source code (zip)"), then go to Plugins → Add New Plugin → Upload Plugin, choose the file, and select Replace current with uploaded. Sites on 1.0.14 or later update normally.
• Each landing page now opens only on its own client's subdomain. Links on another subdomain or the main domain redirect to it, so update ads and QR codes to the page's own address when you can, and check the Client column on Landing Pages (a page with no client redirects to its main-site address, /landing-page/<slug>/). Then purge your page cache: cached copies keep serving the old addresses until it is cleared.
• Check the Google Maps server key before updating. Within a day of updating (20 clients per run, with more runs scheduled until all are done), each client's saved latitude and longitude are refreshed from Google with that key. If that fails, for example because no key is saved or the key doesn't allow the original Places API, the coordinates are deleted and maps that need them stop showing. Afterwards, open a client and check Latitude and Longitude; if they're empty, fix the key and save the client.
• Live landing pages with empty required fields now show the required-fields notice in the editor each time. The page stays published.
• If Settings → API Keys was open during the update, reload it before saving. Saving the old tab is safe (the stored keys are kept), but it won't show the new password fields.

Rollback

• If you go back to 1.0.15, re-enter the Google Maps browser key and the Brandfetch key before saving Settings. 1.0.15 masks those fields and restores them from plain-text copies that this version deletes, so its first Settings save would clear them.

Landing Page Manager v1.0.15

Fixed

• A new landing page no longer opens with "Missing required fields". The warning appeared on the blank Add New form, before anything was typed. It still appears when you save or publish a page with required fields missing, and an incomplete page still stays a draft when you publish it.

Changed

• The copyright and author lines in the plugin's files and LICENSE name Duppins Technology.

Upgrade notes

• Sites on 1.0.13 or earlier: install this version once by hand. Their updater can't install updates (fixed in 1.0.14). Download landing-page-manager.zip from the 1.0.15 release (not "Source code (zip)"), then go to Plugins → Add New Plugin → Upload Plugin, choose the file, and select Replace current with uploaded. Sites on 1.0.14 update normally.

Landing Page Manager v1.0.14

Fixed

• "Update now" works again. Since 1.0.6, every update failed with "A directory could not be read" and the site stayed on its old version: the updater deleted the downloaded update because its folder was already named landing-page-manager (as every release zip is). If a downloaded update can't be moved into place, the update now stops with an error instead of installing into a misnamed folder.

Upgrade notes

• Sites on 1.0.13 or earlier: install 1.0.14 once by hand. Download landing-page-manager.zip from the 1.0.14 release (not "Source code (zip)"), then go to Plugins → Add New Plugin → Upload Plugin, choose the file, and select Replace current with uploaded. Later updates install normally.
• This also brings the 1.0.13 changes, including its security fix, to sites that couldn't update to 1.0.13.

Landing Page Manager v1.0.13

Added

• Tracking menu item under Landing Pages. With Landing Page Manager Pro 1.0.6 or later it holds Pro's tracking settings (what is tracked, whose visits are counted, consent). Without Pro it explains how to get conversion tracking.
• For developers: lpmanager_pro_screen_slots() names the Analytics and Tracking screens, and the lpmanager_render_analytics_page and lpmanager_render_tracking_page actions render them. Anything hooking these actions must check the user's capabilities itself.

Changed

• Analytics come from Landing Page Manager Pro. The Analytics screen's dashboard (summary, charts and report tabs) now ships with Pro 1.0.6, which also adds a detail view for each landing page. Without Pro, Analytics explains how to get it, with a Get Pro button. With a Pro version before 1.0.6, Analytics and Tracking say where those features are until Pro is updated.

Removed

• The Conversion Tracking (Pro) Settings tab, replaced by the Tracking menu item. (Sites running Pro before 1.0.4 still see their tracking options there.)
• The analytics dashboard's script and styles, which now ship with Pro, including an unversioned copy of Chart.js loaded from a CDN.
• The Pro banner on the other Landing Pages screens now says Get Pro, like the Analytics and Tracking screens, instead of "coming soon, contact for early access". It no longer appears on Analytics and Tracking, which carry their own Pro message.

Security

• Removing the analytics dashboard script also removes a cross-site scripting issue in it: a landing page title containing quotes, written by a user who can publish landing pages, could run script on an administrator's Analytics screen. Pro 1.0.6 ships the dashboard with the fix.

Upgrade notes

• Update Landing Page Manager Pro to 1.0.6 at the same time. With Pro 1.0.5 or earlier, the Analytics screen no longer shows charts: Analytics and Tracking say where Pro keeps those features until Pro is updated.

Landing Page Manager v1.0.12

Removed

• The one-time step from 1.0.10 that saved the previous default template for sites that had never saved the template setting. Every site that needed it has run it. A site updating straight from 1.0.9 or earlier without having saved the setting starts on Starter One.

Landing Page Manager v1.0.10

Added

• Two starter templates, Starter One (light) and Starter Two (dark). They ship with the plugin, appear first under Settings → Templates, and are the default for new sites. Each has a hero with a call button, highlights, about, FAQ and contact sections, and uses the client's logo, colors and phone number, with text colors chosen so any brand color stays readable. They load no external fonts, icons or scripts. Copy one to build your own template.

Changed

• Uploaded and custom templates are kept outside the plugin folder, in wp-content/lpmanager-templates/, so plugin updates no longer delete them. You can also copy a template folder there yourself.
• Templates still inside the plugin folder are copied there automatically (Template A, Template B, Template C, and any template you uploaded earlier), shortly after updating or when an administrator next opens an admin page. While any template is still only inside the plugin folder, an admin notice names it and updating the plugin is blocked, including uploading a plugin ZIP over it, so the next update can't delete it.
• The template tiles list the starter templates first, then other templates by name, then Upload New Template.
• The notice for a missing template now says where to put it, and the in-plugin Help no longer says that updates remove uploaded templates.
• The suggested privacy-policy text now says that some landing page designs load Google Fonts and cdnjs: the starter templates don't.

Upgrade notes

• Template A, Template B and Template C will be removed from the plugin in the next release. This update copies them to wp-content/lpmanager-templates/, and your landing pages keep using them. Update to this version before any later one, open Landing Pages → Settings, and check that no template notice appears.
• Sites that never saved the template setting stay on Template B, the previous default. New sites start with Starter One.
• Back-ups and staging-to-live copies must now include wp-content/lpmanager-templates/. Uninstalling the plugin keeps that folder.
• Sites that deploy the plugin without the WordPress updater (DISALLOW_FILE_MODS, Composer or Git): copy template_a, template-b and template-c (and any template you uploaded) from the plugin's includes/templates/ to wp-content/lpmanager-templates/ yourself before deploying the next version. The admin notice reminds you.
• If the copy can't run (for example, WordPress can't write to wp-content), automatic updates of this plugin fail, and WordPress emails a failure notice each time it retries, until the copy succeeds or you copy the folders yourself. Your pages keep working meanwhile.
• Rolling back to 1.0.9 keeps the client templates working, but 1.0.9 can't see wp-content/lpmanager-templates/ or the starter templates: pages that use a starter or a template uploaded in 1.0.10 show a 404 until you update again.