Automatic creation and deployment of websites

Abstract

Methods, systems, and techniques are provided for deploying target websites, particularly those created using third-party content management systems ("CMS") for developing websites such as WORDPRESS. Example embodiments provide a CMS deployment system ("CDS") or CMS deployment application ("CDA") that enables a user to create content locally using all the resources of the CMS, and then manage and deploy the target website using a version control process and in a more secure form on a target server. In one embodiment, the CDS / CDA exports the CMS website instance as flat HTML files, manages these files using a version control system, and then deploys them on a target server without requiring user expertise. An example CDS / CDA includes an installation facility, an export facility, and a deployment facility that cooperate to deploy a secure website created using standard CMS tools.

Description

Technical Field

[0001] This disclosure relates to methods, techniques, and systems for automatically deploying content for a website, and more particularly to methods, techniques, and systems for automatically deploying content from a content management system in a lightweight environment. Background Technology

[0002] Content Management Systems (“CMS”) enable non-professional users to create websites with complex text and graphic content. For example, a CMS environment like Wordpress is very popular, partly because it's distributed as “open source,” meaning it's free when someone hosts their own website (on their own server). Furthermore, there are abundant resources available for learning how to deploy websites, ranging from plugins to templates, tutorials, and more. From a user's perspective, it's easy to install, set up, configure, and customize. It allows external personnel to write content and allows website administrators to assign different roles (editors, contributors, etc.) to them as needed.

[0003] One of the drawbacks and problems of using WordPress and other similar CMS environments to create and deploy websites is that the software, including plugins, templates, or other resources, can be very resource-intensive. When a website supports a few hundred visitors per month, resource consumption may not be a real issue. However, when that number is exceeded, as is common in production websites, resource consumption can become problematic, leading to severe latency, poor performance, and other issues. One solution is to purchase more powerful equipment. Another is to use a caching system to cache frequently used pages and resources. However, such solutions still require powerful servers to handle the workload, which can be expensive and, in some cases, prohibitively costly.

[0004] Another drawback and problem of websites deployed using WordPress and other open-source environments is the lack of security. Because the environment is open source and therefore used on millions of websites, it is vulnerable to attacks, as evidenced by stories of WordPress vulnerabilities exploited by hackers. These vulnerabilities are often caused by plugins or installations that are not kept up-to-date. Using add-ons such as WordPrism can solve these problems. Furthermore, keeping CMS installations and plugins up-to-date, enforcing strong passwords, etc., mitigate some vulnerabilities, but still require more resources to defend against potential attacks. Additionally, maintaining a single CMS installation may not require much work, but these solutions do not scale well. For hundreds or thousands of websites, keeping all WordPress installations updated can be extremely time-consuming and costly. Summary of the Invention Attached Figure Description

[0005] This patent or application document contains at least one color drawing. A copy of this patent or application disclosure with color drawings will be provided by the office upon request and payment of the necessary fees.

[0006] Figure 1 This is a block diagram of an example CMS deployment application environment using the technologies, methods, and systems described in this article.

[0007] Figure 2 This is a sample flowchart outlining the improved website development and update process for creating and deploying a target website using a sample CMS deployment application environment.

[0008] Figures 3A-3U This is a sample screen display of the sample user interface for performing website development and deployment based on the sample CMS deployment application environment described in this article.

[0009] Figure 4 This is a sample block diagram of the components for deploying an application instance in the example CMS.

[0010] Figure 5 This is an example block diagram of a computing system used in an embodiment of CMS deployment system / application.

[0011] Figure 6 This is a sample flowchart of a sample website creation and content management system installation routine provided by the installation facility for the CMS deployment system / application to initially set up the website using a local CMS instance for creating the target website.

[0012] Figure 7 This is a sample flowchart of a version control routine provided by the installation facility of the CMS deployment system / application to create an initial version of the target website, which is then used when exporting the website.

[0013] Figure 8 This is a sample flowchart of the workflow for exporting CMS content in a new version of a target website, provided by the export facility of the CMS deployment system / application.

[0014] Figure 9 This is a sample flowchart of the workflow for deploying a target website on a target server, provided by the sample deployment facility of the CMS deployment system / application. Detailed Implementation

[0015] The embodiments described herein provide enhanced computer- and network-based methods, technologies, and systems for deploying target websites, particularly those created using a third-party content management system (“CMS”) for website development, such as Wordpress. Example embodiments provide a CMS deployment system (“CDS”) or CMS deployment application (“CDA”) that enables users to create content locally using all the resources of the CMS, and then manage and deploy the target website more securely on the target server using version control processes.

[0016] In the example implementation, CDS / CA instantiates each instance of the CMS locally and isolates each instance from other CMS instances that may be running on the same computing system. Users are able to add and manage content in the CMS instance in the same way they typically interact with the CMS. Then, when the target website is complete, an authorized user (e.g., a user with administrative privileges) can export the website as a secure form, which can then be deployed to the target server. Using CDS / CDA reduces the attack vector for a target website by deploying it as a flat HTML file, rather than incorporating all or even a portion of the resources typically required to run a website created by the CMS environment. For example, in the example CDS / CDA, the export facility creates a flat HTML file of the target website, and the deployment facility then transfers the target website to a remote server by, for example, redirecting references (e.g., links) when needed and copying the file to a remote server. The CDS / CDA export facility typically determines all the HTML needed to display the pages of the website by “scraping” the CMS website and then automatically loading missing resources, renaming paths as needed, etc. Furthermore, the sample CDS / CDA provides a simplified user interface, allowing deployment of the target website in a single user interface operation. This simplified interface allows users to export websites created using CMS tools in a single user interface operation. Once content is created / modified, this allows the website to be "automatically" "upgraded" with the revised content in response to a single user operation.

