Digiter Network Tools

Professional network, domain, mail and visitor diagnostics from one WordPress workspace.

Product overview

Digiter Network Tools brings a collection of everyday network and internet diagnostics into the WordPress administration environment so a site owner does not have to jump between unrelated third-party pages for every check. The product is intended for website operators, agencies, technical support teams and advanced users who need a clearer picture of connectivity, public addressing, DNS, TLS and mail configuration while they are already working on the site.

The plugin combines browser-side measurements with server-side and public-network observations where appropriate. Results are normalized into a consistent interface so a user can compare related information instead of reading raw responses from many different services. The goal is practical diagnosis: identify whether a symptom is more likely to originate in the visitor connection, DNS configuration, certificate state, mail records, public routing or another visible part of the delivery chain.

Core capabilities

• Run internet connection checks that present latency, jitter, download and upload behavior in a visual form suitable for quick comparison.
• Inspect domain and DNS information, including common record types and the relationships between hostnames, addresses and configured mail routing.
• Review public IP and connection context so administrators can better understand how a site or visitor reaches the public internet.
• Analyze SSL/TLS-facing information and surface certificate or hostname conditions that may contribute to browser or service warnings.
• Review mail-domain configuration such as MX, SPF, DKIM, DMARC and transport-security indicators from one diagnostic area.
• Provide visitor-oriented diagnostics, mapping and report views that can help explain connection context without requiring shell access.
• Present related checks in a consistent Digiter interface so technical findings are easier to document, repeat and communicate to another administrator or customer.

Typical operating workflow

• Select the diagnostic area that matches the symptom instead of running every test at once.
• Enter or confirm the target domain, address or connection context and start the requested check.
• Review the primary result first, then compare supporting DNS, TLS, routing or mail information when a dependency is involved.
• Repeat the same check after a configuration change so before-and-after behavior can be compared.
• Use reports or visible result summaries when findings need to be shared with a hosting provider, DNS operator or customer.
• Keep WordPress, the plugin and relevant server software updated so diagnostic output reflects the current environment.
• Escalate unresolved infrastructure issues to the responsible provider when the plugin identifies a condition outside WordPress control.

Where the product fits

• Checking whether a newly moved domain resolves to the intended host and whether the visible TLS state follows the new configuration.
• Reviewing mail authentication records after a hosting migration or when messages are rejected because SPF, DKIM or DMARC alignment is incomplete.
• Comparing a visitor-reported slow connection with latency, jitter and throughput observations before changing WordPress performance settings.
• Collecting a compact technical picture before contacting a registrar, ISP, mail provider or hosting support team.
• Giving administrators a repeatable diagnostic toolbox on sites where command-line access is unavailable or intentionally restricted.

Operational considerations

• Diagnostics are initiated by the user and should be interpreted as observations of the current environment, not as a guarantee that an external network will remain unchanged.
• Public DNS, IP and certificate information can change independently of WordPress. Re-run relevant checks after DNS propagation, certificate renewal, router changes or hosting migrations.
• Browser measurements depend on the visitor device, connection quality, browser limitations and concurrent network activity. Several measurements are usually more meaningful than a single isolated result.
• Mail diagnostics describe the visible configuration and transport context. Final delivery decisions remain under the control of receiving mail systems and their reputation or filtering policies.
• For production troubleshooting, preserve a record of the time, target and result before making changes so a later comparison is possible.

Compatibility and environment

• The plugin is designed for normal modern WordPress installations and uses WordPress permissions and front-end/browser capabilities rather than requiring permanent shell access.
• Some network information is necessarily dependent on the hosting provider, DNS operator, browser or external destination. A restricted hosting environment may expose less information than a full server.
• Caching and security plugins should not cache dynamic diagnostic responses that are intended to represent the current request or visitor context.
• When a hosting firewall blocks an outbound request required for a selected test, the plugin can only report the resulting limitation; the server administrator controls that policy.

Recommended best practices

• Use the narrowest diagnostic that answers the current question, then expand to related checks only when the first result points to another layer.
• Never change DNS, mail or TLS configuration only because of one isolated metric. Confirm the current authoritative configuration first.
• After a migration, verify web DNS, mail DNS and certificates separately because they can be hosted by different systems.
• Keep screenshots or exported findings when working with external support so the exact state at the time of the issue is documented.
• Treat reputation or public-network data as one input in a broader investigation rather than an absolute verdict.

Privacy, security and implementation boundary

Diagnostic requests are limited to the feature the administrator or visitor deliberately starts. Some functions necessarily process a domain, public IP address, approximate connection context or browser-approved location in order to return a result. Digiter documentation does not publish internal scoring weights, provider-selection logic, anti-abuse controls or proprietary validation methods. Administrators remain responsible for informing visitors when a public-facing diagnostic collects information that requires notice under their local privacy rules.

Support and troubleshooting

If a result appears inconsistent, reproduce the check, note the target and time, and contact [email protected] with the relevant screenshots or report. Digiter Team can help interpret plugin behavior and distinguish a plugin issue from a DNS, hosting, ISP or mail-provider condition.

Digiter Weather Forecast

A configurable 10-day WordPress weather experience with location awareness, Car Travel route planning and animated map layers.

Product overview

