| Feature | Summary |
| Centralpoint 8.12.12 maintenance - faster site map and console navigation, execution ceilings for long-running handlers, and console reliability fixes | Navigation and site map performance. The client-facing site map and the console navigation tree were rebuilt by re-scanning the entire navigation table once per node. The cost grew sharply with the number of navigation items and surfaced as slow page loads and occasional request timeouts on larger sites. Both now build in a single pass. The navigation output itself is unchanged - this is purely a speed improvement.
Execution ceilings for long-running handlers. Three handlers that legitimately run for minutes had no ceiling of their own and inherited the ASP.NET 110-second default, which aborted them mid-operation:Resource.ashx, which streams files and video to the browser, now allows 1800 secondsScripting/AsposeToImg.ashx, which renders a document thumbnail, now allows 600 secondsWebServices/Utilities.asmx on Master now allows 18000 seconds
Each value is a floor, not an override - a site already configured higher keeps its own value. This changes web.config on every site; see the warning below. Note that the document thumbnail ceiling is a mitigation rather than a fix: a document that cannot convert is still retried on every view, which is tracked separately.
Console reliability.Development > Content Audit now names the specific configuration entry or audience that is missing, instead of failing with a generic error- The Code File Manager no longer errors when opened with an unrecognized site in the address bar - it falls back to the current site
- Logging entries created without a results count no longer fail
- Trigger registrations are now cached in a form safe to read from concurrent requests, removing an intermittent failure under load
Security hardening. Several console detail pages built their database lookup by concatenating a value from the page rather than passing it as a parameter. All were converted to parameterized queries: Master > CMS > Keyword Lists, Master > CMS > Relations, Master > Admin > Private Labels, Master > Admin > Roles, and Development > Keyword Lists. Separately, predicate column validation on Master > CMS > Relations now checks the expression by compiling it rather than running it.
Deployment and server management.- The Centralpoint Agent's IIS repair now creates a site's missing
/Api application, and corrects one that points at the wrong or a deleted application pool. Previously a site whose API was never mounted could report as healthy. - The deployment engine's file copy step now honors the same exclusion list its cleanup step already used
Master > Development > Sync Methods now keeps each site's local copy of sync-method history in step with the master record, so a site restored or copied from another server no longer inherits stale failures from its sourceMaster > Content > Web Sites no longer reports a successful API application pool restart when the restart actually failed, and now names the pool in the error
Background reliability.- Long-running process cleanup now uses a recorded activity timestamp, so a process that is still working is no longer marked as abandoned during a quiet phase
- Static file references now carry an automatic version stamp, so browsers pick up updated files after a deployment instead of serving a cached copy
- A failure to reach Uber is now consistently classified as an infrastructure issue rather than being reported as an application error, and those calls are time-bounded
- Sign-in continues to work against the last known good signing key when the database is briefly unreachable, rather than failing outright
IMPORTANT - web.config changes in this release. The three ceilings above are applied by sync methods that edit web.config directly. Concretely they add or raise a ` block containing system.web/httpRuntime executionTimeout`:Resource.ashx -> 1800, applied to each site's Root/Web.config and Console/Web.configScripting/AsposeToImg.ashx -> 600, applied to each site's Root/Web.configWebServices/Utilities.asmx -> 18000, applied to the Master Root/Web.config only
The deployment touches the main site and Console web.config only. Two client-impact cases:
1. A virtual directory running as its own IIS application has a separate web.config that the deployment does not touch. If that sub-application serves Resource.ashx or the document thumbnail handler, it keeps the 110-second default and will still abort long downloads or renders. The same ` blocks must be added to that application's own web.config` by hand.
2. A site that has already raised any of these values keeps its own setting. These are floors, so no existing configuration is lowered - but confirm the intended value is still in place after the sync.
There are no binding redirect, handler, or module changes in this release, so client custom code needs no corresponding configuration change. |
| Word Viewer — tables now render at their defined width | The Word Viewer now sizes tables to their defined width. Documents containing tables are rendered with a fixed-layout method that preserves each page's exact dimensions; previously a table could be drawn narrower than defined, sized to whatever text happened to sit in its cells. Where a table continued across pages this was most visible, since each page could be drawn at a different width and the pages did not match each other. Documents whose tables are wider than the page itself continue to use the standard responsive rendering, because a fixed-layout page would cut off the columns that fall past the page edge. Documents without tables are unaffected.
This is the same rendering method already used for documents containing floating shapes, text boxes, and anchored images.
Note on these documents: because fixed-layout pages keep their exact dimensions, they are not responsive. Very wide pages on small screens may require horizontal scrolling.
Clearing the cached file for a problem document
The viewer saves each converted document as an HTML file under the site's Temp\AsposeWordViewer folder so it does not re-render on every view. If a specific document renders incorrectly and needs to be regenerated (for example, after the source document is corrected), delete only that document's cached file.
Cache location: [site]\Temp\AsposeWordViewer\[document folders]\[filename].html
- A document at
/Uploads/Policies/charter.docx is cached at ...\Temp\AsposeWordViewer\Uploads\Policies\charter.html - Resource-based documents are cached at
...\Temp\AsposeWordViewer\Resources\[resourceId].html
Steps:
1. Locate the .html file that matches the problem document under Temp\AsposeWordViewer.
2. Delete that single file.
3. Reopen the document in the viewer; it regenerates automatically on the next view.
Important: delete only the specific problem document's cached file. Do not clear the entire AsposeWordViewer folder. Every viewed document is cached there for performance, and removing all of them forces every document to re-render.
|
| Data Transform > Data Transfer - FileDownload "Save As Resource" now tracks files by a durable key so re-imported OneDrive files update in place instead of duplicating | The FileDownload script's Save As Resource mode now identifies each imported file by a durable source key instead of the download link. Previously, transfers from OneDrive or SharePoint Online created a brand-new Resource on every run, because the OneDrive download link changes each time and the system could not recognize a file it had already imported. This caused the Resources list to grow on every scheduled run and the returned link to change each time.
With this fix, re-importing the same source file updates the existing Resource in place: no duplicate rows, and the link stays the same across runs. For OneDrive and SharePoint Online this is automatic (the file's own item id is used, scoped to its drive). A new optional Identity Column field has been added to the FileDownload script for other source types whose URL is temporary or signed; leave it empty for OneDrive.
The Resource System Name is now generated so the same source file always produces the same name, which keeps the /Resource.ashx?sn=... link stable across runs. When ResourceUrlByName is enabled, the returned link uses that stable System Name.
Important - one-time behavior on upgrade: existing OneDrive or SharePoint Online transfers already running under Save As Resource will create one fresh set of Resources on their first run after this update. The previously duplicated rows are left in place and simply stop growing; after that first run, re-imports update in place as expected. Older duplicate rows can be cleaned up separately if desired. This release makes no web.config changes. |
| Site Architecture > Module Designer > Personalized Dashboard — gadgets now carry stable CSS classes so individual gadgets can be styled | Every gadget on a personalized dashboard now renders with CSS classes that identify it, so a stylesheet can target one specific gadget or every gadget of a given type. Previously the only identifiers in the markup were generated from a gadget's position on the page, so they differed from user to user and changed whenever a gadget was moved. Styling an individual gadget was not possible, and matching on the gadget name did not work either because users can rename their own gadgets.
Each gadget wrapper now carries:
- A type class on every gadget, naming the kind of gadget, such as
cp-gadget-rss or cp-gadget-html. - An instance class where the gadget has an identity to key on. Preset gadgets use their record number, for example
cp-gadget-6. Gadgets configured with a URL, meaning RSS and URL gadgets, use a simplified form of that URL, for example cp-gadget-rss-feeds-bbci-co-uk-news-rss-xml. These are the gadgets a user can add more than once, so the type alone would not tell them apart.
Neither class is affected by renaming a gadget or moving it to a different column or position. This means .cp-gadget-rss can style every feed alike while an instance class overrides a single one.
The available classes are documented in the PersonalDash module's Styles attribute, in the Dashboard group of the module view designer. The default styles now list the gadget type selectors, and new help text on the attribute describes the naming so it is discoverable without inspecting page markup.
No configuration changes are required. The classes begin rendering on their own once the sync is applied. There are no database changes, no new module settings to enable, and nothing to configure per site. Styling is opt in, so until a rule is added to the Styles attribute the dashboard looks exactly as it did before. Installations that have already customized their dashboard styles keep their existing styles untouched, and still receive the new help text describing the classes.
Note on record numbers: preset gadget record numbers are assigned per installation, while module view settings are carried between installations by the sync engine. A rule written against a specific gadget number will not point at the same gadget on a different installation, so those rules should be authored on the site where they will run. The URL based classes are not affected by this.
Two related corrections ship with this change:
- SQL performance has been optimized when loading a dashboard. Dashboards containing preset gadgets now make considerably fewer database calls per page load, and the saving grows with the number of gadgets on the dashboard.
- Each dashboard module view now keeps its own default gadget list. Previously every dashboard on a site shared a single cached list, so whichever dashboard loaded first determined what the others showed. On a site with more than one dashboard, a user who has never customized their layout may now see a different, correct set of default gadgets. Users with a saved layout are unaffected.
|
| macro-enabled Word document (.docm) support | Macro-enabled Word documents (.docm) are now handled everywhere other Word formats are. Previously a .docm could be uploaded but nothing in the system would process it: the FileViewer CpScript rendered no link at all, the PdfViewer CpScript and the PDF and thumbnail handlers returned nothing, and the document's text was never added to the full-text search index. The file was accepted on upload and then effectively invisible.
.docm is now accepted by:
FileViewer and the Word viewer pagePdfViewer and the PDF conversion handler- Thumbnail and image generation
- Full-text search extraction (the
ResourceContent attribute) - Word document content attribute extraction
FileOutput template documents
Two related corrections ship alongside it. The FileViewer CpScript now also emits links for .xlsb and .xlsm spreadsheets, which the Excel viewer already displayed but for which no link was ever generated. And the FileOutput CpScript now matches template file extensions case-insensitively, so a template saved with an uppercase extension such as Template.DOCX is processed instead of being silently skipped, producing no file and no error.
The Word viewer's unsupported-format message has also been reworded to name the supported formats.
|
| Admin > Duplicate Content — new tool for finding and reviewing duplicate records | A new Duplicate Content tool finds records that hold the same content as each other and groups them together so they can be cleaned up from one place.
Each set of comparisons is configured as a scheduled task under Master > Content > Scheduled Tasks, choosing which modules to look at and which fields decide whether two records count as the same. Matches are found within a single module and across several, so the same content published in two places is reported together. The comparison ignores differences that do not change what a reader sees, such as formatting, spacing and capitalization, and it looks at one web site at a time.
Results are reviewed under Admin > Duplicate Content. Records that match are listed side by side with their module, dates and status, so the one to keep is easy to pick out. Redundant records can be deleted, which sends them to the recycle bin and leaves them restorable. Duplicates that exist on purpose can be dismissed instead, with an optional note explaining why, which stops them being reported without deleting anything. Anything dismissed can be put back into the report later.
The tool only reports what is true at the moment. Editing a record so it no longer matches removes it from the list on the next run, and deleting one removes it straight away. The first run examines every record and can take a while on a large module; later runs only look at what has changed since, so they finish quickly. An optional time limit keeps any single run inside a chosen window.
Each person sees only the groups and records their account already allows them to see elsewhere in the Console, so two administrators may correctly see different lists.
|
| Data Transform > Data Transfer — new option to return Resource file URLs by System Name | The FileDownload script now has a new Resource Url By System Name option, available when Save As Resource is enabled. Normally, when a Data Transfer downloads a file and stores it as a Resource, the script returns the file's link using the Resource's Id (for example, /Resource.ashx?id=...). Some sites have existing preview and document-viewer scripts that expect the link in the System Name form instead (for example, /Resource.ashx?sn=...). Enabling this option makes the script return the System Name form. Both forms point to the exact same stored file. The option is off by default, so existing transfers are unaffected. The option only takes effect when Save As Resource is also enabled. |
| Master > Deployment > Updates - update installs now report every file that failed, and agent updates no longer block on a locked file | File copying across the deployment path has been consolidated onto a single routine that checks its own work, and every place that copies files during an update, a patch or an agent update now uses it.
Update installs. An update that cannot write a file no longer stops at the first one. It finishes the file set, then fails with the complete list of files that did not land, so a single locked or read-only file no longer hides everything after it. A destination marked read-only is now cleared and written instead of aborting the run. After each section is copied, the applied files are reconciled against the update package and any file that is missing or a different size is reported as a warning on the process status and in the error detail - previously a partially applied file set looked identical to a complete one. The install also no longer leaves the Master API application pool stopped when it fails: the pool is restarted before the failure is reported.
Agent and CLI updates. The Centralpoint Agent and Centralpoint.exe are now replaced by renaming the existing file aside and writing a fresh copy, rather than overwriting the running file in place. Overwriting required exclusive access to a file that was in use, so on servers where antivirus, a file indexer or a backup agent holds a handle the update could not succeed at any retry count and needed a manual copy every release. If the replacement cannot be completed, the previous file is put back, so the service is never left without a working executable. The agent service is also now confirmed to reach Running before the update reports success.
Patches. Each file a patch writes is now read back and compared against the file the patch shipped. A mismatch is reported with the expected and actual values and the patch reports failure instead of success. A patch that stops an application pool now waits for it to come back and reports failure if it does not. When a patch cannot land its files for a site, that site's configuration step is skipped rather than applying binding redirects for assemblies that did not arrive - the redirects for other sites on the same server still apply as normal. A patch that reports failure is no longer recorded as applied, so it can be re-sent. |
| Master > Deployment > Synchronize - one sync per site at a time, with truthful reporting and a recoverable data sync | Synchronizing a site is now protected against overlapping runs. Only one synchronization can run against a given site on a server at a time. Under Master > Deployment > Synchronize, a site that is already synchronizing is shown as in progress and cannot be selected, and starting another run against it reports that it was skipped rather than starting a second one. Selecting several sites still synchronizes the ones that are free.
The synchronization also now reports what actually happened. Previously a run could report Sync Completed even when it had failed internally, when a deployment step failed, or when the data synchronization declined to run. Those outcomes are now reported as failures on both the page and the process record, and a data synchronization that refuses because the site has no recent backup says so instead of finishing silently.
Data synchronization is safer and more recoverable:
- The data synchronization will not delete content when another process is interfering with the working tables it uses. It stops with a clear message instead.
- A single file marked read-only no longer aborts an entire synchronization. The file is corrected automatically and the run continues.
- Recovering content no longer depends on the file copy finishing first. The database work runs even if the file phase fails, and All Elements no longer forces every file to be re-copied, so restoring content completes on large sites instead of timing out.
- Long file copies now report their progress, so a healthy run is no longer mistaken for a stalled one.
Under Master > Development > Process Monitor, processes now record who started them rather than appearing as automated, keep their status current even during quiet phases, and the page loads faster on installations with a large process history.
|
| Admin > Properties - new Protect Statistical Semantic Search option, ahead of the v8.12.13 removal | A new Protect Statistical Semantic Search property has been added under Admin > Properties. It controls whether this site keeps Statistical Semantic Search when the feature is removed in v8.12.13.
Statistical Semantic Search is an optional SQL Server feature that Centralpoint does not create and does not require. Where it is present it was enabled by hand on the database server. A stalled semantic index rebuild can consume enough database resources to slow or stop a site, so the feature is being retired across all installations.
The property defaults to No, which means the removal will run on this site. Set it to Yes only if this site actively uses semantic search. Taking no action means Statistical Semantic Search will be removed from this site in v8.12.13.
What the v8.12.13 update will do on a site that has not opted out:- Remove the semantic option from the site's full text indexed columns.
- Retire the semantic example Data Sources under
Design > Data Sources. These are archived rather than deleted, so they remain retrievable.
Ordinary keyword search and Contextual Search are not affected - only the per column semantic option is removed. Removing it causes SQL Server to rebuild the full text index, so the v8.12.13 update should be scheduled outside business hours.
Clients who have copied a semantic example Data Source into a live page should review those pages before v8.12.13, or set this property to Yes to keep the feature on this site.
|
| Site-wide - links built from the current page address are now encoded (security) | Links that Centralpoint builds from the address of the page being viewed are now encoded before being written into the page. This affects the breadcrumb trail (BreadCrumbTrail), the Enable/Disable Edit Mode link (EditMode), the "Export to Excel" links and the record Add/Edit/Delete actions on dashboard views (LeadsDashboardScript, TrafficDashboardScript, DashboardAction, BuldLink, CompanyNavigation), and the Yahoo Calendar link produced by AddToCalendar.
Previously a visitor could append specially crafted text to a page address and have it treated as part of the link markup rather than as part of the address. The encoding closes that. It is deliberately narrow so existing links are unaffected: addresses that already contain encoded characters, such as & in a query string, are left exactly as they are, so paged, filtered and taxonomy-filtered views continue to link as before.
This is a code-only change delivered with the update package. There is no configuration, CMS or database change, and nothing to enable. |
| Admin > Global Login - hardened post-login redirect for SAML sign-in (open-redirect fix) | SAML sign-in now validates the destination a user is sent to after a successful login. Previously the return destination could be supplied in the sign-in link and was followed without checking, so a crafted link could route a user to an outside website immediately after a genuine login. The sign-in flow now only honors a destination that is a path on the same site, or a full web address on the same site''s own domain; anything pointing to a different domain (or an unreadable value) sends the user to the site home page instead.
Destinations an administrator configures on a Global Login record (the RedirectTo setting) are unchanged and continue to work, including a full same-site address such as https:///section/page. The new check applies to both service-provider and identity-provider initiated sign-in, and to the redirect shown after a failed sign-in. |
| Admin > Authorizations - resolved repeated reauthorization prompts on Microsoft connections | Changes Made
Some clients reported having to reauthorize their Microsoft connections over and over. An authorization would complete successfully, work for about an hour, and then report that it needed authorizing again. Reauthorizing restored it for about another hour, indefinitely.
It was most commonly identified on Data Transfer records using the Office 365 and SharePoint readers, since those depend on the connection staying live between scheduled runs.
The cause was a missing or out-of-date address for the master in the Azure application's Redirect URI list. Microsoft access is renewed automatically about once an hour, and that renewal was sending the master's address for Microsoft to check against that list. Where the address was absent, or still pointed at a previous server after a migration, Microsoft rejected the renewal. The initial authorization was unaffected because it runs against the site address, which is normally registered, so authorizing always appeared to work and only the renewal behind it failed.
The renewal no longer sends an address at all, which is what the Microsoft standard calls for on that step. A missing or stale master entry no longer causes the connection to lapse, and a future server, domain or IP change will not break an existing connection the same way. No configuration changes are required to resolve this on either the Centralpoint or the Azure side. Reauthorizing an affected connection once after the update is enough.
A second, related correction: on a multi-site install, a renewal triggered from a Data Transfer was being saved against the master instead of the site the connection belonged to, leaving the site's own record untouched.
Where a renewal does fail, the failure report now names the install it came from. Reports of this kind are collected centrally and previously gave no indication of which client produced them.
The Redirect URL attribute on an authorization record at Admin > Authorizations is now documented. Leaving it blank uses the built-in callback address, which is correct for nearly every install, and any value entered there must be registered in the Azure application.
The master address should still be present in the Azure Redirect URI list, because an authorization started from the Master console continues to use it. It is no longer involved in the hourly renewal, so a missing entry now surfaces immediately when authorizing rather than an hour later.
The Authorizations help article has been rewritten to cover the Redirect URI requirements, where each address is found under Admin > Console Settings, and what to re-check after a server move.
|
| Master - 8.12.12 maintenance: reliability fixes across sync, scheduled tasks, sign-in, and the console (raises the Utilities.asmx execution ceiling) | This is the roll-up for the 8.12.12 weekly maintenance pass. Every item came from a real failure observed on a client install, not from planned feature work.
Execution ceiling for Utilities.asmx raised to 5 hours. Utilities.asmx and ScheduledTasks.asmx both run the same cleanup sweep across every web site, but the shipped ceiling depended on which endpoint the caller used - 15 minutes on one, 5 hours on the other. A client's cleanup aborted mid-sweep at exactly 15 minutes. Both endpoints now allow 5 hours. This is a web.config change - see the warning below.
Sign-in no longer breaks the page when the central server answers with an error page. If the central server returned a maintenance page or an error page instead of a normal response, sign-in raised an unhandled error and took the page down with it. It now denies the sign-in cleanly and records the reason. Any password present in the returned content is masked before it is recorded.
Console navigation survives a brief loss of contact with the central server. The list of groups a site belongs to is read from the central server on every console render, so a momentary network blip could empty the navigation. That list is now cached for an hour, with the last known good value served through a short outage and a ceiling past which it stops serving stale data. A failure for one site no longer affects any other.
Health Monitor loads its notes in one pass. The records view previously issued a separate query for every row on the page. It now loads them together, in batches, so a large page size no longer slows the page or exceeds a database limit.
Data Broadcast: unsubscribed-recipient list. When a broadcast was configured to unsubscribe bad email addresses, the resulting list was never produced. It is now generated for both bad-address and duplicate-address modes, and each batch writes to its own folder instead of nesting inside the previous one.
Data Archive: the configured timeout now applies to the whole run. The extended timeout was applied several statements too late, so the earliest steps still ran under the default and could abort on a large archive.
Installs no longer abandon sync methods during a cold start. When a site was still starting up, an internal call could fail on its first attempt and the remaining sync methods were skipped, leaving them Pending. Those attempts are now retried - but only where the response proves the work never began, so a retry can never start the same sync twice.
Article pages no longer fail when search telemetry is slow. Recording search insights held the page open until the remote service answered. Those calls are now bounded and, if they fail, the article still renders.
Marketplace Directory contact lookup now passes its record identifiers safely, and Query Analyzer releases its saved-query connections properly.
Diagnostics added where a failure previously reported nothing useful. Impersonation failures now record the underlying Windows reason, central-server call failures record the transport status, and the Process Monitor no longer suggests a cause that has been ruled out.
Agent and CLI updated to 8.12.12.0 and delivered by this sync.
web.config warning. This release changes Master/Root/Web.config: the WebServices/Utilities.asmx location's executionTimeout goes from 900 to 18000 seconds. Existing installs are upgraded by the RaiseUtilitiesAsmxExecutionTimeoutTo18000 sync method, which is floor-only - a client who already raised the value keeps theirs, and an install already at 18000 is unchanged. Only the Master site's own web.config is touched.- Virtual directories running as their own IIS application have a separate
web.config that this deployment does not touch. If a sub-application calls Utilities.asmx, its cleanup still aborts at whatever ceiling its own config carries. Apply the same executionTimeout there by hand. - The usual custom-code concern does not apply here: this changes a timeout value only, with no assembly, handler, or module changes, so nothing that loads today can fail to load after it.
|