[0017] Figure 1This is a block diagram of an example CMS deployment application environment using the techniques, methods, and systems described herein. The CMS deployment system (“CDS”) provides an instance of a CMS deployment application (“CDA”) 101 that runs locally on a computer system (e.g., a local server). CDA 101 is responsible for creating one or more content management system (“CMS”) environments to create one or more target websites (not shown), which can ultimately function as public websites accessible to one or more users 103a-103c via a communication network 110 (such as the Internet) on a remote server / computing system 130a-130c. CDA 101 manages one or more CMS environments, including allowing users 103a-103c to configure one or more websites 104 (each using a CMS instance), target servers 105, and / or user access permissions 106. CDA 101 also communicates with data repositories 120a-120b to store the CMS (website) content (including resources and other data) of each website created by the CMS, and communicates with remote servers 130a-130c to export and deploy the created target websites. Using configured user access information 106, different users with potentially different permissions can act as administrators, editors or content providers, designers, etc. Each CMS environment configured as website 104 is an independent processing environment, so that changes to one website will not interfere with changes to another website or the content of one website will not interfere with the content of another website. Once the website content is complete, CDA 101 can export the target website (locally) to one or more flat HTML files (potentially stored in data repositories 120a-120b or a separate repository), and then deploy the target website to one of the remote servers 130a-130c via network 110.

[0018] Figure 2 This is a sample flowchart outlining an improved website development and update process for creating and deploying a target website using a sample CMS deployment application environment. The improved website development process 200 can be provided by one or more components, modules, or facilities within the sample CDA instance. In general, in box 201, the CDA identifies or configures at least one remote server for hosting the target website. For example, this configured server could be... Figure 1 One of the target servers configured in the configuration is 105. In box 202, the CDA receives instructions from a user (typically a user with administrative privileges) regarding the target website. For example, the target website could be... Figure 1One of the websites configured in box 104. In box 203, CDA automatically installs the instance of the CMS being used (specified or default), sets up version control for the target website, and associates the target website with the target server. Once the CMS instance for the target website is set up, in box 204, content is received from one or more users using standard CMS interfaces (e.g., in Wordpress, users create posts, use templates, etc.). Sample CDA 101 can support more than one type of CMS, and because each CMS operates within its own environment, CDA is scalable. (For example, there may be two different or identical CMS instances executing as part of CDA 101). After a period of time, in box 205, once the target website content is considered sufficiently complete for publication (e.g., users typically decide the site is ready for public release), the user (typically a user with administrative privileges) can automatically export the website to create a target 'format'-flat HTML file for the website. In the sample environment, CDA automatically exports the website by processing it to generate the HTML file without further user commands, by touching a single user interface control (e.g., a button). However, in some sample CDAs, users may be required to verify or correct specific information. Then, in box 206, the CDA exports the website to the target location on an associated remote server. In some sample CDAs, users have the opportunity to verify the content of the target website before it is exposed (deployed on a public communications network).

[0019] The significance of CDA's automation lies in the fact that, once given appropriate instructions for exporting or deploying, CDA takes care of transforming CMS content into a directly executable form (flat HTML files) on the remote server. In the example CDA, this transformation is accomplished using tools that crawl and correct the content to load and / or reference missing information or resources. Any such corrections to make the content executable are also handled by CDA. Therefore, after creating, updating, or modifying content using a content management system, almost no user expertise is required to deploy the target website.

[0020] Figures 3A-3R These are sample screen displays from sample user interfaces used in the sample CMS deployment application environment described herein to perform website development and deployment. These screen displays are captured from an example embodiment of a CDA called "OneClick". Other screen displays of this CDA or another example CDA may have equivalent features or may be implemented using techniques different from those described herein or in a different arrangement than those described herein, to still achieve similar or equivalent functionality.

[0021] Figure 3AThis is an example of a control panel screen display 301 presented by CDA when CDA begins. Control panel screen display 301 includes: a list of websites with user interface (“UI”) controls (or UI elements) 302 for configuring (e.g., viewing, editing, or specifying) them; a list of servers with UI controls 303 for configuring them; and a list of users that can be configured via UI controls 304. (The last sentence appears to be incomplete and possibly refers to a selection process.) Figure 3A When a UI control in the middle returns a 303 error, such as Figure 3B The screen display 310 presents a list of servers configured so far. The list includes: the name of each server 311, which website 312 is associated with each server (e.g., IP address), and user interface controls, including edit or delete buttons 314 for each server. Users can configure new servers for CDA using the "Create Server" UI control 313.