Digiter Weather Forecast is designed for WordPress sites that want to present useful weather information without making the visitor leave the page for a separate weather portal. It combines a multi-day forecast with location handling, responsive presentation and animated map layers so a publisher can place a compact forecast, a richer weather view or both into the site experience.

The product focuses on presentation as well as data. Administrators can control the visual appearance, language, background behavior, timeline and shortcode placement while the plugin converts forecast and map information into one consistent front-end component. Automatic location can begin with an approximate IP-based position, while precise browser location is used only when the visitor explicitly grants permission.

An important newer capability is Car Travel planning. This mode is intended for route-oriented weather awareness: the user can define a starting point and destination, review expected weather conditions along the drive and understand how rain, wind, temperature or other conditions may evolve around the estimated travel timeline rather than only at one static location.

Core capabilities

• Present a 10-day forecast in a responsive layout that is suitable for desktop, tablet and mobile visitors.
• Use approximate IP-based location for convenience and optionally request precise browser location when the visitor chooses to allow it.
• Show animated weather-map layers for rain, cloud, snow, wind, temperature and satellite-style visualization where supported by the configured data source.
• Offer multilingual presentation for the supported US and European languages included in the product.
• Allow administrators to configure colors, backgrounds, display behavior and timeline-related presentation without rebuilding the WordPress theme.
• Provide shortcode-based placement so weather content can be inserted into pages or other supported content areas in a controlled way.
• Offer Car Travel route planning so a user can check expected weather along a drive, not only at a single fixed place.
• Combine route weather with travel-time context so weather changes can be interpreted in relation to the expected progress of the trip.
• Keep public weather presentation visually isolated from unrelated theme styling as far as practical so the widget remains readable across different sites.

Typical operating workflow

• Install and activate the plugin, then review the default location and visual settings before publishing the widget.
• Choose whether the site should begin with automatic approximate location, a configured default location or a visitor-selected position.
• Configure language, units, colors, backgrounds and map behavior to match the site design and audience.
• If the site uses Car Travel mode, test one or more representative routes so the expected travel-weather timeline is easy for visitors to understand.
• Insert the provided shortcode into the intended WordPress page and test the result on both desktop and mobile widths.
• Test the browser-location permission flow so visitors who decline precise location still receive a useful fallback experience.
• Review animated layers and timeline behavior on the browsers most commonly used by the site audience.
• After significant theme, cache or optimization changes, verify that weather assets and dynamic data are still loaded rather than served as a stale static copy.

Where the product fits

• Local news, tourism, accommodation or event sites that want weather information directly beside their content.
• Community and regional portals that need a forecast for the visitor location without forcing manual city selection every time.
• Outdoor, travel or service websites where rain, wind or temperature maps provide more context than a simple current-condition number.
• Travel-oriented pages that want to present Car Travel route weather, helping drivers understand forecast changes during a journey rather than only at the destination.
• Multilingual sites that want one consistent weather component across several translated pages.
• WordPress installations that need a configurable visual forecast but do not want to build and maintain a custom weather front end from scratch.

Operational considerations

• Forecast information is time-sensitive and depends on the configured weather data source. It should be treated as an informational forecast rather than a safety-critical warning service.
• Approximate IP location can be inaccurate for VPNs, mobile networks, corporate gateways and some ISPs. Precise browser location is normally more accurate but requires visitor permission.
• Animated map layers can require more browser and network resources than a simple forecast card. Site owners should test the intended combination on mobile devices and slower connections.
• Car Travel route planning depends on route and travel-time assumptions. It is intended to help users estimate likely weather exposure during the trip, not to function as a navigation or traffic-control system.
• Caching should be configured so rapidly changing weather data is not frozen for excessive periods. Static page caching and dynamic forecast refresh have different purposes.
• When a data provider or browser temporarily limits a request, the interface should be reviewed again before assuming the WordPress configuration is permanently broken.

Compatibility and environment

• The public interface is intended for current mainstream browsers with JavaScript enabled and a modern WordPress front end.
• Browser geolocation depends on HTTPS and the browser permission model. A visitor can deny permission at any time, and the plugin must continue with a fallback location strategy.
• Optimization plugins that delay scripts aggressively should be tested to ensure the weather initialization code is not postponed beyond the point where the widget is expected to appear.
• Theme CSS can vary widely; the plugin attempts to isolate its presentation, but unusual global CSS rules may still require site-specific adjustment.

Recommended best practices

• Always provide a useful configured fallback location so the weather display does not depend entirely on geolocation permission.
• Use map animation selectively on pages where it adds value, especially when mobile performance is important.
• When using Car Travel, choose route examples and wording that clearly communicate that the feature estimates weather conditions along the journey and does not replace safe-driving judgment.
• Match units and language to the primary audience and verify translated labels after major plugin updates.
• Exclude dynamic weather endpoints from page or object caches if a cache layer causes outdated conditions to persist.
• Do not present a general consumer forecast as a substitute for official emergency, avalanche, aviation, marine or severe-weather warnings.

Privacy, security and implementation boundary

Precise location is requested only through the browser permission mechanism and is used for the weather function the visitor requests. Approximate IP-based location may be used as a fallback or convenience feature. The exact provider-selection, caching, fallback and abuse-prevention logic is part of the proprietary implementation and is intentionally not published. Site owners should describe location use in their own privacy information when local law or their site context requires it.

