| Feature | Summary |
| Admin > Global Login — website logout now completes SAML Single Logout so SSO users are fully signed out | For sites using a SAML identity provider (configured under Admin > Global Login) with Single Logout enabled, clicking Logout on the website now signs the user out of the identity provider as well as Centralpoint. Previously the sign-out request to the provider could be dropped during the logout redirect, so the provider session stayed active — a user who clicked Logout and then clicked the SSO sign-in button again was let straight back in with no prompt for credentials. The sign-out request is now preserved and sent to the provider, so returning to the site requires signing in again.
Sites that do not use SAML, or that have Single Logout turned off, are unaffected — their logout behaves exactly as before. |
| Mail & Calendar - a mail account that stops working now tells the user why, instead of disappearing from the list | The Mail, Contacts, Calendars module now explains why a configured account failed instead of reporting a generic connection failure. Where the module previously said only " failed to connect", it now states the actual cause: an Office 365 authorization that has been cleared or revoked asks the user to reauthorize and reminds them to do it from the site's normal web address rather than an IP address or internal server name; an authorization missing a required permission names the permission that needs consent; and an unreachable Exchange, IMAP or Template account asks the user to check its configuration. The prompt still offers to open that account's settings, and now opens the correct one when several accounts are configured.
A broken account no longer disappears from the list. Previously, when a member had more than one account and had not explicitly selected one, any account that failed its check was dropped before the view was rendered. That produced two wrong messages. With every account broken, the module reported "You must add at least one active mail service before viewing your mail" and switched to Settings, telling the member to add an account they already had. With a working calendar-only account beside a broken mail account, it did the same thing, and the broken account was never mentioned. Accounts that fail their check now stay in the list and report their reason on the view they serve, so a mail failure is reported on Mail and stays silent on Calendars.
Pages that list messages through a data source now show the reason inline instead of returning an empty message list with no explanation.
The account list in the module's Settings view now checks each account as it loads, so the "(invalid)" indicator reflects the account's real state on every visit rather than only the first one after a failure. Because of this, the settings list contacts each configured account when it binds and may take a moment longer to appear for a member with several accounts.
|
| My Logs - member health logs, charts and record edits are now scoped to the signed-in member (security) | Health log charts previously scoped their records to the owner of the requested chart rather than to the signed-in member, so a chart address carrying another member's chart id returned that member's health log records. The MyLogs module now resolves records from the signed-in member in every case, and that scope is applied by the module itself rather than by each individual view, so no view can leave it out.
Ownership is now verified on every My Logs entry point that reads or changes log data:
- Charts refuse a chart belonging to another member instead of rendering it.
- The log form view refuses another member's log rather than displaying its title.
- Record entry verifies both the log and each record being edited before anything is written, so a partly saved form is no longer possible.
- Log deletion verifies ownership before removing a log or its records. A deletion request carrying another member's log id previously removed that member's log while leaving their records behind.
A behavior change worth noting: administrators no longer reach another member's health logs through these pages. Access is now strictly the signed-in member's own data. Any workflow that depended on a provider or an administrator opening a member's chart should be raised as a separate request.
Three related fixes ship alongside:
- The Delete This Log? link now works from the chart views. It previously issued its request and silently did nothing, which read as a broken feature.
- The chart on the standalone chart page now renders. Its drawing area was being replaced before the chart was drawn, so that page never displayed a chart.
- The chart date range is now validated before it is applied. An empty or non-date entry previously produced either a blank chart with no explanation or an unhandled error. Invalid entries are now reported next to the button and kept on screen for correction.
|
| Data Broadcasts - images with spaces or special characters in the filename now display in delivered emails | When a Data Broadcast is sent with Embed HTML Images set to Yes, an image whose filename contains a space or other special character (for example ericsson email photo.png) was not appearing in the delivered email — recipients saw a broken image. The image reference was being corrupted while the message was assembled for sending. This is fixed: images with spaces or special characters in their filenames now embed and display correctly, the same as plain-named images. As part of the fix, image embedding also confirms each image resolves to a file inside the site's Uploads or module image folders before attaching it. |
| Site Architecture > Search Page Designer - new tool for building additional advanced search pages | A new tool is available at Site Architecture > Search Page Designer. The advanced search page has always rendered one fixed structure, so any change to how it is laid out had to go through development. Administrators can now create additional search pages and control their markup, styles and scripts directly.
Each page is built from four fields: Page markup, Styles, Inline scripts, and a Custom binder script that applies when JavaScript File is set to Custom. A new record opens pre-filled with the standard search page markup, so every page starts from a working layout and is edited from there. Controls can be reordered, rewrapped, restyled or hidden, but not removed. A check on save refuses markup that has dropped a required control and names exactly which ones are missing.
A page is published by pointing a Site Map record with a page type of Url at the path shown at the top of the editor, which carries a copy option. Existing audience and role security continues to apply, so there is no second set of permissions to manage. Version history keeps the last ten saves and any of them can be restored; restoring is itself recorded, so it can be undone.
These pages continue to leverage the configuration on the System Pages record's Search tab, for example the results header content, results item content, filter visibility options and the rail labels. Those settings resolve per audience and apply to every search page, so they stay managed in one place rather than in each page's Page markup.
The standard advanced search page is unchanged. |
| Admin > Properties - new Cross-Module Friendly URL Handling option | A new Cross-Module Friendly URL Handling option has been added to the site
properties under Admin > Properties. It controls what happens when a friendly
URL of the form /{audience}/{section}/{document} requests a document that
actually belongs to a different section than the one named in the URL.
Previously, the page would draw that foreign document inside the wrong section's
layout.
The option has three settings:
- Legacy (default) — no change from current behavior; the document renders
in place under the section named in the URL.- Canonical — the visitor is redirected to the document's own section, so it
displays under the correct layout.- Strict — the same redirect as Canonical, and additionally returns a Page
Not Found (404) for a document whose module has no public-facing section at all.
The default is Legacy, so no site changes behavior until an administrator
selects Canonical or Strict. |
| Data Transform > Data Transfer — the Users field-mapping script can now strip text before matching a user | In Data Transfer field mappings, the Users script (which matches an incoming value to a Centralpoint user, usually by IntegrationId) can now clean up that value before it looks for a match. It supports the currentSourceReplaceText and currentSourceReplaceWith attributes, the same find-and-replace step the Roles and Audiences scripts already perform.
This lets a mapping remove a stray prefix or suffix from a source value so it lines up with the stored user. Previously the Users script ignored those attributes, so a source value that did not match exactly returned nothing, the record's user could not be set, and the record was dropped, which could cancel a transfer once enough records failed. Mappings that do not use these attributes behave exactly as before. |
| Centralpoint 8.12.13 maintenance run #2 - source-editor fields keep their edits on a partial page refresh, plus sign-in, search, broadcast and scheduled-task fixes | Source editor keeps the latest edits. A source-editor field (JSON, SQL, HTML, CSS or JavaScript) could lose the most recent edits when part of the page refreshed before the record was saved - the previously stored value was submitted instead, with no error. The field now captures every change as it is typed, so a page that refreshes a section still saves what is on screen. A field holding plain text rather than encoded content is also accepted as-is instead of being stored as corrupted text. Affects the source editors on Tools > Actionable Select Command Builder and on the task properties under Master > Content > Scheduled Tasks.
Sign-in and account lockout.Admin > Global Login: a certificate problem during single log-out now names the Global Login source that failed and the certificate settings to check, instead of reporting a generic failure.- A locked-out account is no longer handed back to the requesting page in a signed-in state. The sign-out rebuilds the request identity, and self-request sign-outs redirect only from a page request.
Search. Contextual search no longer fails when a term resolves to no matching records. A search field configured without a column name now contributes no filter term instead of failing the whole search.
Broadcasts. On the unsubscribed-recipients grid under Broadcasts > Broadcasts, recipient names are now encoded, so a name containing markup characters displays correctly. A keyword search on that grid now keeps the grid's base filter instead of replacing it, so results stay scoped to the broadcast.
Policies and Procedures. Values passed into the approval pop-up are now encoded, so an approval link containing reserved characters no longer breaks.
Media Manager. The fourth upload control on Design > Media Manager now validates the file name before uploading, matching the other three.
Scheduled tasks and data transfers. A blocked or orphaned scheduled-task warning now names the task holding the lock, rather than only reporting that something held it. During a data transfer, an unresolved user is reported once per user instead of repeatedly, and the row that trips the relation-error limit is now identified in the status.
Module downloads. A file-output download link derives its address from the current request, so it resolves correctly behind alternate host names.
AI chat. A rejection from an AI provider is now reported as the provider's, with the matching remediation, instead of as a Centralpoint incident. The assembled system message is bounded to the model's prompt budget.
Audience selector. The console audience selector loads correctly when a user has to choose the current audience.
Master > Deployment > Web Sites. Administrative operations release impersonation reliably, including when the operation fails.
For custom code. A non-throwing check for whether a local user exists is now available, so custom code can test for a user without handling an exception.
Dependencies. Updated marked to 18.0.11, Microsoft.Extensions.Hosting.WindowsServices to 10.0.11 and AspNetCore.OpenApi to 10.0.11, and retired a direct Microsoft.OpenApi version pin. |
| AI Governance > AI Indexing - the attribute limit is now 100, failures explain themselves, and an attribute picker prevents typos | The Edit Configuration dialog under AI Governance > AI Indexing has been reworked. Three problems are fixed and four additions make the dialog explain itself before you commit a change.
- The
Source Attributes limit is raised from 25 to 100. Wide indexes that previously could not be saved at all now save. The stored field was also widened to hold a list that long, so a long list no longer fails on save. - A failure now says what went wrong. Both the preview and the save previously reported only a status number, which is why a rejected list and a permissions problem looked identical. The dialog now reports the actual reason, including the reason returned by the server.
- Both calls now have a time limit. A save on a large module used to appear to fail instantly; it now runs to completion and reports what it did.
- A rebuild that is interrupted can be resumed. Re-running the save finishes the remaining work instead of starting over.
- Values are checked before anything is sent. An empty or out-of-range
Chunk Size, Overlap, or Max Chunks/Record, and a list over the limit, are reported inline in the dialog. - New attribute picker. Browse this module's attributes lists every attribute defined on the module, prose fields first, and marks the ones that hold no text. Names that are not defined on the module are called out by name, including a name that is correct except for its capitalization - matching is exact, so
aidescription does not match AIDescription and would have indexed nothing. - The dialog estimates how much of each record is actually indexed, and the preview shows it measured per attribute: how often each one is filled, its size, the running total, and where the budget runs out. Attributes past that point are named as not reached, so a list that is longer than the budget allows is visible before saving rather than after.
- The preview states the exact impact - how many chunks and stored values the save will delete, how many records will be rebuilt, and roughly how long that takes. Records that exceed
Max Chunks/Record are now reported instead of being silently shortened.
|
| Master > Deployment > Updates - a long-running sync method no longer fails the install or skips the Development phase | Update installs run from Master > Deployment > Updates no longer fail when a sync method legitimately runs long. Previously the install stopped waiting after five minutes regardless of how much time the request actually had, and then reported that the web service was inaccessible - even when the service had answered and every method had completed successfully. Three things changed:
- The wait now derives from the request's own time budget rather than a fixed five minutes, so a sync method that needs longer is allowed to finish. Each phase is given a share of the remaining time, so the phase that follows still has time to run.
- The message now names what actually happened. A timeout, an unreachable address, and a server-side error read differently instead of sharing one wording. The message names the scope that failed rather than always saying "Master and Development", and the advice to check the web service address now appears only when the address really was unreachable. The remediation text no longer tells the operator to select "Pending" on
Master > Development > Sync Methods - there is no such filter on that page, and a method that has never run shows as New. - A slow Master phase no longer silently skips Development. When the Master scope times out, the install now still runs the Development scope, because a Master timeout says nothing about Development and minutes of install work run in between. It still skips Development when the address is unreachable or the server returned an error, and it now records a step on
Master > Development > Process Log naming the scope it skipped. Previously a skipped phase left no record at all.
An install that times out and then completes is also no longer reported as a failed run.
This fix cannot govern the install that delivers it. The affected code is loaded before an update's files are copied, so 8.12.13 is the first version to carry it and 8.12.14 is the first install it actually controls. Masters left with a skipped Development phase by an earlier version are corrected by re-running their sync methods from Master > Development > Sync Methods. |
| Master > Deployment > Updates - updates, deployments and config edits now survive an interrupted write | Several file-writing operations across Master and the client sites have been hardened so that an interrupted write - a process ending mid-save, a server restart, a full disk - can no longer leave a half-written file behind. Each of these files is now written to a temporary file first and swapped into place in a single step, so a reader either sees the previous version or the new one, never a partial one.
- Update file manifest.
Master > Deployment > Updates records which files an update replaced. If that record was interrupted while being written, the next update could read it as empty and treat every file as needing replacement. The record is now written whole or not at all. - Deployment backups. A deployment interrupted while writing its backup marker could afterwards be read as a completed backup. The next deployment then skipped taking a backup and began replacing files with nothing to roll back to. The marker can no longer be left in that state.
- Deployment packages. Replacing a deployment package on the server briefly removed the old file before the new one was in place. A site requesting it in that instant received a "not found". The swap is now a single step.
- Long installation paths. On installations whose folder path exceeds the Windows 260-character limit, saving settings, toggling application trace, and restarting an application all silently did nothing - the operation reported success without acting. These now work on long paths.
There is no change to any screen or option, and no change to the contents of any configuration file. The behaviour differs only when a write is interrupted, or on an installation with a long folder path.
|
| Admin > Properties - site map navigation is now filtered per user under Multi-tenant Audiences (security) | On sites where Web Site Audience Filtration & Security is set to Multi-tenant Audiences, the site map navigation was built once for an audience and then reused for everyone in it. The first signed-in non-administrator to load it fixed the tenant scoping for the rest of that audience until the site next restarted, so users holding different Tenants selections could be shown navigation items belonging to another tenant.
The navigation tree is now loaded for the audience as a whole, and each user's Tenants selections are applied as the site map renders. Every user sees only the items their own selections allow, and the shared tree stays reusable, so there is no added query cost per visitor.
What was exposed, and what was not. The items visible were navigation titles, links, tooltips and navigation groupings. The pages behind them were still permission-checked on every request, so no one could open a page they were not entitled to. Anonymous visitors and administrators inheriting from a parent site continue to use the default Tenants selections.
The Site Map module can no longer be entered in Web Site Audience Filtration & Security Modules, because it manages its own cache rather than the shared module cache. Both the help text on that section and the message shown when the module is entered have been corrected - the previous wording stated that the Site Map module itself was not supported, which is no longer the case. Tenant scoping does apply to navigation items; it is simply applied as the site map renders instead of by disabling the cache.
Sites left on Audiences (Default) are unaffected and follow the identical code path as before.
|
| Site-wide - seven page caches that never took effect now work, and member log edits appear immediately | Seven caches across the Development site read one storage key and wrote another, so none of them ever took effect. Each looked like it was caching, but the query underneath ran again on every page view. The affected areas are audience home pages, the ModuleContentTree and ModuleDragTree CpScripts, the TaxonomyProximitySearch CpControl, the page list on a multi-page PubArticles article, and member log records in MyLogs.
Those caches now work, which required correcting what sat underneath them:
- The two taxonomy tree CpScripts and the
TaxonomyProximitySearch CpControl now store their results per taxonomy root and per module. Widgets configured with different roots previously shared a single storage key, which would have served one widget's taxonomy to another as soon as the cache began holding anything. - The audience menu now builds its own filtered list on each request. It previously filtered a shared list in place, so two visitors in different audiences loading a page at the same moment could affect each other's menu.
- Deleting a member log, and saving a member log record, now update the log display immediately. Both write directly rather than through the console, so neither released the stored copy.
- The taxonomy trees now refresh when a taxonomy item is renamed or moved.
- The member log chart no longer stores its results. Its date range moves with the current date, so a stored copy was never reused; it now reads live on every request, and changing the date range always re-reads.
Pages using these features will run fewer repeated queries. Content that was always read fresh is now held for between 6 and 24 hours depending on the feature, and each one is released when the content it depends on changes. |
| Site-wide - API request limits are now tracked per caller, so agent traffic no longer locks operators out (Server Hub) | Fixed an issue where automated site check-in traffic could consume a shared request budget and cause the API to reject requests from signed-in operators with a 429 Too Many Requests error. The impact was most visible in the Server Hub: when many sites were checking in at once, operators could be blocked from issuing or retrying commands and from other write actions, even though the automated agents themselves kept working normally. The effect grew with the number of sites in the fleet.
Request budgets are now tracked separately per caller, so automated agent traffic no longer counts against a signed-in operator's limit. Each operator, each site, and anonymous callers get their own independent budget.
Separately, when a request limit is reached, the "try again in N seconds" message now reflects the correct time window. Previously a caller who hit an hourly limit was told to retry within seconds, causing repeated failed retries; the message now reports the actual wait for the window that was exceeded. |
| Site-wide - site navigation now loads once for every audience instead of once each, so a restart no longer stalls sites with many audiences | After an application restart - a scheduled recycle, an update, or a manual restart - a site rebuilt its navigation separately for every audience it has. Each rebuild ran its own database lookup and opened its own connection. On a site with a few hundred audiences that was enough to exhaust the available connections, and visitors saw errors on pages that had nothing to do with navigation for the first minute or two after the site came back.
Four changes address this, and all of them apply automatically with no configuration change:
- The navigation set is read once and shared. Every audience now builds its menu from a single lookup instead of running its own. The menus produced are unchanged; only the number of lookups changes.
- An audience with no published home page is recorded once. Previously that condition was re-checked in full on every visit, for the life of the application. It is now recorded the first time and skipped after that, until a home page is published or the navigation cache is cleared.
- Simultaneous first visits to the same audience share one lookup. Several visitors arriving at once no longer each open their own connection for the same audience.
- One audience's failure no longer affects the others. If a menu cannot finish building, only that audience is affected. Previously the site discarded every audience's menu, so every visitor had to wait for a rebuild - and the rebuilt links could come back in a non-standard form until the next restart.
The benefit scales with audience count. A site with one audience behaves exactly as before. |
| Site-wide - AI crawlers no longer count as visitors in recorded searches, leads, and clicks | Centralpoint decides whether a visitor is a crawler before it records a site search, a lead, or a link click. That decision previously came from a browser list built into the underlying web platform, which has not been updated since the current generation of AI crawlers appeared. It recognized older crawlers such as Googlebot and bingbot, but not ClaudeBot, GPTBot, PerplexityBot, Bytespider, ChatGPT-User, or Meta's crawler. On a site those agents visit, they were counted as visitors: their search terms were stored, and their page views and link clicks were recorded as leads and clicks. On one measured site, those newer agents accounted for over 98 percent of all crawler traffic.
All three of these places now use Centralpoint's own crawler list, which already governs Natural Language Search reporting and is maintained with each release. The affected areas are:
- Recorded search terms - stored only when
Admin > Properties > Search Criteria Recording is enabled. These feed popular-search and search-activity displays. - Leads - recorded only on navigation items with lead tracking turned on.
- Clicks - recorded through the click redirector, which has no separate setting and is therefore the broadest of the three.
Expect these numbers to go down. On a site that receives AI-crawler traffic, popular searches, lead counts, and click counts will fall once this release is applied, and the drop may be large. This is the correction working as intended - those entries were never real visitors - but a client tracking these figures month over month will see the change. Historical entries already recorded are left alone; only new traffic is affected. There is no per-site setting to return to the previous behavior, because the previous behavior did not recognize the crawlers causing the problem.
The crawler list also now recognizes Google's specialized crawlers - Googlebot-Image, Googlebot-News, Googlebot-Video, and Googlebot-Mobile - which the old platform list matched but Centralpoint's own list did not. |
| Site-wide - search terms are now encoded everywhere they are displayed, and blank stored entries are removed (security) | Search terms typed by visitors are recorded and then displayed back in several places. Every display location now encodes the term, so a term containing markup is shown as plain text instead of being treated as part of the page. This covers the SearchTermsCloud and ModuleTagCloud CpScripts, the tag cloud Data Source output format, the PopularSearches control, the Top Searches line on a module's console grid, and AI Governance > Search Suggestions.
Links built from a search term are also web-address encoded now, so a term containing & or other special characters produces one working link instead of a broken one.
Stored terms themselves are left exactly as the visitor typed them, so search reporting stays accurate. A one-time cleanup that runs with this sync removes stored entries that hold no search text at all - entries that are blank or contain only markup. Any entry with real text is left untouched, and everything removed is written to a backup file first.
For terms that contained no markup the display is unchanged. Only a term that contained markup or special characters looks different, and it now reads as the text the visitor actually typed. |
| Master > Development > Sync Methods - the Master API address is no longer overwritten from a stale setting, and an unreachable one can now be repaired | Two changes to how the Master's own API address is maintained under Master > Admin > Settings.
The 8.12.8 sync method that ensures Api.Base.Url derived its value from UpdateInstall.SyncInvokeMethods. The installer writes that second setting once, so on an install whose domain has since been renamed it names a host that no longer answers. The method treated it as authoritative and replaced a working Api.Base.Url with the retired host. The Centralpoint Agent reads Api.Base.Url to reach the Master, so from that point it could no longer run sync methods there, while scheduled tasks kept working. This was observed on an install running 8.12.12.
That method now leaves a populated Api.Base.Url alone on a Master, and only fills it in when it is missing, which was its original purpose. Web site behavior is unchanged.
A new Master sync method in this version repairs an install already affected. It first checks whether the configured address answers. If it does, nothing changes. If it does not, it takes the address that carried the request, confirms that address answers, and only then writes it to Api.Base.Url and corrects UpdateInstall.SyncInvokeMethods to match. It cannot write an address it has not proven, so it can never install a second unreachable host. Where appSettings is protected, it reports that and makes no change, so set Protected to no under Master > Admin > Settings first.
web.config change: on a Master whose configured address does not answer, this version writes two appSettings values in the Master's own Root web.config, Api.Base.Url and UpdateInstall.SyncInvokeMethods, and backs the file up to Backups\Web.Config first. No web site or Console web.config is touched, and no binding redirects, handlers or modules change, so a virtual directory running as its own IIS application needs no matching edit. On a Master whose address already answers, nothing is written. |
| Centralpoint 8.12.13 maintenance run #1 - Master tools now report a failed operation as failed, console navigation recovers from an interrupted build, and sign-in, search and link hardening | This is the roll-up note for the 2026-08-20 maintenance cycle. Nothing below changes how a feature is used; each item removes a case where the product reported the wrong outcome, stopped early, or exposed something it should not.
Master > Development > Utilities - a failed operation is now reported as failed. SQL Non-Query and Database Maintenance recorded a failure against the site that failed but still finished with a "Completed" status, so a statement or a maintenance pass that failed on every selected site reported success. Both now report the failure and point to the Process Log for the detail. This extends the same correction already made for Master > Deployment > Web Sites in this cycle.
Master > Development > Utilities and Master > Deployment > Web Sites - a failure is recorded against the right run. When one of these tools failed, the failure could be written against an empty process entry rather than the run that was actually going, leaving the real entry open with no end time. Nine tools were affected, including the nightly Clean Up. The Process Log now shows the failure on the run it belongs to.
Master > Content > Scheduled Tasks - clearer warnings. A late-task warning now states how late the task is, and a sync method that was interrupted mid-run is now named in the warning instead of being reported anonymously.
Master > Development > Process Log - historical entries are no longer re-reported. Long-idle orphaned entries that predate the current cycle are marked and set aside rather than reported again on every sweep.
Console navigation - an interrupted build no longer leaves navigation incomplete. If building the navigation tree was interrupted, the partial tree could be served until the application restarted. The build is now discarded on interruption and rebuilt on the next request. Console pages also no longer error when a navigation item's module is missing; the page loads with that item's settings empty.
Admin > Global Login - a certificate problem is now reported as configuration. A certificate that is missing, expired, or whose password does not match is now reported as a configuration issue naming the Global Login record to correct, rather than as a generic error.
AI Governance > NLS Configuration - provider errors no longer include the API key. Errors raised while connecting to Algolia or Amazon Kendra included the configured API key in the message text, which then appeared wherever the error was recorded. The key is no longer included.
Reporting - report errors now name the cause. A report whose Select Command returns a column the grid cannot display now names that column instead of failing with a framework error, and a command that returns no rows at all now says so directly.
Result grids - the All Attributes search field is matched regardless of casing. Where the All Attributes field was selected with different capitalisation than expected, attribute-mapped columns came back empty and the underlying attribute data was included in the response. Both are corrected.
Console links and post-sign-in returns - hardening. External link and embedded-page destinations are now taken from the configured navigation item rather than from the address bar, and every post-sign-in return address is validated against one shared rule instead of three separate copies of it. A return address whose own query string contains a full web address continues to work.
Data updates - one unreadable file no longer stops the rest. A single file that could not be copied ended the whole data update; the remaining files are now processed and the skipped files are reported together at the end.
|
| Tools > Resource Access Diagnostic - new tool to diagnose why a resource will or will not open | Changes Made:
A new Resource Access Diagnostic tool has been added under Tools > Resource Access Diagnostic. It helps determine why a document or file will or will not open for a user. Enter a ResourceId, a resource System Name, or a full /Resource.ashx link, and the tool reports in one screen: whether the resource record exists, whether its file is present on the server, whether the resource is enabled, and whether the current user (or another user you name) meets the role requirements. It ends with a plain Yes/No result. It runs the same checks the file viewer performs, so it answers "why won't this preview or download?" without needing direct server access. An optional Check as user field lets you test another user's access; if a username is shared by more than one account it asks for the UserId instead. |
| Site-wide - result pages that preview a lookup value now load it once per page instead of once per row | A Results View that displays a value from another module using the Column script with Preview enabled previously ran a separate lookup for every row on the page. On a large lookup list this could mean a couple of hundred database round trips to draw a single page of results, which showed up as a slow page and, on the largest lists, a timeout.
Those lookups are now resolved once for the whole page before the results are drawn. The values displayed are unchanged; only the number of lookups changes.
This applies automatically with no configuration change, and no Module Designer setting needs to be turned on. It covers preview columns that point at another module, an audience, a taxonomy, a navigation item, or a tiered selector. A preview column whose lookup list is narrowed by a filter is intentionally left on the previous behaviour, so those columns will not show the same improvement.
|
| Content > Events - recurring events set to December only now generate their occurrences | A recurring event configured to repeat monthly in December only produced no occurrences at all, and reported that no month had been selected even though December was selected. Any other single month, and any combination including a second month, worked normally. December-only recurrences now generate their occurrences as configured. |
| Master > Content > Scheduled Tasks - overdue and misconfigured monthly tasks no longer take the console offline | A scheduled task whose next run date had fallen a long way behind could take the Master console and all scheduled processing offline, recovering only until the next run and then failing again. Long-overdue tasks are now brought up to date without that failure, however far behind they are.
Two related corrections ship with it. A monthly task saved with no month selected previously ran at the wrong time; it now stops and reports the misconfiguration so it can be corrected. A task that cannot be scheduled at all now leaves its Next Run Date blank, shown as Never, instead of displaying a date in the year 9999 that made it look scheduled.
Alongside these, a failure to record a task's next run date is now reported rather than passing silently, so a task can no longer stop running with nothing in the error log to find it by.
|
| Site-wide - Document Viewer cache file hardening: previews are now keyed by file extension, so two files sharing a name no longer share a preview | Each converted document preview is now cached under the source file's full name, including its extension. Previously the extension was left off the cached preview's name, so two files sharing a base name in the same folder, such as Report.docx and Report.pdf in one Uploads folder, resolved to the same cached preview. Whichever document was viewed most recently was the one both of them then displayed, with no error shown and no reconversion. This affected the Word viewer, the Excel viewer, and the PDF preview behind the PdfViewer and FileViewer CpScripts. The PDF preview had the widest exposure, since it converts 22 different file types down to a single .pdf preview. Previews of files held as Resources were never affected, because each resource is already cached under its own unique id, and they keep their existing names.
Existing cached previews are kept, not discarded. The first time a document is viewed after the update, its existing cached preview is renamed to the new name in place, so it is not reconverted. Documents that are not viewed keep their old cached files until they are. Where two files genuinely shared a name, neither adopts the old preview: the previous name could not tell them apart, so each converts its own on its first view.
No preview cache folder should be cleared as part of this update. The rename above handles the transition on its own, one document at a time and only when that document is viewed. Emptying a Temp\AsposeWordViewer, Temp\AsposeExcelViewer or Temp\AsposeToPdf folder would instead force every document on the site to reconvert on its next view.
The cached file name has changed, which matters for the single-file clearing steps documented in the v8.12.12 Word Viewer note. A document at /Uploads/Policies/charter.docx is now cached at ...\Temp\AsposeWordViewer\Uploads\Policies\charter.docx.html, where it was previously charter.html. The same applies to the Excel viewer's .json files and the PDF preview's .pdf files. Clearing one problem document's cached file is still supported and is still the correct approach; only the file name to look for has changed.
A PDF carrying a static watermark now renders. Previously a PDF configured with a fixed watermark through the PdfViewer CpScript failed on every request and returned an error document, because the watermark step looked for a converted copy that was never produced for a source already in PDF form. Only PDFs were affected, and only with a fixed watermark. Every other format, and watermarks that insert the signed-in reader's own details, were unaffected. Such a document now renders with its watermark applied and caches normally.
Alongside this, the Excel viewer now writes its cached preview to a temporary file and swaps it into place only once it is complete, which is how the Word viewer has written its own since v8.12.11. An interruption partway through a conversion, such as the site restarting or the disk filling, previously left the Excel viewer with a truncated preview file stamped as newer than its source workbook, which was then served indefinitely until the workbook itself was re-saved. A write that cannot complete now leaves the previous cached preview untouched, reports the error in the viewer, records it in the error log so it can be traced, and converts again on the next view.
|
| Master > Development > Sync Methods - a server whose reporting stops during an update now restores it on its own | When an update replaced the Centralpoint Agent, the agent could restart correctly and continue running scheduled tasks while quietly stopping its check-ins to the central service. The server then looked completely healthy from the console - correct version, service running, scheduled work firing - while central reporting and remote commands were unavailable for it until someone restarted the service by hand on the server.
The agent now retries on its own and resumes reporting once the condition clears, so no manual restart is required. It also records why reporting stopped in its own log, rather than stopping silently, and no longer repeats the same message on every retry. |
| Master > Deployment > Updates - an update install no longer fails because the progress display was being read at the same moment | Installing an update from Master > Deployment > Updates could stop partway with a message about the file UpdateSteps.htm being in use by another process, even though nothing was wrong with the update itself. That file is the progress log the page reads to keep showing steps after the application restarts mid-install, and the page reading it could block the installer from writing to it. The installer and the progress display no longer contend for the file, and a progress write that cannot complete now leaves a note in the step list instead of ending the install. Retrying the install was the correct workaround and is no longer needed.
Two related improvements ship with it. The progress display is now confined to reading only the update progress file, and a page that requests anything else is refused. A failed progress write also no longer causes a successful install to be reported as failed. |
| Site-wide - a Data Source can no longer be set to run with no query time limit, and CpScript asset includes cache-bust automatically | A Data Source can no longer be configured to run its query with no time limit at all. The DataSource CpScript's CommandTimeout attribute is documented in the Script Designer for the first time, and a value of 0 - which previously meant no limit - now resolves to the system maximum. Any value above the system maximum continues to be capped, as before.
Existing Data Sources are not being given shorter time limits. A Data Source that leaves Command Timeout blank is unaffected: each Data Source type keeps exactly the default it had before, so existing feeds run as they do today. A Data Source explicitly set to 0 now stops at the system maximum, which is higher than the page request limit those queries already run under, so a query that completed before still completes.
One case worth reviewing. On Connection String, ODBC, OLE DB, Oracle and module-cached Data Sources, a CommandTimeout value was previously accepted and then silently ignored. It now applies. If one of those Data Sources carries an explicit value that is lower than the limit it was effectively running at, that value now takes effect - so check any Data Source of those types that has Command Timeout filled in. Ones left blank are unchanged.
The RegisterCssFile and RegisterUnmanagedScriptInclude CpScripts now add a cache-busting version to a site-relative stylesheet or script automatically, taken from the file's last modified date and applied when the page renders. A version query string added by hand is now replaced, so hand-added versions should be removed from existing content: they pin the file to an old version and stop later updates from reaching browsers. Fully qualified and protocol-relative URLs are left exactly as written.
The Word and Excel viewers now read a single shared list of supported formats, so the FileViewer CpScript's "View File in Browser" link and the viewer page it opens can no longer disagree about which file types are supported. |
| Master > Development > Sync Methods - the Agent update now refuses before replacing any files when it cannot manage the service | The sync method that updates the Centralpoint Agent used to begin replacing the Agent files and only then discover that it could not stop or start the Windows service, leaving the Agent part-updated and stopped. It now checks that it can manage the service first and refuses with a clear explanation if it cannot, so nothing is replaced. It also distinguishes a service that is simply slow to stop from one that has been refused: a slow stop is now waited for and re-checked rather than being treated as a failure, and a service already running at the target version is reported as such instead of being restarted needlessly. |
| Master > Deployment > Web Sites - site tools now report when an operation could not finish, instead of reporting success | Several site operations in Master > Deployment > Web Sites could fail silently on servers where the Master does not have permission to manage IIS or Windows services. In each case the console reported success and the operator had no way to know something had been left undone. These now report honestly:
- Deleting a web site - if the IIS bindings cannot be read, the process status now says so and the failure is recorded, so it is clear that a hosts-file entry may have been left in place. Previously this was discarded entirely.
- Restarting the API application - now reports three outcomes instead of two: restarted, requested but not confirmed, or failed. Previously anything that was not an outright failure was shown as a successful restart, including a restart that was only requested. This wording is shared with
Master > Admin > Properties, so both pages say the same thing. - Saving load balancing settings - if the Centralpoint Agent service cannot be restarted to pick up the new configuration, the operator is now told. Previously this went only to trace output, which is switched off on client servers, so the save reported success while the Agent carried on with its previous configuration.
Where a failure is caused by insufficient permissions, the message now explains the cause and, where one exists, points to the Server Hub action that can carry out the same operation. |
| Data Transform - Design (Styles) module fields beyond Global/Icons are now individually mappable | When a Data Transfer uses a module that has a "Site Type Properties" field (an Attribute Collection) as its source or destination — most notably the Design (Styles) module — the Fields tab now lists every sub-field as its own mappable column, each with its proper control (color picker, background-repeat list, font list, etc.). This covers all the tabs beyond Global and Icons: Top, Right, Bottom, Left, Center, Navigation, Sub Nav, Mobile Nav, and Misc.
Previously only the Global and Icons fields were mappable and every other field was locked inside a single Site Type Properties value, so the only way to load them was to hand-build one large XML value.
Expansion is automatic — there is no setting to enable. Existing transfers are unaffected: the new columns default to each field's existing value, so re-running a transfer does not require a new source mapping and does not change any field you did not map. On import, mapped values are merged into the module's Site Type Properties, leaving the fields you did not map untouched. |
| Site-wide - Statistical Semantic Search removal: measured re-index times, and the how-to pages it leaves behind | This is a follow-up to Site-wide - Statistical Semantic Search is removed, and its example Data Sources are archived, filed earlier in this cycle. That note still describes what the release does and how to opt out; nothing in it has changed. This one adds the timings, now that the removal has been run across a full server.
The re-index is far quicker than the earlier note suggested. That note said the rebuild "can run for hours on a large site", which was a conservative estimate made before the removal had been run at scale. Measured across 39 sites on one server:
- The whole server finished in 50 minutes, start to last index complete.
- The largest site, at 2.7 GB of indexed content, rebuilt in 6 minutes 27 seconds.
- Ordinary site search and
Contextual Search returned identical result counts before and after on every site checked.
No site needs to be scheduled separately. The sync works through sites one at a time rather than starting every re-index at once, so the load stays spread out on its own. A normal sync window is sufficient, and there is no need to stagger sites or hold the large ones back. An off-hours window is still the right choice, for the reason the earlier note gives.
Five how-to pages under Content > Generic describe the removed feature and should be retired. They contain no semantic queries, so the release leaves them untouched and they will keep rendering - but after this release they document something that no longer exists:
Semantic - Document KeyphrasesSemantic - Similar DocumentsSemantic - All Keyphrases Score in Content but not in KeywordsHow to create a Semantic Keywords Tag Cloud (Generic Enhanced A) including an EXCLUDE dictionaryHow to render a Semantic Keywords Tag Cloud - Against an Individual Record (Generic Enhanced A Only)
|
| Site-wide - the console now recovers on its own after a brief interruption to the central service | A short interruption in a site's connection to the central Oxcyon service could previously leave part of the console unusable until the site's application was restarted, which in practice could mean many hours. The first failed lookup was remembered and repeated on every later page view, so the site never retried even after the connection was fine again. Affected lookups now retry on the next page view and the console recovers on its own.
This covers two areas a user would notice:
- Console navigation. The menu and breadcrumb depend on a licensing lookup against the central service. A single brief failure could break those on every console page until the application restarted.
- Administrator role checks. A brief database interruption could leave administrator permissions unresolvable for the whole application in the same way.
On Development > Errors, sign-in failures against the central service are now grouped separately from connection failures. The two are unrelated faults that previously shared one group, which meant a burst of one could use up the hourly reporting limit and hide the other. Existing error records keep their current grouping; the split applies to newly reported errors.
|
| Master > Deployment > Web Sites - raised request time limits so large site creations and long-running tools no longer time out | Several pages and services were running under time limits far shorter than the work they perform, and would stop partway with a generic error rather than finishing.
- Creating a web site from a backup under
Master > Deployment > Web Sites had a one-hour limit. On a large site the domain-rewrite stage alone can exceed that, so the creation failed after the database and files were already in place. The limit is now five hours, and the rewrite stage itself was made substantially faster - it no longer scans every text column twice on sites whose new domain is longer than the old one. - Retrying a sync method from the Server Hub had a ten-minute limit, while the same method run during a version install had two hours. A long database operation could therefore fail on retry and succeed on install, with nothing to explain the difference. Retries now get the same five-hour allowance as the other maintenance services.
- Streaming a video or large file from the console, opening the template gallery, and converting a document to PDF each had no explicit limit and fell back to a short default. All three now carry their own.
Installations gained two safeguards. The installer now refuses to run when a Centralpoint database already exists on the SQL server, because continuing would replace it and discard every site, user and setting in it - recovering an installation by re-running the installer is no longer possible by accident. It also reports whether the Centralpoint Agent service ended up installed and running, so a server that would be invisible to the Server Hub is visible at the end of the run instead of days later.
web.config change - please read. This release edits web.config on the main site and Console to raise these limits. Two situations need attention on your installation:
- A virtual directory that runs as its own IIS application has a separate
web.config that the deployment does not touch, so it keeps the old, shorter limits. If that sub-application serves long-running requests - large downloads, document conversion, reporting - the same time limits must be applied to its own web.config by hand. - Custom code with its own configuration is unaffected by the values themselves, but confirm the site still loads after the update if your configuration overrides the same settings; where it does, your value takes precedence and may still be too short.
|
| Site-wide - audiences missing a home page are now reported, and a site root that cannot resolve returns 404 instead of looping | An audience with no published home page previously showed visitors an error page while recording nothing an administrator could act on. That condition is now reported and appears on Development > Errors, so it can be found without reading a server log. It is reported once per audience for the life of the application, not on every visit - a missing home page is a configuration fault rather than an event, so one entry per audience is the intended volume.
A new check also runs as part of the standard Clean Up task (Master > Content > Scheduled Tasks) and reports audiences that have pages but no home page, before a visitor finds one. Per-site detail is written to Master > Development > Process Log. Audiences with no pages at all are counted rather than reported, so the report stays limited to audiences that are genuinely broken - on a typical site that is the difference between one finding and hundreds. A single report covers the whole run and names every affected site.
Separately, a site root that cannot resolve to a home page - most often a domain added without a matching Preferred URLs record - previously returned a redirect to itself, which a browser reports as a redirect loop with no explanation. It now returns a standard 404 and records the host along with the address it resolved to, so the cause is visible instead of being mistaken for an outage.
The Events module add-to-calendar link (the addToMyCalendarText option) now returns a standard 404 when the event has been removed or has expired, rather than an error page.
To resolve a reported audience, open Site Architecture > Audiences, select the audience, and publish a home page for it. To resolve an unresolvable site root, add the Preferred URLs record for that domain, or a URL Redirect record pointing it at a valid page. |
| Master > Development > Sync Methods - a sync method that could not update a second load-balanced web server now reports Partial instead of Success | A site can be configured for load balancing, which adds a second web server sharing the same database. The sync methods that write site configuration write it to both servers.
Previously, if the write to the second server did not succeed - its path unreachable, or its permissions denied - the sync method still recorded Success. The first server was updated, the second was not, and the record gave no indication of it. Those methods now record Partial on Master > Development > Sync Methods, keeping the individual first- and second-server results on the record. A Partial record can be retried or marked Ignored from the record itself, the same as a failed one.
A run that updated both servers reports Success exactly as before - nothing that currently succeeds changes. An unexpected condition during the second-server write is now reported as a failure on the record rather than absorbed into it.
Existing records are not re-evaluated. A method that already recorded Success on a server does not run again, so the corrected reporting applies to methods that have yet to run there. On a site with no second server configured, nothing changes. |