[0022] Once the server UI control 313 is selected, such as Figure 3C As shown, screen display 320 displays information about the corresponding server in a set of editable user interface controls (e.g., text editing fields). For example, the user can edit the server name 321, specify the protocol 322 used for file transfer (e.g., "ftp"), the hostname of the target website 323, the server port and path 324, and the certificate 325 used to access the server.

[0023] When the "Save" UI control 326 is selected, CDA displays information about the newly configured server, such as... Figure 3D The display screen 330 is shown. In display 330, CDA presents the hostname access path (reflecting the protocol, domain, port, etc.) and the access username and password, as shown in field 331. Example notification 332 indicates that the target website has not yet been linked to the newly created (configured) server.

[0024] exist Figure 3A In addition, users can configure the website using the control panel screen display 301 by selecting the "Website" UI control 302. Users can also configure other UI controls such as UI control 304. Figure 3A The control panel screen displays the user permissions shown in 301.

[0025] After selecting the website UI control 302, such as Figure 3EAs shown, the screen then displays a list of websites 347 configured so far. This list includes: the name 341 of each website, the URL associated with that website 342, an indication of which configured server 343 is associated with that website, a website version status indicator 344, and a set of user interface (UI) controls 345. These UI controls include: access to the front-end (UI) of the CMS instance for that website, access to the back-end (UI) of the CMS instance for that website, and a preview of the website using the CMS instance. The user uses the "Create Website" UI control 346 to configure and initialize the creation of a new website.

[0026] Once the website UI control 346 is selected, such as Figure 3F As shown, screen display 348 displays information about the corresponding website in a set of user interface controls (e.g., text editing fields), which can be edited in a manner largely similar to editing server information. For example, a user can edit the name used to identify the website to the CDA instance, the website's live URL (or Uniform Resource Identifier URI) (on the local server), and the language used to install the CMS where applicable.

[0027] In selection Figure 3F When using the "Save" UI control 346 in the middle, such as Figure 3G As shown, CDA displays information about the newly configured website, for example, on screen 347. Users can also use the "Install" UI control 335 to install an instance of the corresponding CMS, enabling the creation and editing of website content and CMS configuration. As indicated by notification 334, there is no available export version of the website at this time because it has not yet been exported (to a flat HTML file) and therefore has not yet been deployed to the associated server. Furthermore, notification field 336 indicates that the installation is in progress. See below. Figure 6 and Figure 7 Describe the example installation process.

[0028] Figure 3HThe CDA display screen 350 shows the site after CMS installation is complete. Once installation is complete, it displays details of the website (website name 351), an indication of the current version of the installed CMS (359), and a list of activities relative to the target website (353). Since the CMS instance installation is now complete, UI controls for accessing the CMS (including the "Frontend" UI control (355) and the "Backend" control (356)) are available to navigate the user to the CMS's standard user interface. The CDA also displays an "Edit" UI control (354) for editing website details; an "Export" UI control (357) to begin the export process to produce a formatted file (flat HTML); and a "Preview" UI control (358) to display the website created so far. (Selecting the Preview UI control (358) before adding content can display default and / or template content.) For example, selecting the Frontend UI control (355) (or the Preview UI control (358) at this time) can display... Figure 3I The display screen 360 is shown in the image. Selecting the backend UI control 356 will display... Figure 3J The display screen 361 shown is a standard CMS interface for adding content (such as adding new "posts") to a newly configured website.

[0029] For example, in Figure 3K In the middle, CDA displays the corresponding CMS instance's display screen 362. Here, the user selects UI control 363 to edit or view a "post" on a website named "example.com". Display screen 362 shows the standard WORDPRESS interface for editing posts. It shows the post title "Hello world!" being edited in the edit field 364 into the proposed title "Hello Everyone!". The proposed title "Hello Everyone!" is as follows. Figure 3L The edit field 364 is shown in the display screen 365.

[0030] Once editing is complete, the user can select the "Update" UI control (not shown) to save the edits, and then select link field 367 (or its equivalent in other CMS environments) to preview the newly created post, as it will eventually be made available to the public. Figure 3M As shown in the image, notification field 368 indicates that this is a standard Wordpress post with published information.

[0031] After making the desired modifications, the user (typically a user with administrative privileges) can process the changes to export the website and deploy it to the target server. Figure 3NThis is a sample display screen 370 of the CDA after new content is available for export. Here, the user can select the "Export" UI control 371 to begin the export process. Figure 3O In the CDA interface, dialog control 371 prompts the user to describe what has changed and confirm the desired export. The user can select the "Start Export" UI control 373 to begin the export process. Figure 3P As shown, when UI control 373 is selected, CDA indicates that the export process is in progress (without further user intervention) via the "busy icon" in the export UI control 375. Selecting the preview UI control 358 (see...) Figure 3H )get Figure 3Q The screen shown displays 376. The display is similar to... Figure 3I The display is shown in the image; however, note the changes in the post title and the updated posting information.

[0032] As mentioned earlier, the export facility is responsible for converting the website created by the CMS into a more deployment-friendly format, in this case, a flat HTML file. See below. Figure 8 The example export process is described further.

[0033] Once the export process is complete, the sample CDA provides users with the opportunity to approve or verify the website changes described in Version Notification 380 using the "Approve" UI control 378. Figure 3R As shown in display screen 377. Alternatively, the user can use the "Reject" UI control 379 to reject the change.