Support and troubleshooting

For display, location, shortcode, Car Travel or map problems, contact [email protected] with the WordPress version, browser, page URL, the route used for testing where relevant, and a screenshot of the affected widget. Digiter Team can help separate a site-style or caching conflict from a data-source or browser-permission issue.

Digiter Security Ultimate

Layered WordPress protection, malware analysis, authentication hardening, quarantine and recovery tooling.

Product overview

Digiter Security Ultimate is built as a security operations suite rather than a single on/off firewall switch. It combines request protection, anti-bot controls, login hardening, malware and integrity analysis, quarantine, two-factor authentication, alerts, diagnostics and recovery-oriented functions so administrators can investigate an incident and respond from one coordinated interface.

The product is designed around layered defense. No individual signal is treated as sufficient for every threat, and security decisions are presented with context where practical. File analysis can combine WordPress-aware integrity information with local inspection and, when an administrator has installed and enabled supported server-side tools, optional engines such as ClamAV or YARA. The exact scoring, signatures and defensive thresholds remain proprietary because publishing them would weaken the protection model.

Core capabilities

• Apply an application-layer firewall and anti-bot controls to relevant public requests while preserving normal WordPress operation.
• Protect login activity with rate controls and administrator two-factor authentication, including recovery-oriented account procedures.
• Scan WordPress files for suspicious behavior, integrity problems, disguised executable content and other indicators that deserve action or manual review.
• Use protected quarantine and verified restore workflows so a suspicious file is not simply deleted without a recovery path.
• Present security events, attack activity, IP intelligence, alerts and diagnostic information in an administrator-focused interface.
• Use server-side ClamAV or YARA integrations when they have been installed by the server administrator and are accessible to the WordPress PHP environment.
• Integrate licensed private updates and authorized rollback so security maintenance remains part of the same commercial product lifecycle.

Typical operating workflow

• Begin with the security dashboard and diagnostics to confirm that the installation, file permissions and optional local engines are in the expected state.
• Configure login, anti-bot, firewall and notification settings conservatively before enabling stricter policies on a production site.
• Run an initial scan to establish the current file state and review findings by severity and context rather than deleting every flagged file automatically.
• Quarantine only items that have been reviewed and preserve the ability to restore them if the finding proves to be benign or the site depends on the file.
• Review authentication and attack events for repeated sources, unusual patterns or changes that correspond with a reported incident.
• After remediation, run follow-up integrity and malware checks and verify the affected public and administrative workflows.
• Keep the licensed plugin and WordPress core/extensions updated and retain a separate backup because a security product is not a replacement for disaster recovery.

Where the product fits

• Hardening a public WordPress site that receives repeated automated login attempts, form abuse or suspicious request patterns.
• Investigating unexpected file modifications after a compromised account, vulnerable extension or unauthorized server change.
• Adding administrator 2FA and recovery controls on sites where wp-admin access has meaningful business impact.
• Providing an auditable workflow for malware findings, quarantine decisions and post-cleanup verification.
• Using local server-side scanning engines as an additional signal without allowing WordPress to install or manage privileged operating-system packages.

Operational considerations

• Security findings require context. A suspicious pattern can be malicious, intentionally administrative or part of another security product; manual review remains important for high-impact actions.
• The plugin does not grant WordPress sudo or root privileges. Installing system packages, managing daemons and changing server-wide security policy remain server-administrator responsibilities.
• Optional scanners can be unavailable when PHP open_basedir, disabled functions or hosting policy prevents access to the executable or rule files. Diagnostics should be checked before relying on them.
• Quarantine and restore operations should be accompanied by a current site backup and should be tested carefully on business-critical installations.
• Firewall and anti-bot settings can affect integrations, API clients and unusual authentication flows. Increase strictness gradually and test the workflows the site actually uses.

Compatibility and environment

• The suite is designed for current WordPress installations and common Apache/Nginx/Plesk-style environments, but hosting security restrictions can change which optional local tools are available.
• Caching, CDN and reverse-proxy layers can change the apparent client address. Administrators should configure the surrounding infrastructure correctly so security logs represent the intended source information.
• WooCommerce, APIs, mobile applications, SSO and password-reset flows should be tested after authentication or rate-defense changes because they may use different endpoints from a normal browser login.
• Other security plugins can overlap with firewall, login or scanning functions. Avoid enabling two products to enforce contradictory policies on the same request path.

Recommended best practices

• Create a verified backup before major remediation or hardening changes and keep that backup outside the affected WordPress installation when possible.
• Use 2FA for administrators and maintain recovery codes in a secure offline location.
• Investigate recurring warnings instead of simply whitelisting them; repeated false positives usually indicate that a rule, integration or site behavior needs better context.
• Review diagnostics after PHP, web-server or hosting changes because optional binaries and paths may become inaccessible even though WordPress itself still works.
• Treat security as a process: update, monitor, investigate, remediate, verify and maintain recovery capability rather than relying on a single scan.

Privacy, security and implementation boundary

Security operation necessarily processes request metadata, authentication events, file paths, hashes, IP-related context and configuration information required to detect or investigate suspicious behavior. Exact detection weights, signatures, rule composition, trust logic, hardening thresholds and internal response decisions are proprietary and are not published in customer documentation. Site owners remain responsible for their own logging notices, retention policies and legal obligations.

Support and troubleshooting

For a suspected false positive, quarantine question, login lockout or scanner issue, contact [email protected] with the finding category, affected path or workflow, relevant diagnostic state and a screenshot. Do not email passwords, private keys, full database exports or other secrets.

Digiter Migration Pro

Resumable backup, migration, staged restore and disaster-recovery tooling for WordPress.

Product overview

Digiter Migration Pro is designed for WordPress moves and recoveries that are too important to depend on one long browser request. The product breaks demanding work into controlled stages, records progress and uses the Digiter migration package format so larger sites can be processed with a better chance of continuing through normal PHP and hosting limits.

The plugin covers more than export. It is intended to support the full operational chain: create a backup, preserve integrity metadata, move or upload the package, import it, restore files and database content in ordered phases, recover from an interrupted operation and verify the result. Manual browser backups remain available as a basic capability, while licensed functions add the more advanced migration, scheduling, server-side execution, diagnostics and recovery workflow.

Core capabilities

• Create manual browser-driven backups and licensed server-side or scheduled backup jobs depending on the active entitlement.
• Build resumable DGM4 migration packages with integrity metadata so long-running work can be continued in stages.
• Handle supported legacy Digiter backup generations when compatibility logic is available for the selected archive.
• Run staged database restore and file operations rather than treating the entire site recovery as one opaque request.
• Provide recovery checkpoints, automatic rollback-oriented safeguards and an emergency recovery runner for interrupted operations where supported.
• Adapt work pacing to server conditions so demanding backup or restore tasks are less likely to overwhelm constrained PHP environments.
• Expose diagnostics, logs, settings and licensed private update/rollback functions for administrators who need to understand the migration state.

Typical operating workflow

• Before migration, update the source site where appropriate and confirm that a separate working backup exists.
• Create a new Digiter package and allow all stages to finish before moving it away from the source installation.
• Check archive integrity and available free space on the destination before starting an import or restore.
• Place the destination site in a controlled maintenance window when overwriting an existing installation could affect visitors or orders.
• Run the restore through its staged workflow and avoid closing or interrupting recovery actions that explicitly need administrator confirmation.
• After completion, verify the front end, wp-admin, permalinks, key plugins, media, forms and any site-specific scheduled or external integrations.
• Keep the pre-migration and post-migration backups until the new site has operated correctly for a reasonable verification period.

Where the product fits

• Moving a WordPress site between hosting providers when the administrator needs both files and database content transferred in a coordinated package.
• Creating a restorable snapshot before a major redesign, plugin replacement or infrastructure change.
• Recovering a site after an interrupted deployment, damaged database operation or failed migration attempt.
• Handling larger sites where a single browser export would be vulnerable to PHP timeouts or connection loss.
• Maintaining a repeatable backup-and-restore procedure for sites managed by an agency or technical administrator.

Operational considerations

• Backup success is not proven until a restore path has been tested. Administrators of important sites should periodically verify that their packages can be read and restored in a disposable environment.
• A migration can change URLs, filesystem paths, database credentials, PHP capabilities and server behavior at the same time. Post-restore testing should therefore cover both WordPress and the surrounding hosting stack.
• Free disk space is required for package creation, extraction and rollback data. A server that is nearly full can fail even when the final site itself would fit.
• Large database tables and media libraries can extend operation time. The adaptive engine reduces pressure but cannot override hard provider limits or insufficient storage.
• Do not delete the only known-good source site or backup immediately after a successful-looking migration. Preserve a rollback path until functional verification is complete.

Compatibility and environment

• The product targets modern WordPress/PHP environments and records product-specific minimum requirements in the Shop catalog and plugin package.
• Host limits such as execution time, memory, file size, process restrictions and free disk space still apply. The resumable design reduces exposure to those limits but does not make them disappear.
• Security plugins and web-server rules can block archive upload, extraction or recovery requests. Temporarily adjusting a conflicting rule should be done only by an authorized administrator and restored afterward.
• Cross-version or legacy-package restore depends on the compatibility support built into the current release; unsupported archive formats should not be forced into the restore process.

Recommended best practices

• Create at least one independent backup before overwriting a destination site.
• Perform major migrations during a maintenance window and suspend content/order changes if data consistency matters.
• Check PHP version, available storage and important plugin requirements on the destination before beginning the transfer.
• After restore, regenerate permalinks and verify forms, email, scheduled actions, ecommerce callbacks and external API credentials.
• Keep backup archives protected from public download and remove obsolete copies from web-accessible locations when they are no longer needed.

Privacy, security and implementation boundary

Migration packages can contain the entire WordPress database, uploads and configuration data, which may include personal or confidential information belonging to the site. Package handling is therefore an administrator responsibility and archives should be treated like a full site backup. Archive layout, recovery sequencing internals, serialization handling and proprietary compatibility logic are intentionally not disclosed because they are implementation-sensitive.

Support and troubleshooting

For backup, import or restore trouble, contact [email protected] with the plugin version, source and destination WordPress/PHP versions, package size, operation stage and sanitized diagnostic message. Never send a full customer database or configuration containing secrets unless a secure support procedure has been explicitly agreed.