[0034] Figure 3S The example CDA display screen 381 is shown after the user has approved the new version changes. The review status indicator 382 indicates that the changes have been approved. Display screen 381 indicates to the user that the version is ready for deployment by adding a "Deploy" UI control 383 to display screen 381. After selecting the deployment UI control 383, CDA displays a confirmation dialog box to the user, such as... Figure 3T As shown. After selecting the confirmation UI control 384, CDA begins the deployment process (e.g., via...). Figure 1 The communication network 110 in the middle deploys the production files to the target server for public release.

[0035] As mentioned earlier, the deployment facility is responsible for transmitting the production-formatted website to the target server using the configured protocol, for example, such as... Figure 3C As shown below. Figure 9 The example deployment process is described further.

[0036] Figure 3U This demonstrates that the target website has been deployed to the target server and, for example, via... Figure 1The target website is publicly available after the network 110 is accessed.

[0037] Figure 4 This is a sample block diagram of the components of a sample CMS deployment application instance. In a sample CDA environment, a CMS deployment application (“CDA”) instance includes one or more functional components / modules that work together to perform the website management functions described so far, including creating / editing a website, exporting the website to an efficient and secure production form, and then deploying the exported website to the appropriate target server. Figure 4 The illustration shows CDA instance 401 when executed on a computing system (here referred to as the local computing system to distinguish it from a remote, publicly accessible server). It should be understood that CDA instance 401 may run physically or virtually on one of the computing systems also used to deploy a publicly accessible website.

[0038] Example CDA instance 401 includes: user interface 402, installation facility 403, export facility 404, and deployment facility 405. User interface 402 operates to allow one or more users to create / modify websites using one or more CMS instances, and then export and deploy them. For example, user interface 402 can operate to achieve the above-described... Figures 3A-3U The described display screen. Installation facility 403 is responsible for installing one or more instances of the (same or different) CMS environment. Execution instance 401 shows two CMS instances 408 and 409 as already installed, where their corresponding CMS (website) data is stored in one or more data repositories 440. Output facility 404 is responsible for converting (transforming, translating, configuring, etc.) the CMS-based website into a format suitable for the production environment. Production files are stored as exported CMS data in data repository 430. Some CDAs employ version control systems to help track website versions so that certain operations, such as rolling back to a previous version, can be performed more easily. As described, the exported format is currently implemented as a flat HTML file 435, although other formats may be suitable and supported in the future. The required feature of this format is the ability to run "lightweight"—that is, without requiring a CMS environment or its resources. Deployment facility 405 is responsible for finalizing the exported format for the target server, such as referring to the server by changing link and path names, and is responsible for copying the finalized code to the target server (e.g., one of the remote servers 450). Such a deployment facility 405 uses the FTP protocol to transfer files and code, but it can also support other protocols, such as SSH (SFTP) and others.

[0039] In some examples, CDA instance 401 also includes queue management 407 for asynchronous processing of functions to allow for greater responsiveness and coordination across various facilities. See, for example, the following... Figures 6-9 As further described, various facilities can use queue management facility 407 to queue certain operations, such as CMS instance installation, (during export) generation of production files, etc.

[0040] CDS / CDA technologies are generally applicable to the creation, management, export, and deployment of any type of content. Furthermore, while the examples described herein are generally related to Wordpress, the technologies described herein can also be used with other CMS environments, such as Drupal, Joomla, or Expression Engine. Similarly, any PHP-based or MySQL-based CMS can operate with the examples described herein. Moreover, the concepts and technologies described can be applied to other production formats and protocols. Also, while certain terms are used primarily herein, other terms are used interchangeably to produce equivalent embodiments and examples. Furthermore, terms may have alternative spellings that may or may not be explicitly mentioned, and all such variations of the terms are intended to be included.

[0041] The example embodiments described herein provide applications, tools, data structures, and other support for implementing a CMS deployment system or application to facilitate website creation and deployment, thereby reducing the expertise required for website deployment, creating more robust websites that are less susceptible to hacking, and requiring fewer resources. Other embodiments of the described techniques can be used for other purposes. Numerous specific details, such as data formats and code sequences, are set forth in the following description to provide a thorough understanding of the described techniques. The example embodiments described may also be practiced without some of the specific details described herein, or with other specific details (such as changes regarding the ordering of logic, different logic, etc.). Thus, the scope of the described techniques and / or functionality is not limited to the specific order, selection, or decomposition of the aspects described with reference to any particular routine, module, component, etc.

[0042] Figure 5 This is an example block diagram of a computing system used to implement an embodiment of a CMS deployment system / application. Note that one or more general-purpose virtual or physical computing systems or dedicated computing systems may be appropriately indicated for implementing CDS / CDA. Furthermore, CDS / CDA may be implemented in software, hardware, firmware, or a combination thereof to achieve the capabilities described herein.

[0043] Note that one or more general-purpose or special-purpose computing systems / devices may be used to implement the described technology. However, the fact that CDS / CDA can be implemented on a general-purpose computing system does not mean that the technology itself or the operations required to implement the technology are conventional or well-known.

[0044] The computing system 500 may include one or more server and / or client computing systems and may span distributed locations. Furthermore, each box shown may represent one or more such boxes as required by a particular embodiment, or may be combined with other boxes. Additionally, the various boxes of the CDS / CDA 510 may physically reside on one or more machines, which communicate with each other using standard (e.g., TCP / IP) or dedicated inter-process communication mechanisms.

[0045] In the illustrated embodiment, computer system 500 includes: computer memory (“memory”) 501, display 502, one or more central processing units (“CPUs”) 503, input / output devices 504 (e.g., keyboard, mouse, CRT or LCD display, etc.), other computer-readable media 505, and one or more network connections 506. CDS / CDA 510 is shown residing in memory 501. In other embodiments, some portions of the content of 510, some or all of the components of 510 may be stored on and / or transmitted via other computer-readable media 505. Components of CDS / CDA 510 preferably execute on one or more CPUs 503 and manage the generation, maintenance, and deployment of websites, as described herein. Other code or programs 530 and potentially other data repositories (such as data repository 520) also reside in memory 501 and preferably execute on one or more CPUs 503. It should be noted that... Figure 5 One or more of the components may not exist in any particular implementation. For example, some embodiments embedded in other software may not provide means for user input or display.

[0046] In a typical embodiment, CDS / CDA 510 includes: one or more user interfaces 514, one or more installation facilities 512, one or more export facilities 513, and one or more deployment facilities 514. Furthermore, CDS / CDA 510 typically includes: CMS data locally stored in a data repository 515 and exported versions of website code and data in a data repository 516. In some embodiments, one or more queue management facilities 518 are also provided. In at least some embodiments, access to the CDS / CDA is provided externally to the CDS / CDA and can potentially be obtained via a CDS application programming interface (API) 517 through one or more networks 550. Other and / or different modules may be implemented. Furthermore, CDS / CDA may interact via network 550 with application or client code 555 or with one or more client computing systems 560, which use exported website (production) formats and / or deployment formats for other functions, such as providing access to third-party version control systems. CDS / CDA can also interact with one or more third-party information provider systems 565 (such as purchasers of content used on the website and stored as CMS-accessible data in CMS data repositories 515) via network 550. Furthermore, it should be noted that data repositories 515 and 516 can also be provided outside of CDS / CDA, for example, in a knowledge base accessible through one or more networks 550.

[0047] In the example embodiments, standard programming techniques are used to implement the components / modules of CDS / CDA 510. For example, CDS / CDA 510 may be implemented as a "native" executable running on CPU 103 and one or more static or dynamic libraries. In other embodiments, CDS / CDA 510 may be implemented as instructions processed by a virtual machine. Generally, such example embodiments can be implemented using a range of programming languages ​​known in the art, including representative implementations of various programming language paradigms (including but not limited to object-oriented, functional, procedural, scripting, and declarative programming language paradigms).

[0048] See Figures 3A-3UIn one example implementation of OneClick CDA described, several known technologies and languages ​​are used to implement CDS / CDA 510, including PHP tools such as Laravel; NPM for Javascript and a package manager for integrating Javascript; SASS preprocessor for generating optimized CSS code; Webpack for bundling assets; Redis as a message broker; and Git as a version control system for tracking changes (including git-ftp for pushing changes to FTP servers such as target servers). In other implementations, other tools and technologies (including those that do not yet exist) can be combined similarly and equivalently.

[0049] The example embodiments described above can also utilize well-known or proprietary, synchronous or asynchronous client-server computing technologies. Furthermore, various components can be implemented using relatively independent programming techniques (e.g., as an executable program running on a single-CPU computer system), or alternatively, various structured techniques known in the art can be used to decompose the components, including but not limited to multi-programming, multithreading, client-server, or peer-to-peer methods running on one or more computer systems with one or more CPUs. Some embodiments can execute simultaneously and asynchronously and communicate using messaging techniques. Equivalent synchronous embodiments are also supported.

[0050] Furthermore, the programming interface for data stored as part of CDS / CDA 510 (e.g., in data repositories 516 and 517) can be obtained through standard mechanisms such as C, C++, C#, and Java APIs; libraries for accessing files, databases, or other data repositories; scripting languages ​​(such as XML); or web servers, FTP servers, or other types of servers that provide access to the stored data. Data repositories 515 and 516 can be implemented as one or more database systems, file systems, or any other technology used to store such information, or any combination thereof, including implementations using distributed computing technologies.

[0051] Similarly, the example CDS / CDA 510 can be implemented in a distributed environment comprising multiple, even heterogeneous, computer systems and networks. Different configurations and locations of programs and data are expected to be used with the techniques described herein. Furthermore, the CDS / CDA can be a physical or virtual computing system and can reside on the same physical system as the target server hosting the target website. Additionally, one or more modules themselves can be distributed, pooled, or otherwise grouped for reasons such as load balancing, reliability, or security. Various distributed computing techniques are suitable for implementing the components of the illustrated embodiments in a distributed manner, including but not limited to TCP / IP sockets, RPC, RMI, HTTP, Web services (XML-RPC, JAX-RPC, SOAP, etc.). Other variations are possible. Moreover, each component / module can provide additional functionality, or existing functionality can be distributed differently among components / modules while still achieving the functionality of the CDS / CDA.