Digiter Page Caching Ultra

Adaptive full-page caching and frontend performance controls for WordPress.

Product overview

Digiter Page Caching Ultra is designed to shorten the path between a visitor request and a finished WordPress page by storing eligible rendered responses and serving them again when it is safe to do so. The product combines page caching with warm-up and selected frontend performance controls so administrators can manage performance from one place instead of stacking many unrelated optimizers.

The difficult part of caching is not writing a file; it is knowing when a cached response is still valid. The plugin therefore treats invalidation, exclusion, warm-up and compatibility as first-class concerns. Content changes can clear affected entries, important pages can be warmed again, and hardware/load-aware pacing can reduce background pressure when the server is already busy.

Core capabilities

• Create and serve eligible full-page cache entries for anonymous front-end requests according to configured rules.
• Invalidate affected cache entries when WordPress content changes so visitors are less likely to receive outdated pages.
• Warm selected content after invalidation using paced requests rather than generating every page simultaneously.
• Provide frontend optimization controls for assets, media and browser behavior where those functions are enabled in the product settings.
• Coordinate performance work with host load and configured compatibility rules so background optimization can become less aggressive on a busy server.
• Offer diagnostics and recovery-oriented controls so an administrator can disable or reverse an optimization when a theme or plugin behaves unexpectedly.
• Integrate private licensed updates and product lifecycle controls with the rest of the Digiter ecosystem.

Typical operating workflow

• Enable basic page caching first and measure the site before activating several optional optimizations at the same time.
• Exclude pages that must remain personalized, transactional or highly dynamic, such as account, cart, checkout or other user-specific endpoints.
• Confirm that content edits correctly invalidate the pages that reference the changed information.
• Configure warm-up for important public content and observe server load during the first full cycle.
• Add frontend optimization features gradually, testing navigation, forms, menus, sliders and interactive scripts after each meaningful change.
• Use diagnostics or recovery controls immediately if an optimization causes layout or JavaScript problems instead of layering additional fixes on top.
• Retest performance after theme, CDN, server-cache or major plugin changes because the optimal combination can change with the surrounding stack.

Where the product fits

• Improving repeat page delivery on content-heavy WordPress sites where most public visitors receive the same rendered page.
• Reducing PHP/database work on small servers by serving cached anonymous pages when personalization is not required.
• Warming important pages after content updates so the first real visitor is less likely to pay the full generation cost.
• Consolidating common frontend performance controls into one administration interface with a recovery path.
• Tuning a site where performance must improve without hiding checkout, account or other dynamic states behind a public cache.

Operational considerations

• Performance should be measured from a known baseline. A lower synthetic score after one isolated test does not always mean the real site became slower, and a higher score does not guarantee every visitor workflow still works.
• Caching personalized or transactional pages can expose incorrect state. Exclusions are therefore more important than maximum cache coverage.
• Warm-up generates real requests and consumes CPU, PHP and network resources. Aggressive concurrency can be counterproductive on smaller servers.
• Asset optimization can interact with theme or plugin JavaScript. Troubleshooting should begin by disabling the most recent optimization rather than clearing every unrelated setting.
• CDN, host-level cache, reverse proxy and plugin page cache can overlap. Administrators should understand which layer owns invalidation to avoid serving stale content.

Compatibility and environment

• The plugin is intended for standard modern WordPress sites, but ecommerce, membership, LMS and heavily personalized applications require careful exclusions.
• Server-level caching or managed-hosting acceleration can coexist only when purge and bypass behavior remain coherent. Two independent full-page caches can make troubleshooting difficult.
• JavaScript delay, CSS handling and media optimizations should be tested with the actual theme and page builder because front-end dependencies vary between sites.
• Logged-in users and administrative requests should not be treated the same as anonymous public traffic unless the product explicitly supports that scenario.

Recommended best practices

• Change one major performance category at a time and test before moving to the next.
• Protect carts, checkouts, account pages, previews and other personalized URLs with explicit cache exclusions.
• Use a realistic warm-up scope instead of crawling every low-value archive page on a resource-limited host.
• After a theme or plugin update, check the pages with the most JavaScript interaction before assuming the previous optimization profile is still ideal.
• Keep a documented recovery configuration so performance tuning can be rolled back quickly during an incident.

Privacy, security and implementation boundary

Page caching is designed to operate locally on the WordPress installation unless the administrator deliberately configures an external CDN or service. Administrators must not cache authenticated or personalized responses in a way that exposes one visitor's information to another. Proprietary cache ownership, invalidation, warm-up pacing and adaptation logic is not published because those mechanisms are part of the product implementation.

Support and troubleshooting

For stale pages, broken assets or unexpected cache behavior, contact [email protected] with the affected URL, whether the visitor was logged in, active cache/CDN layers and the optimization category recently changed. A clear reproduction sequence is more useful than a general speed-test screenshot alone.

Digiter Smart Cloud

A complete private browser workspace combining Cloud Desktop, Mail, Calendar, Writer, media viewing and administrator-controlled storage.

Product overview

Digiter Smart Cloud turns a WordPress installation into a dedicated browser workspace for authorized users. It is designed as a desktop environment rather than a simple file list: users can work with private files, open multiple application windows, write documents, use a calendar, connect standards-compatible email accounts, preview media and personalize the desktop from one authenticated Cloud interface.