[0052] Furthermore, in some embodiments, some or all of the components of the CDS / CDA 510 may be implemented or provided in other ways (such as at least partially in firmware and / or hardware), including but not limited to one or more application-specific integrated circuits (ASICs), standard integrated circuits, controllers that execute appropriate instructions and include microcontrollers and / or embedded controllers, field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), etc. Some or all of the system components and / or data structures may also be stored as content (e.g., as executable or other machine-readable software instructions or structured data) on a computer-readable medium (e.g., a hard disk; memory; network; other computer-readable medium; or other portable media articles to be read by an appropriate drive or via an appropriate connection, such as a DVD or flash memory device) to enable the computer-readable medium to execute or otherwise use or provide the content, thereby performing at least some of the described techniques. Some or all of the components and / or data structures may be stored on a tangible, non-transitory storage medium. Some or all of the system components and data structures may also be stored as data signals on various computer-readable transmission media (e.g., by being encoded as part of a carrier wave or included as part of an analog or digital propagated signal), and the data signals may take various forms (e.g., as part of a single or multiple analog signals, or as multiple discrete digital packets or frames). In other embodiments, such computer program products may also take other forms. Thus, embodiments of this disclosure can be practiced with other computer system configurations.

[0053] like Figures 1-4As described, one of the functions of CDS / CDA is to deploy and manage websites created / modified using standard content management systems such as Wordpress.

[0054] Figure 6 This is a sample flowchart of a sample website creation and content management system installation routine provided by the installation facility for a CMS deployment system / application, used to initially set up the website using a local CMS instance for creating the target website. This routine can be, for example, provided by... Figure 1 Part of CDA instance 101 Figure 4 The installation facility 403 is used for execution. See also Figure 3F As described in a sample CDS / CDA, CDS / CDA first creates a website configuration, then automatically installs a CMS instance locally in response to the user creating a website and selecting to install the UI controls. In general, for each new website created, CDS / CDA creates one or more corresponding records in the database, installs the corresponding CMS instance locally, and sets up version control for the new website. The website creation and CMS installation logic 600 creates all the folders required for the CMS and version control software. The local website is then ready for editing.

[0055] Specifically, in box 601, the website creation and CMS installation logic 600 first runs in the data storage repository (such as...). Figure 4 An instance of the website is created in the data store (440) within the CDS / CDA instance. In a sample CDS / CDA, each CMS instance has its own data store, thus isolating data between CMS instances. All new website details, such as website name, location (URI / URL), the server where the website will be deployed, language, etc., are stored. In box 602, logic 600 then adds the new website's identifier to the "Install" queue (e.g., by...). Figure 4The queue management facility 407 manages the queues to enable background workers (e.g., background tasks / processes / threads) to execute potentially time-consuming installation processes. In some example CDS / CDAs, a safety mechanism is implemented to prevent users from restarting the installation while it is already queued. Although shown in the same flowchart, it should be understood that, where appropriate, the appropriate installation queue handler (the background worker for installation) will asynchronously retrieve and process installation events from the queue. In box 603, the queue handler downloads the latest version of the specified CMS software (if needed), and in box 604, creates a new CMS configuration corresponding to the new website CMS instance. In box 605, the queue handler logic installs the CMS (e.g., WORDPRESS) core and configures the CMS core to include, for example, users with administrative privileges. In box 606, the queue handler logic creates / installs the CMS template and any default values ​​specified by the CDS / CDA. In some example CDS / CDAs, the default template is configurable. In box 607, the queue handler logic creates any additional users based on the new website configuration settings and / or default values. This logic assigns appropriate access permissions to each user. In box 608, after updating any other CMS configuration (not shown) (such as disabling certain features (e.g., comments)), the queue handler sends (forwards, reports, communicates, etc.) a notification of the new website's identifier, thus letting the user interface logic know that the new website has been created and knows the identifier for later access. In box 609, the queue handler logic then sets version control for the new website, as shown in [see section 609]. Figure 7 Further description: Once the version control settings are complete, the queue processing logic then sends a notification that the website installation process is complete. This notification, for example, allows the user interface to... Figure 3H The installation is complete, and the user interface is enabled to create / modify the content of a new website using the CMS user interface.

[0056] Figure 7 This is a sample flowchart of a version control routine provided by the installation facility of the CMS deployment system / application to create an initial version of the target website for use when exporting the website. This routine can be seen, for example, from [see...]. Figure 6The website creation and CMS installation logic described in section 600 is executed. As shown in the diagram, version control logic 700 first creates a version control repository specific to this CMS instance in box 701 (e.g., the directory could be located in a directory such as "... / .gitdirs / [WEBSITE_ID].git"). In the example CDS / CDA, Git version control is used, and two separate branches are created: a main branch and an export branch. The main branch is used for the "ready for deployment" version of the website (which is eventually released to the target server and used during the deployment process); the export branch is used for all exports created. The export branch is also used for... Figure 3H and Figure 3N The example user interface describes the "preview" mode. In box 702, version control logic 700 performs at least one "commit" on the main branch using a placeholder file that can be ignored, allowing the logic to create a second (export) branch. Other version control systems may not need this commit. In box 703, version control logic 700 creates the export branch and then ends.