Each authorized user receives an isolated storage context. Administrators define how many Cloud users may be active, set the default storage quota and can override the quota for individual users. The current Smart Cloud release uses a 16 GB default quota per user, while the actual value can be adapted by the administrator to the server capacity and the needs of each account. Quotas are enforced by the Cloud application and remain subject to the physical free space of the underlying server.

The hosted Monthly service and the self-hosted Lifetime plugin are intentionally separate commercial models. Monthly access is tied to a verified Digiter Account and provides the hosted Cloud Desktop on Digiter.org while the paid service remains active. The Lifetime offer is a domain-bound self-hosted plugin license and does not automatically grant access to the Digiter.org hosted Cloud service.

Smart Cloud is an actively maintained Digiter product. The workspace is developed through continuing releases that refine browser compatibility, window behavior, productivity tools, mail integration, security boundaries, reliability and the overall desktop experience. New or improved capabilities can be delivered through maintained releases according to the customer's active service or update entitlement.

Core capabilities

• Provide a dedicated full-screen Cloud Desktop for authorized ordinary users while administrators retain the normal WordPress administration environment.
• Keep every user's files in a private storage context outside the normal WordPress Media Library and scope file operations to the authenticated Cloud user.
• Offer upload, download, folders, search, rename, copy, delete, color organization, drag & drop, Back/Forward navigation and mouse/touch context-menu workflows.
• Keep deleted items in a desktop Trash with restore, permanent delete and Empty Trash actions instead of immediately destroying recoverable files.
• Open several Writer documents, images and PDF files simultaneously in independent desktop windows with focus, movement, resize, maximize/restore and close controls.
• Preview supported images, PDFs and videos inside the Cloud and play audio with authenticated streaming and timeline seeking.
• Combine storage, productivity and communication tools in one authenticated browser workspace rather than requiring users to enter wp-admin or the hosting control panel.

Integrated workspace applications

• Digiter Mail: a responsive three-pane mail client with multiple accounts, folders, inbox, message reader, reply, unread and delete actions.
• Digiter Mail uses standards-based IMAP4 for incoming mail and SMTP for outgoing mail, supports SSL/TLS and STARTTLS, and includes presets for Gmail, Microsoft/Outlook, Yahoo and iCloud plus manual settings for standards-compatible Plesk, cPanel and other mail servers.
• Each Cloud user can connect up to 10 separate mail accounts. Mail account records and IMAP operations remain scoped to that Cloud user, and saved mail passwords are encrypted at rest and are never returned to the browser.
• Mail attachments can be sent and downloaded within defined safety limits, while HTML email rendering blocks remote tracking images until the user explicitly chooses to show them.
• Cloud Writer: rich private documents with headings, fonts, text size and color, emphasis, alignment, lists, links, embedded raster images and tables.
• Cloud Writer supports autosave and manual save, word and character count, revision-conflict protection between browser windows, DOCX preview/import, DOCX export and browser Print / Save as PDF.
• Calendar: a built-in taskbar calendar with month navigation, complete month grid, date selection and a Today shortcut for fast everyday reference without leaving the Cloud Desktop.
• Cloud Viewer / Player: image zoom, rotation, reset and full-screen controls, PDF/video preview, and audio playback with authenticated streaming.

Desktop customization and window experience

• Choose the Cloud Desktop wallpaper from the Settings area so the workspace can be personalized for the user or organization.
• Adjust desktop grid spacing and icon size to fit different display sizes, working styles and accessibility preferences.
• Move and resize managed application windows from their title bars, edges and corners; maximize or restore them and keep several supported windows open at once.
• Remember supported window geometry per user/browser so the workspace can return to a familiar working layout.
• Use distinct visual file icons for folders, images, audio, archives/packages, video, PDF, spreadsheets and other supported file categories.

Storage capacity and quota administration

• Administrator defines the maximum number of Cloud users and the default storage quota assigned to users; the current factory default is 16 GB per user.
• Individual users can receive quota overrides, allowing different storage sizes for different accounts instead of forcing one fixed capacity on everyone.
• Quota limits are enforced during uploads, copies and Writer/text-document saves so the application does not intentionally exceed the user's assigned capacity.
• Smart Cloud reports server free and total disk space, all-time transfer counters and per-user uploaded/downloaded transfer statistics to help administrators plan capacity.
• The application supports files up to 2 GB each, while the effective real-world upload maximum can be lower when PHP, Nginx, Apache, a reverse proxy or the hosting provider imposes a smaller request limit.
• Administration diagnostics warn about non-writable storage, unreadable disk capacity, low free space, quotas that exceed physical server capacity and HTTP upload limits below the Cloud file ceiling.

Typical operating workflow

• Install and configure Smart Cloud, confirm the private storage path is writable and review the server capacity and effective upload limit before inviting users.
• Set the maximum Cloud user count and a sensible default quota, then apply individual quota overrides where a user needs more or less storage.
• Create or verify the WordPress/Digiter account relationship and grant Cloud access through the intended entitlement mechanism rather than relying on the Subscriber role alone.
• Log in with at least two ordinary test accounts and verify storage isolation, quota enforcement, uploads, downloads, Trash/restore and folder workflows.
• Open Writer, Calendar, viewers and multiple desktop windows to confirm the workspace behaves correctly in the browsers that will be used in production.
• For Digiter Mail, connect a test mailbox, verify IMAP folder discovery and SMTP sending, and confirm the provider's TLS, app-password or standard authentication requirements independently from Cloud storage authorization.
• Monitor free disk space, transfer volume and user quotas as adoption grows, and adjust quotas before the physical server becomes constrained.

Where the product fits

• Providing customers, employees or project members with a private browser workspace without giving them wp-admin, FTP or hosting-panel access.
• Combining private files, document writing, calendar reference and everyday email access in a single authenticated desktop-style environment.
• Running a self-hosted private workspace on a licensed WordPress domain where the owner controls users, quotas, storage capacity and server policy.
• Providing different users with different storage capacities while keeping all Cloud access under one administrator-controlled system.
• Keeping multiple documents, images and PDFs open side by side for a more desktop-like working flow inside the browser.

Operational considerations

• Cloud reliability depends on the underlying server disk, filesystem permissions, PHP limits, web-server limits and outbound network permissions. The plugin can detect or report many constraints but cannot create physical server capacity.
• Configured quotas are logical limits, not physically pre-reserved disk partitions. Administrators must leave enough real free disk space for all users and for WordPress/server operation.
• Large uploads can be rejected before WordPress receives them when PHP, Nginx, Apache, a proxy or the host is configured below the intended size.
• Digiter Mail depends on standards-compatible IMAP/SMTP access, valid server certificates and permitted outbound TCP connections. Some providers require an app password or separate IMAP access setting.
• Hosted Monthly access is an Account entitlement, not a generic WordPress role capability. The Subscriber role by itself never grants Smart Cloud access.
• User isolation must remain intact during custom integrations; administrators should not expose private Cloud storage through unrelated public URLs or manually shared server paths.

Compatibility and environment

• The Cloud Desktop requires a modern JavaScript-capable browser and reliable authenticated WordPress AJAX/application requests.
• Writer DOCX preview, import and export additionally use common PHP DOM and ZipArchive capabilities; Writer itself and browser Print / Save as PDF can continue without DOCX conversion features when those extensions are unavailable.
• Digiter Mail requires OpenSSL and outbound connections to the selected IMAP/SMTP ports. Standards-compatible Plesk, cPanel, Dovecot, Courier, Postfix and Exim environments can be used when correctly configured.
• Reverse proxies and aggressive page caches must not cache authenticated Cloud responses as public content.
• Browser drag-out behavior can differ by browser and operating system; Chromium and Firefox use different safe download paths while Cloud-internal drag/drop remains supported.

Recommended best practices

• Choose quotas based on real server capacity and expected growth, then review free disk space periodically instead of treating quota totals as reserved storage.
• Use individual quota overrides for heavy or light users rather than increasing the global default unnecessarily.
• Test Cloud isolation with multiple non-administrator accounts before production use and after major access-control changes.
• Keep WordPress, Smart Cloud and the hosting stack updated so browser, security and compatibility improvements can be applied.
• Keep independent backups of important user files and application data even when Trash/restore is available.
• Never send mailbox passwords, WordPress passwords, signing keys or server credentials in ordinary support email.

Continuous development & innovation

• Digiter Smart Cloud follows an active maintained-release model rather than being treated as a finished static file manager.
• Ongoing work focuses on practical innovation: richer browser applications, better desktop interaction, stronger cross-browser behavior, safer communication workflows and more polished user experience.
• Releases can refine existing features such as Writer, Mail, Calendar, window management, drag/drop, previews, Trash and desktop customization as real-world usage exposes opportunities for improvement.
• Compatibility work continues as WordPress, PHP, browsers and hosting environments evolve, with maintained releases used to address supported-platform changes where appropriate.
• Product documentation is intended to evolve with maintained releases so customers can understand important new capabilities without exposing proprietary or security-sensitive implementation details.
• Access to a particular maintained release or hosted capability remains governed by the purchased plan, active service period and applicable update entitlement.

Privacy, security and implementation boundary

Smart Cloud can store user-provided files, Writer documents and account-related service configuration, including encrypted mail credentials when Digiter Mail is used. Hosted access is account-specific and user storage is intended to remain isolated. Mail passwords are encrypted at rest and are not returned to the browser. Privacy-oriented mail rendering blocks remote tracking images until the user chooses to load them. Documentation deliberately does not expose storage-path hardening, authorization internals, cryptographic material, token handling or other security-sensitive implementation details.

Support and troubleshooting

For access, storage, quota, upload/download, Writer, Calendar, desktop, viewer or Digiter Mail issues, contact [email protected] with the affected Account email, Smart Cloud version, browser and a clear reproduction sequence. For mail issues include the provider/server type and connection mode, but never send mailbox passwords, WordPress passwords or server credentials in an ordinary support email.

Digital Content Compression Pro

Local media compression, next-generation formats and Core Web Vitals-oriented image optimization.

Product overview

Digital Content Compression Pro is built for WordPress sites where image weight and delivery have a measurable effect on page speed, bandwidth and visitor experience. It can process uploaded images and generated thumbnails, create optimized alternatives and manage larger libraries through queued or bulk work rather than forcing an administrator to optimize every file manually.