[0057] Figure 8 This is a sample flowchart of a workflow for exporting CMS content in a new version of a target website, provided by the export facility of a CMS deployment system / application. This routine can be, for example, provided by... Figure 1 Part of CDA instance 101 Figure 4 The export facility returned a 404 error. See also... Figure 3N As described, in a sample CDS / CDA, after editing the website using the standard CMS user interface, the user can choose to export the UI controls so that the CDS / CDA export facility can convert the CMS website content into a production format more suitable for deployment. In the described sample CDS / CDA, this format includes flat HTML files, but other formats can be combined similarly and equivalently. In the sample CDS / CDA, in summary, CMS content is "fetched" using a crawling tool such as "wget," including files containing relevant assets such as images, scripts, and stylesheets, which are copied to the export branch, and file paths and other references are corrected as needed. Other crawling tools (including, for example, "aria2," "aget," "curl," "grab-site," and "wpul") can be combined similarly and equivalently. After the crawling tools are initially generated to correspond to the flat HTML for each page and copied to a new export branch, CDS / CDA loads each flat HTML page into a "headless" browser (without a UI) and then monitors browser events to detect resource loading and track any missing (status 404) resources. Then, CDS / CDA automatically post-processes the captured output and copies each of these missing files and assets from the CMS location to the export branch.

[0058] More specifically, Figure 8 The example CDS / CDA export facility workflow / logic 800 is shown. In box 801, logic 800 prepares the version control repository to include the new export branch. This may involve resetting certain aspects of the repository configuration and / or emptying the directory to clean up the export branch, removing unnecessary files and allowing CDS / CDA to detect changes between versions.

[0059] In box 802, export logic 800 generates a production format file – in this case, a flat HTML file. As mentioned, in the example CDS / CDA, this process is performed using a scraping tool such as wget, which allows CDS / CDA to download all CMS web pages as flat HTML files and store them as part of the CMS instance export branch.

[0060] In box 803, export logic 800 post-processes the flat HTML file (an instance stored in the export branch) to identify any missing files and resources by running the HTML in the headless browser. For example, some files and resources might not be detected by a crawler that doesn't execute Javascript, but rather dynamically loads them. Resources (such as lazy-loaded images, some pagination results managed using Javascript, etc.) might be missing because the crawler doesn't detect them. Even if the wget crawler handles recursive downloads (the homepage and all other pages linked to it), it won't find these files because they are dynamically loaded at a future time. Export logic 800 can listen for events in the headless browser to detect such missing files and resources, then locate and copy them to the stored export instance. For example, certain files will be searched, including the "robots.txt" file, the sitemap XML file which can be located if a sitemap index is found (the index can be searched to identify and export linked sitemap files), and any CMS-specific folders known to contain files imported into the local CMS instance (e.g., for WORDPRESS, the folder "wp-content / upload" contains all uploaded media files). Dynamic files can be identified by loading the exported instance into a headless browser (such as "phantomJS" or headless Chrome) and by retrieving a list of files that have been loaded after all scripts have been executed. This list is compared to the list of files already in the exported instance. If a file is missing, it is copied to the exported instance.

[0061] In box 804, export logic 800 post-processes resource names, links, file names, etc., to adjust path names to be relevant to the exported instance, rather than to anything that is not a CMS repository, as appropriate. (See, for example, [link to relevant documentation]). Figure 4 (Pages exported from data repository 430 need to be pinned to repository 430, not repository 440.) Furthermore, as an example, flat HTML may include files requested using query strings, which, if not renamed, will lead to an error. This is common for Wordpress, which adds query strings to all assets. For example, a target website might contain the string: “style.css?v=123”. The scraper will save the file as “style.css?v=123.css”, but the real and desired file name is “style.css”. To correct this and avoid errors, each such extracted file name is renamed without a query string. Post-processing for box 804 aims to resolve this and similar potential errors without user intervention.

[0062] In box 805, export logic 800 performs a version control "commit" operation on the new version and then ends. This commit detects and registers any changes from the current version (the deployed version) of the target website to the newly exported version. The updated website (target) is now ready for deployment.

[0063] See also Figure 3Q-Figure 3R The example CDS / CDA user interface shown illustrates that, before the deployment process begins, users are given the opportunity to approve and / or verify the exported version (using preview and approval UI controls). If changes are rejected, CDS / CDA can roll them back to their pre-export state using standard version control software techniques. Figure 3S The example CDS / CDA status is shown after the change has been approved, after which the user can use, for example, a deployment UI control to request the deployment of a new version.

[0064] Figure 9 This is a sample flowchart of a workflow for deploying a target website on a target server, provided by a sample deployment facility for a CMS deployment system / application. This routine can be, for example, provided by... Figure 4 Deployment facility 405, as Figure 1 A portion of the execution of CDA instance 101.

[0065] Specifically, in box 901, the deployment workflow logic 900 first determines whether a deployment task already exists on the deployment processing queue of the CMS instance. If so, the existing deployment task on the deployment processing queue (box 903) is used to process the next export; otherwise, a new task is added to the deployment queue (box 902). This synchronization is performed to maintain the integrity of the target website so that a single export version is reflected at a time. The queue handler processes the deployment queue asynchronously as a background worker, similar to responding to [see...] Figures 6-7 The described installation queue processes the deployment queue. In box 904, when triggered to process a deployment task from the deployment processing queue, the deployment queue processor displays the version deployed on the associated target server (including approved (exported) changes) and then cleans up the version control repository. In box 905, the deployment queue processor merges the displayed version (including changed files and assets) with the main branch of the target website. In box 906, the queue processor automatically post-processes the main branch files to resolve inconsistencies with resource and asset names, links, and file names, referencing the endpoint used for transfer (i.e., the target server URL) instead of the export URL or the CDS / CDA local instance URL. In box 907, the queue processor determines whether the user has confirmed the expectation of deploying the exported website. For example, Figure 3T A dialog box is shown requesting user confirmation of the desired deployment of the current (exported) website. If yes, the logic continues to box 909; otherwise, it continues to box 908. In box 908, the queue handler uses standard versioning technology to roll back the version to a previous version and then terminates. If approved, in box 909, the queue handler automatically (without further user intervention) transfers the exported website files to the target server. In an example CDS / CDA, the transfer is accomplished using Git-FTP, which is optimized to transfer only changed files. Other mechanisms can be combined similarly and equivalently. In box 910, the queue handler sends a notification that the target website has been successfully deployed. The target website is then publicly available on the target server, such as... Figure 3U As shown.

[0066] As will be understood from the foregoing, while specific embodiments have been described herein for illustrative purposes, various modifications may be made without departing from the spirit and scope of the invention. For example, the methods and systems discussed herein for developing and deploying websites can be applied to other architectures. Furthermore, the methods and systems discussed herein can be applied to different protocols, communication media (optical, wireless, cable, etc.), and devices (such as wireless mobile phones, electronic managers, personal digital assistants, portable email machines, game consoles, pagers, navigation devices such as GPS receivers, etc.).

Claims

1. A computer-implemented method for facilitating the automated creation and deployment of a website configured for public access, comprising: automatically provisioning a remote server for hosting a target website; associating the target website with a server name and network resource identifier of the provisioned remote server; automatically provisioning the target website on behalf of a user in response to an indication of a single user interface control selection by: installing a local instance of a content management software (CMS) system, the CMS system configured to provide resources, a front-end user interface for viewing content stored in the CMS system, and a back-end user interface for creating, modifying, and / or managing content stored in the CMS system; and associating the installed CMS system instance with the target website; in response to receiving an indication of a selection of the back-end user interface or the front-end user interface, invoking the installed CMS system instance to create, modify, and / or manage content for the installed CMS system instance; exporting the installed CMS system instance to produce an exported version of the CMS system instance, the exported version configured as flat html content to enable content stored in the CMS system instance to be remotely rendered from the CMS system instance; and in response to an indication of a single user interface control selection, automatically deploying the exported version as the target website on the remote server, the deployed target website rendering the flat html content independent of the CMS system; wherein exporting the installed CMS system instance to produce the exported version of the CMS system instance further comprises: without user intervention, using a software content retrieval tool for automatically scraping the CMS system instance; automatically scraping the CMS system instance to provide initial html content; automatically auditing the initial html content to detect missing resources, files, and / or pages; and automatically causing any detected missing content to be downloaded to supplement the initial html content to produce the exported version. the software content retrieval tool is at least one of: wget, aria2, aget, curl, grab-site, and / or wpull.

2. The method of claim 1, wherein, the software content retrieval tool is a command line tool configured to retrieve, crawl, and / or download content for offline viewing.

3. The method of claim 1, wherein, the missing content includes one or more of: assets, data, and / or files dynamically downloaded by the CMS system instance through scripts, stylesheets, or dynamically executed code.

4. The method of claim 1, wherein, exporting the installed CMS system instance to produce the exported version of the CMS system instance further comprises:

5. The method of any one of claims 1-4, wherein, resolving links to point to remote server locations. the CMS system instance is a WORDPRESS software instance and / or is a content management software system based on PHP, MYSQL DRUPAL, JOOMLA!, and / or EXPRESSIONENGINE software.

6. The method of any one of claims 1-4, wherein, ​ 7. The method of any one of claims 1-4, wherein, The automatically configuring the remote server is performed in response to input of a protocol designation, a port identifier, user credentials, and an associated server name.

8. The method of claim 1, wherein, The remote server is configured as an ftp server.

9. The method of any of claims 1-4, further comprising: storing an exported version of the CMS system instance in a version control system; and using the version control system, automatically deploying an approved version of the exported version as a target website on the remote server, and / or automatically rolling back the target website to a previous exported version of the CMS system instance, and / or maintaining continuity and / or consistency of content provided by multiple users at the same or different times.

10. A computer-readable storage medium having stored instructions for controlling a computer processor, the instructions when executed facilitating the automatic creation and deployment of a website configured for public access by performing at least one of the methods of claims 1-9.

11. A computer system comprising: a computer processor; a memory; and a website deployment component, the website deployment component comprising a content management system access tool, an export facility, and a deployment facility, the content management system access tool, the export facility, and the deployment facility stored in the memory, the website deployment component when executed by the computer processor configured to perform at least one of the methods of claims 1-9. The website deployment component is structured to accommodate multiple users modifying and / or exporting the CMS system instance.

12. The computer system of claim 11, wherein, ​

Images