The product is designed around controlled local processing. It can preserve originals according to configuration, generate next-generation formats such as WebP or AVIF when supported and adapt processing pressure to the hosting environment. The goal is not simply the smallest possible file at any cost; the workflow balances visual quality, compatibility, CPU usage, recoverability and the practical performance needs of the site.

Core capabilities

• Compress eligible uploaded images and WordPress-generated thumbnail sizes according to configured quality and processing rules.
• Optionally resize oversized media and clean selected metadata when the administrator chooses those behaviors.
• Generate WebP and AVIF alternatives for supported image types and browsers when the required server capabilities are available.
• Process an existing media library through queued or bulk optimization with locking, retry and progress handling rather than one extremely long request.
• Preserve original media where configured so an administrator has a recovery path after an aggressive optimization decision.
• Adapt background processing pace to available PHP/server capacity so stronger hosts can process more work while constrained hosts remain more conservative.
• Provide LCP, CLS, lazy-loading and media-delivery controls intended to reduce image-related contribution to Core Web Vitals problems.

Typical operating workflow

• Review server capabilities and backup policy before enabling automatic processing on a large production media library.
• Choose image quality, resize, metadata and original-preservation settings with a small group of representative images first.
• Enable next-generation format generation only after confirming that the server has the required codecs and the delivery method works with the active stack.
• Run a controlled bulk optimization and monitor processing speed, failures, disk use and front-end image quality.
• Test important visual areas such as hero images, galleries, product images and responsive thumbnails on several devices.
• Use restore/original controls if an image was compressed too aggressively or an unexpected format interaction occurs.
• After theme, CDN or image-delivery changes, confirm that the optimized variants being generated are also the variants visitors actually receive.

Where the product fits

• Reducing the storage and transfer cost of a WordPress media library containing many large camera or design exports.
• Creating WebP/AVIF alternatives so modern browsers can receive smaller image formats without replacing every media reference manually.
• Processing an established site in batches rather than re-uploading years of existing images.
• Improving image-related LCP or layout behavior while keeping recovery copies available.
• Keeping media processing on the WordPress/server environment when the administrator prefers not to send original images to an external compression SaaS.

Operational considerations

• Compression quality is subjective and depends on the source image. Administrators should test photographs, logos, text-heavy graphics and transparent images separately.
• Generating additional formats can temporarily increase disk use because originals, standard derivatives and next-generation variants may coexist.
• AVIF/WebP support depends on the image libraries available to PHP or the server. The plugin cannot generate a format that the hosting environment cannot encode.
• Bulk processing consumes CPU, memory, disk I/O and time. Hardware-aware pacing reduces risk but a very large library should still be processed during a suitable maintenance window.
• Lazy-loading and LCP-related changes should be validated visually. The first prominent image on a page may need different treatment from below-the-fold content.

Compatibility and environment

• The plugin operates within WordPress media workflows and therefore inherits the image capabilities of the active PHP/server libraries.
• CDNs or external image services can override local delivery. If another layer rewrites images, confirm which system is responsible for the final format seen by visitors.
• Page builders and themes may generate unusual responsive markup or custom image sizes; test those templates before applying aggressive global settings.
• Backup or migration tools should include any optimized variants that the live site depends on, or the variants should be regenerable after restore.

Recommended best practices

• Keep originals until the chosen quality settings have been visually verified across representative content.
• Optimize in controlled batches on very large libraries and monitor free disk space during the first full run.
• Do not chase file size alone; use a quality level appropriate for the content and audience.
• Exclude or treat logos, line art and text-heavy graphics differently when photographic compression settings produce visible artifacts.
• Measure real page delivery after optimization to confirm that the generated formats and loading strategy are actually improving the target pages.

Privacy, security and implementation boundary

Image processing is designed to run locally on the WordPress installation unless an administrator deliberately configures another delivery or storage layer. Media files can contain personal information in the image itself or embedded metadata, so metadata-removal settings should be chosen with the site's purpose and retention obligations in mind. Compression heuristics, internal quality decisions and workload adaptation logic remain proprietary.

Support and troubleshooting

For failed jobs, unsupported formats, unexpected visual artifacts or bulk-processing issues, contact [email protected] with the media type, approximate dimensions/file size, server capability shown by diagnostics and the processing step that fails. A small non-sensitive example image can be useful when reproducing a quality problem.

Licensing, updates, support and ownership

A Digiter purchase grants the usage entitlement described by the selected product plan. It does not transfer copyright, source code ownership, trademarks, design rights, private signing material or proprietary implementation knowledge. Lifetime plans, where offered, refer to the stated software-use entitlement; update periods are shown separately in the Shop and purchase record.

Hosted Smart Cloud Monthly is an Account-bound service and is operationally different from a downloadable domain license. Standard plugin purchases may be completed as a guest where the Shop allows it, while Account-based purchases can remain associated with the verified Digiter Account.

Protected downloads and private updates are delivered through the Digiter Shop licensing system. Customers should retain their purchase email and license information and should not publish license keys publicly. For setup, licensing, delivery, update or product questions contact [email protected]. Digiter Team will investigate verified issues and work with the customer toward a practical resolution.