Editing the database while previewing a virtual webpage

Abstract

This invention provides a method, system, and non-temporary computer-readable medium for dynamically editing web pages to update a backend database containing datasets that are populated into the web pages. [Solution] The method includes receiving multiple data elements via a user interface, storing at least one group of data elements in a database, generating multiple virtual web pages, displaying each group of at least one data element on individual pages among the multiple virtual web pages, displaying an editing tool so that the user can edit virtual web pages from the multiple virtual web pages, converting edits to the virtual web pages into updates for the database, storing the updates in the database, and enabling the display of the corresponding actual web pages in their updated state.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims priority to U.S. Provisional Patent Application No. 62 / 536,403, filed Jul. 24, 2017, and U.S. Provisional Patent Application No. 62 / 702,278, filed Jul. 23, 2018, both of which are hereby incorporated by reference in their entireties.

[0002] This application also generally covers the following applications, namely, U.S. Patent Application No. 13 / 596,146 filed on 28 August 2012, U.S. Patent Application No. 13 / 771,119 filed on 20 February 2013, U.S. Patent Application No. 13 / 779,798 filed on 28 February 2013, U.S. Patent Application No. 13 / 786,488 filed on 6 March 2013, U.S. Patent Application No. 13 / 959,759 filed on 6 August 2013, U.S. Patent Application No. 15 / 339,984 filed on 1 November 2016, and U.S. Patent Application No. 15 filed on 15 October 2013. U.S. Patent Application No. 14 / 053,614, U.S. Patent Application No. 15 / 233,987 filed on August 11, 2016, U.S. Patent Application No. 14 / 176,166 filed on February 10, 2014, U.S. Patent Application No. 14 / 207,761 filed on March 13, 2014, U.S. Patent Application No. 14 / 483,981 filed on September 11, 2014, U.S. Patent Application No. 14 / 559,943 filed on December 4, 2014, U.S. Patent Application No. 14 / 619,903 filed on February 11, 2015, U.S. Patent Application No. 14 / 619,903 filed on September 18, 2017 U.S. Patent Application No. 15 / 706,789, U.S. Patent Application No. 14 / 207,930 filed on March 13, 2014, U.S. Patent Application No. 15 / 657,156 filed on July 23, 2017, U.S. Patent Application No. 14 / 699,828 filed on April 29, 2015, U.S. Patent Application No. 15 / 653,568 filed on July 19, 2017, U.S. Patent Application No. 14 / 926,007 filed on October 29, 2015, U.S. Patent Application No. 14 / 619,145 filed on February 11, 2015, U.S. Patent Application No. 15 / 619,145 filed on September 19, 2017 U.S. Patent Application No. 15 / 168,295 filed on May 31, 2016, U.S. Patent Application No. 15 / 175,272 filed on June 7, 2016, U.S. Patent Application No. 15 / 224,616 filed on July 31, 2016, U.S. Patent Application No. 15 / 292,172 filed on October 13, 2016, U.S. Patent Application No. 15 / 224,579 filed on July 31, 2016, U.S. Patent Application No. 16 / 000,907 filed on June 6, 2018, U.S. Patent Application No. 15 / 607 filed on May 29, 2017,In relation to U.S. Patent Application No. 586, U.S. Patent Application No. 15 / 661,342 filed on 27 July 2017, U.S. Patent Application No. 15 / 850,151 filed on 21 December 2017, U.S. Patent Application No. 16 / 002,356 filed on 7 June 2018, U.S. Provisional Patent Application No. 62 / 591,297 filed on 28 November 2017, U.S. Provisional Patent Application No. 62 / 624,824 filed on 1 February 2018, U.S. Provisional Patent Application No. 62 / 626,093 filed on 4 February 2018, and U.S. Provisional Patent Application No. 62 / 647,736 filed on 25 February 2018, all of which are incorporated by reference. [Background technology]

[0003] This disclosure relates to a website building system for building indexable websites and web applications that incorporate custom backend functionality running on a system fully managed by a third party. For example, embodiments describe a stateless server environment (container, serverless code, etc.) when a programmable event associated with a frontend component or system activity is triggered, without requiring the system user to be involved in managing client-server interactions. This includes developing custom backend functionality that can run on virtual machines, etc.

[0004] Furthermore, this disclosure relates to hosting and managing website loads by providing on-demand execution instances of a website or individual web pages in real time. Instances may, in some embodiments, be spun up as virtual machines, containers, or serverless code elements. More specifically, this disclosure relates to a system and method for monitoring the load and activity of hosted websites in order to automatically add and remove instances that provide the hosted website without significant delay in responding to requests to provide the website. Furthermore, the hosted website may include a combination of generic code and website-specific code.

[0005] Furthermore, this disclosure relates to the visualization and testing of websites for end users of websites and data linked to websites, and to data generated in production environments by those end users in real time. More specifically, this disclosure relates to providing website developers or designers with access to data that website end users would typically see, for testing the functionality and experience of the website.

[0006] Furthermore, this disclosure relates to editing a database during a virtual webpage preview. For example, a user can store groups of data elements (e.g., text, graphics, video, etc.) in a database, and one or more virtual webpages may be generated to display a preview of the webpage. While a virtual webpage is being displayed, the user can edit the virtual webpage, and the user's edits may be translated into updates for the database. In addition, updates to the database can be reflected in the displayed live view during a live view of the actual webpage corresponding to the virtual webpage.

[0007] The website building system disclosed herein is used to enable people with limited software development experience and / or resources to develop and host customized websites. In contrast, traditional website development systems provide template front-end UIs that lack or have limited back-end control via embedded code snippets that invoke external services or server-side code; therefore, this system is limited to web pages that lack or have minimal options for data manipulation or other custom functionality. Other systems require maximum involvement in setting up the client-server interaction in order to access full back-end control.

[0008] Traditional website development systems lack the ability to create layouts for web pages into which data is fed and to generate multiple dynamic pages that can be indexed. Furthermore, traditional systems lack the ability to incorporate a software-based router for web pages that can include different content and functionality in web pages depending on how users access and interact with them. Traditional systems also lack the ability to monitor user interactions on a website and display output results based on previously registered functions associated with those interactions.

[0009] Traditional managed website hosting systems either use dedicated servers that incur significant costs and resources to maintain in a ready and operational state, or employ cold starts of new instances when a new website is requested or when the load on a particular website exceeds a certain latency threshold to respond to requests. This is used to process requests to a website. Such a process, which involves cold-starting a new instance of a website or webpage, involves significant processing delays and resulting latency in the user experience.

[0010] Traditional website development systems are also limited in their ability to allow users to dynamically edit page previews. Such systems also cannot receive edits to previewed pages, nor can they translate those edits into updates to the database on which all or part of the page is based. As a result, using such traditional systems involves more user action, more bandwidth, and more cumbersome operations.

[0011] The website testing systems disclosed herein can be set up to create a realistic experience for end-users using a website without disrupting the end-user experience. However, while traditional website testing systems provide a limited preview interface for reviewing a site as an end-user would experience it, they lack a way to provide real-time access to the data generated on the website under test. Furthermore, traditional systems lack the ability to add new data or delete data generated for a site without affecting the end-user experience.

[0012] Traditional website hosting systems are also vulnerable to plugins containing malicious code (e.g., malware) (e.g., software that can be embedded in the front-end or back-end of a website). Once such code is uploaded by one website owner or user, it can spread through the website hosting system and affect the websites of other owners or users. Traditional website hosting systems lack the ability to isolate uploaded plugins and prevent their infection from spreading to other websites commonly hosted by the system. [Overview of the Initiative]

[0013] Therefore, there is a need for a technical solution for a new website development system that manages backend functionality, provides the freedom to further customize the website, and does not involve the user in server setup, provisioning, or server-client interaction. There is also a need to provide users with technical tools to build customized websites, such as customized coding capabilities, without requiring them to code the entire website from scratch.

[0014] Furthermore, there is a need for technical solutions for new on-demand systems that can process website requests without significant delays. Such technical solutions would require the use of virtual computing resources such as virtual machines, containers, and serverless code. Moreover, such solutions should enable highly customized websites that include both features common to many pages or sites and features unique to specific pages or sites.

[0015] Furthermore, there is a need for a technical solution for a new website testing system that provides real-time access to data available during production.

[0016] In addition, there is a need for technical solutions to isolate uploaded plugins and prevent them from spreading infection to co-hosted websites. Such techniques include: While it's possible to separate both front-end and back-end plugins, website owners and users still need to be able to upload and utilize such plugins.

[0017] Certain embodiments of this disclosure relate to a system for building a website. The system may include an online website building system configured to enable a website builder to add backend functionality to a centrally hosted website, the centrally hosted website comprising one or more web pages indexable by a search engine. The online system enables the use of a common online database for editing pages and dynamic previewing, the common online database being accessible simultaneously to designers and users. The system may comprise an online database configured to store a library of website building elements for composing the front end of an indexable web page, and at least one processor configured to perform specific operations. The operation may include sending a first command to a user's remote web browser, the first command enabling the user to remotely access a stored library via an integrated interface viewable by the remote web browser, and enabling the user to utilize selected build elements for constructing the front end of an indexable web page, the integrated interface providing the user with access to both the build elements and customized backend functionality associated with the indexable web page; enabling the user to configure a programmable event via an integrated interface viewable by the remote web browser to activate user-editable code that provides customized backend functionality associated with the indexable web page; receiving user edits to the user-editable code for implementing the customized backend functionality associated with the programmable event via the integrated interface; storing the edited user-editable code in a code storage system that communicates with an online database; and executing the edited user-editable code for implementing the customized backend functionality in response to a trigger associated with the programmable event.

[0018] In some embodiments, the system includes the execution of edited user-editable code to implement customized backend functionality based on hooks that cause the execution of the edited user-editable code.

[0019] Furthermore, in some embodiments, the hooks are webhooks, data hooks, or data binding router hooks.

[0020] Still further, in some embodiments, at least one processor is further configured to automatically generate skeleton code associated with website construction elements selected by a user based on rules stored in an online database and to transmit the skeleton code to a remote web browser to enable the skeleton code.

[0021] In addition, in some embodiments, the system includes a function associated with website construction elements selected by a user and a code snippet associated with the function as part of the automatically generated skeleton code.

[0022] Furthermore, in some embodiments, the system includes an integrated interface that can be displayed by a remote web browser, and the remote web browser includes a front-end website editing window and a customized backend editing window.

[0023] Still further, in some embodiments, the system includes a trigger for data activities that includes a specific dataset associated with the customized backend functionality.

[0024] Still further, in some embodiments, the system includes a trigger for updates entered on an indexable web page.

[0025] In addition, in some embodiments, the system includes triggers for page transitions on indexable web pages.

[0026] Furthermore, in some embodiments, the system includes triggers for defined interactions between a user and indexable web pages.

[0027] Moreover, in some embodiments, at least one processor is further configured to execute edited user-editable code to implement a plurality of customized backend functions in response to triggers associated with programmable events.

[0028] Still further, according to some embodiments, at least one processor is further configured to execute edited user-editable code to implement customized backend functions in response to a plurality of triggers associated with a plurality of programmable events.

[0029] Furthermore, according to some embodiments, the system includes a code storage system configured to store code for a software-based router that processes incoming client requests for indexable web pages.

[0030] Moreover, in some embodiments, the system includes a storage system that is both an online database and a code storage system.

[0031] A particular embodiment relates to a computer implementation for building a website using customized backend functionality. The method comprises the steps of: maintaining an online database configured to store a library of website build elements for constructing the front end of an indexable web page; sending a first command to a user's remote web browser, the first command enabling the user to remotely access the stored library via an integrated interface accessible by the remote web browser, and enabling the user to utilize selected build elements for constructing the front end of an indexable web page, the integrated interface providing the user with access to both the build elements and customized backend functionality associated with the indexable web page; receiving a specification from the user via an integrated interface accessible by the remote web browser for configuring a programmable event to activate user-editable code that provides customized backend functionality associated with the indexable web page; receiving user edits to user-editable code for implementing the customized backend functionality associated with the programmable event via the integrated interface; storing the edited user-editable code in a code storage system that communicates with the online database; and executing the edited user-editable code for implementing the customized backend functionality in response to a trigger associated with the programmable event. It may include "Tep".

[0032] Furthermore, in some embodiments, the method includes the step of retrieving data from an online database and from a remote web browser for use in the execution of edited user-editable code to implement customized backend functionality in response to a trigger.

[0033] Furthermore, according to some embodiments, the method includes the step of providing a user with access to at least a portion of user-editable code for editing in the form of selectable segments of the code.

[0034] Furthermore, according to some embodiments, the method includes executing edited user-editable code to implement customized backend functionality based on a hook that triggers the execution of the edited user-editable code.

[0035] In addition, according to some embodiments, the method includes a hook which is either a webhook, a data hook, or a data binding router hook.

[0036] Furthermore, according to some embodiments, the method includes generating skeleton code associated with a user-selected website building element by at least one processor based on rules stored in an online database, and sending the skeleton code to a remote web browser to enable the skeleton code.

[0037] Furthermore, according to some embodiments, the automatically generated skeleton code includes a function associated with a build element selected by the user, and a code snippet associated with that function.

[0038] Furthermore, in some embodiments, the method includes the step of providing an integrated interface viewable by a remote web browser, the remote web browser including a front-end website editing window and a customized back-end editing window.

[0039] Furthermore, in some embodiments, the method includes a trigger for data activity involving a specific dataset associated with a customized backend function.

[0040] In addition, in some embodiments, the method includes a trigger for updates entered on an indexable web page.

[0041] Furthermore, in some embodiments, the method includes a trigger for a defined interaction between the user and an indexable web page.

[0042] A particular embodiment relates to a system for on-demand allocation of web server execution instances for a website server. The system may comprise at least a first storage location for storing general-purpose website server code for hosting multiple websites, and at least a second storage location, separated from the first storage location, for storing website-specific code unique to each of the multiple websites. The system controls multiple web server execution instances such that at least some instances execute website-specific code unique to at least one of the multiple websites, and at least other web server execution instances execute website-specific code unique to any website. The system may further include at least one processor configured to perform operations that include: executing generic website server code without unique code; receiving a request to access a specific website, wherein the specific website is built on a platform containing the generic website server code; determining whether the specific website is already hosted by one of a plurality of web server execution instances; if it is determined that the requested specific website is not yet hosted by one of the plurality of web server execution instances, directing the request to a first instance of the plurality of web server execution instances running the generic website server code; injecting the first instance of the plurality of web server execution instances running the generic website server code with additional website-specific code unique to the requested website from at least one second storage location; and responding to the request via the first instance of the plurality of web server execution instances using a combination of both the generic website server code and the website-specific code uniquely injected to the requested website.

[0043] In some embodiments, the system may include multiple web server execution instances, each of which may include one or more containers, virtual machines, or physical machine processes.

[0044] Furthermore, in some embodiments, the request is an HTTP request, and the system includes actions to respond to the request that are performed before the request times out.

[0045] Furthermore, in some embodiments, the system includes a response action that is performed within 100 milliseconds of receiving the request.

[0046] In addition, in some embodiments, the system includes a proxy server for processing HTTP requests, including receiving and determining actions.

[0047] Furthermore, in some embodiments, the determination action further includes querying the web server execution instance manager to determine whether a particular website is already hosted by one of several web server execution instances.

[0048] Furthermore, in some embodiments, the determination action further includes forwarding the request to a web server execution instance manager, and, if the request fails, determining accordingly that the specific website requested is not currently hosted by one of the multiple web server execution instances.

[0049] Furthermore, in some embodiments, the determination operation includes determining, based on a state table, that a particular website is already hosted by one of several web server execution instances.

[0050] In addition, in some embodiments, the system includes a state table maintained by the proxy server that identifies a list of websites already hosted by one of several web server execution instances.

[0051] Furthermore, in some embodiments, the system includes an operation to update a status table that removes inactive websites from the list based on a predetermined period of inactivity of requests associated with the inactive website.

[0052] Furthermore, in some embodiments, additional unique websites are provided for the requested website. The unique code includes a backend code unique to the requested website.

[0053] Furthermore, in some embodiments, additional website-specific code unique to the requested website includes code associated with a plugin referenced by the requested website.

[0054] In addition, in some embodiments, the operation further includes monitoring a set of web server execution instances that are not yet hosting a particular website, and instructing the web server execution instance manager to spin up additional web server execution instances if the size of the set of web server execution instances is smaller than a threshold.

[0055] Furthermore, in some embodiments, the operation further includes monitoring a set of web server execution instances that are not yet hosting a particular website, and instructing the web server execution instance manager to shut down at least one web server execution instance if the size of the set of web server execution instances exceeds a threshold.

[0056] Certain embodiments of this disclosure relate to a computer implementation for on-demand allocation of web server execution instances for a website server. The method includes the steps of: storing a general-purpose website server code for hosting a plurality of websites in a first storage location; storing a website-specific code unique to each of the plurality of websites in a second storage location separate from the first storage location; controlling a plurality of web server execution instances, wherein at least some instances execute a website-specific code unique to at least one of the plurality of websites, and at least other web server execution instances execute a general-purpose website server code for which no website has a specific unique code; receiving a request to access a particular website, wherein the particular website is built on a platform including the general-purpose website server code; and the particular website is one of the plurality of web server execution instances. The process may include: determining whether the website is already hosted by one of the stashes; if it is determined that the requested specific website is not yet hosted by one of the multiple web server execution instances, directing the request to a first instance of the multiple web server execution instances running generic website server code; injecting the first instance of the multiple web server execution instances running generic website server code with additional website-specific code unique to the requested website from at least one second storage location; and responding to the request via the first instance of the multiple web server execution instances using a combination of the generic website server code and the website-specific code uniquely injected to the requested website.

[0057] According to some embodiments, multiple web server execution instances may include one or more containers, virtual machines, or physical machine processes.

[0058] Furthermore, according to some embodiments, the request is an HTTP request, and the method includes the step of responding to the request before the request times out.

[0059] Furthermore, according to some embodiments, the method includes a step of responding to a request that is being performed within 100 milliseconds of receiving the request.

[0060] Certain embodiments of this disclosure relate to a system for on-demand allocation of web server execution instances for a website server. The system may comprise at least one memory device for storing a general-purpose website server code for hosting a plurality of websites and a website-specific code unique to each of the plurality of websites, and at least one processor configured to perform operations. The operation may include controlling multiple web server execution instances such that at least some instances execute website-specific code unique to at least one of multiple websites, and at least other web server execution instances execute generic website server code for which no website has a specific unique code; receiving a request to access a particular website such that the particular website is built on a platform that includes generic website server code; determining whether the particular website is already hosted by one of the multiple web server execution instances; and, if it is determined that the requested particular website is not yet hosted by one of the multiple web server execution instances, forwarding the request to a first instance of the multiple web server execution instances that executes generic website server code, the request prompting the first instance of the multiple web server execution instances that executes generic website server code to retrieve additional website-specific code unique to the requested website from at least one memory device; and responding to the request via the first instance of the multiple web server execution instances using a combination of both the generic website server code and the website-specific code uniquely entered for the requested website.

[0061] According to some embodiments, a first instance of a plurality of web server execution instances running generic website server code is configured to obtain an additional website-specific code unique to the requested website from at least one memory device, based at least on the identifier of the requested website included in the request.

[0062] A particular embodiment relates to a system for running test data of a website in a private website test environment while simultaneously running live data of a website in a website deployment environment. The system may comprise at least one common database storing both live data and test data of a website, wherein the test data is associated with the live data in at least one common database, and at least one processor configured to perform an operation. The operation may perform functions including accessing live data stored in at least one common database, using the accessed live data to render the website in the website deployment environment, receiving requests to run tests on the website while the website is running in the website deployment environment, accessing a set of test data in at least one common database in response to the request, wherein the set of test data includes one or more test data elements corresponding to each live data element, and the set of test data is not accessible in the website deployment environment, and testing the website in parallel in the private website test environment so that both sets of test data and live data are used simultaneously by the website in the private website test environment while the website is running in the website deployment environment.

[0063] According to some embodiments, test data is associated with live data using markers configured to replace specific live data elements with specific test data elements during testing.

[0064] Furthermore, according to some embodiments, the marker is configured to be removed after testing.

[0065] In addition, according to some embodiments, the marker can issue a command to ignore specific live data during testing.

[0066] Furthermore, according to some embodiments, the system is a website hosting environment for hosting multiple websites generated by multiple users.

[0067] Furthermore, according to some embodiments, at least one common database is a centralized online database configured to store live data associated with multiple websites generated by multiple users.

[0068] Furthermore, according to some embodiments, the test data includes newly added data that was not previously associated with the live data of the website.

[0069] In addition, according to some embodiments, test data is hidden from the website deployment environment.

[0070] Furthermore, according to some embodiments, the system includes test data in response to requests to add data in a private website test environment.

[0071] Furthermore, according to some embodiments, the test data is created in a region of at least one common database that is hidden from the website deployment environment.

[0072] Furthermore, according to some embodiments, the system includes test data elements corresponding to each live data element, which include data elements that instruct the requested changes to be made to the copy of each live data element.

[0073] In addition, according to some embodiments, the system includes determining the corresponding test data elements for the live data elements that are requested to be changed, and, if the corresponding test data elements exist, performing the requested changes to the respective corresponding test data elements.

[0074] Furthermore, according to some embodiments, the system performs the following actions: receiving a query initiated in a private website test environment; responding to the query with one or more live data elements if one or more live data elements are not associated with their respective test data elements; and responding to the query with one or more test data elements if one or more live data elements are associated with their respective test data elements.

[0075] Furthermore, according to some embodiments, at least one processor is further configured to merge test data with live data, thereby replacing one or more live data elements with their respective corresponding test data elements.

[0076] A particular embodiment of this disclosure relates to a computer implementation method for running test data of a website in a private website test environment while simultaneously running live data of a website in a website deployment environment. The method includes the step of storing both live website data and test data of a website, wherein the test data The following steps may be included: associating live data with at least one common database; accessing live data stored in at least one common database; using the accessed live data to render the website in a website deployment environment; receiving a request to run tests on the website while the website is running in the website deployment environment; accessing a set of test data in at least one common database in response to the request, wherein the set of test data includes one or more test data elements corresponding to each live data element, and the set of test data is not accessible in the website deployment environment; and testing the website in parallel in a private website test environment while the website is running in the website deployment environment, such that the website uses both sets of test data and live data simultaneously in the private website test environment.

[0077] According to some embodiments, the method may include the step of associating test data with live data using markers configured to replace specific live data elements with specific test data elements during testing.

[0078] Furthermore, according to some embodiments, the marker is configured to be removed after testing.

[0079] Furthermore, according to some embodiments, the marker can issue a command to ignore specific corresponding live data during testing.

[0080] In addition, according to some embodiments, the method is performed by a server configured to provide a website hosting environment for hosting multiple websites generated by multiple users.

[0081] Furthermore, according to some embodiments, the test data is created in a region of at least one common database that is hidden from the website deployment environment.

[0082] Specific embodiments of the present disclosure relate to a computer-based system for simultaneously running live data of a visual application system in a deployment environment while running test data of a visual application system in a private test environment, the computer-based system comprising: at least one common database storing both live data of a visual application system and test data of a visual application system, wherein the test data is associated with the live data in at least one common database; and at least one processor configured to access the live data of a visual application system stored in at least one common database, use the live data accessed by the visual application system in a deployment environment, receive requests to run tests on the visual application system while the visual application system is running in the deployment environment, access a set of test data in at least one common database in response to the request, the set of test data includes one or more test data elements corresponding to each live data element, the set of test data is not accessible in the deployment environment, and test the visual application system in parallel in the private test environment such that both sets of test data and live data are used simultaneously by the visual application system in the private test environment while the visual application system is running in the deployment environment.

[0083] Furthermore, according to some embodiments, the computer-based system is at least one of a website development system and a source code development system.

[0084] Certain embodiments of the present disclosure include a computer-readable medium that, when executed by at least one processor, causes at least one processor to execute a specific instruction for updating a backend database containing a dataset to be fed into multiple web pages of a website. The instruction may receive multiple data elements via a user interface, the data elements being organized into one or more groups of at least one data element, each group intended for display on an individual web page of a website, store the group of at least one data element in a database, generate multiple virtual web pages, each virtual web page being a preview of the corresponding actual web page before the corresponding actual web page is operational, each corresponding actual web page not designed to have the functionality to update the database, display each group of at least one data element on an individual page among the multiple virtual web pages, display an editing tool so that the user can edit the virtual web pages from among the multiple virtual web pages, translate edits to the virtual web pages into updates for the database, store the updates in the database, and perform actions to enable the corresponding actual web page to be displayed with the updates made to the virtual web page during the preview while the corresponding actual web page associated with the virtual web page is live view.

[0085] In addition, in some embodiments, each of the multiple virtual web pages can be displayed within a frame associated with the editor interface of the user interface.

[0086] In a further embodiment, the operation includes displaying user-selectable features that allow the user to navigate across multiple virtual web pages in order to display each of the multiple virtual web pages individually and dynamically.

[0087] In additional embodiments, the operation includes displaying a user-selectable feature that allows the user to select a specific virtual webpage from a group of virtual webpages based on the identifier of that specific virtual webpage.

[0088] In a further embodiment, the identifier of a particular virtual webpage is based on a data element associated with that particular virtual webpage.

[0089] Furthermore, according to some embodiments, the operation includes associating a unique URL with each of the multiple virtual web pages.

[0090] In an additional embodiment, each of the multiple virtual web pages is generated based on a sitemap that references the unique URL of each of the multiple virtual web pages.

[0091] According to some embodiments, the editing tool is configured to receive edits to a group of at least one data element stored in a database.

[0092] Furthermore, in some embodiments, the editing tool is configured to receive edits to the attributes of multiple virtual web pages.

[0093] In an additional embodiment, the editing tool is configured to receive edits to the code used to generate multiple virtual web pages.

[0094] In a further embodiment, the editing tool is configured to display multiple segments of skeleton code representing the actual code used to generate multiple virtual web pages, and to receive edits to the skeleton code which are then translated into edits to the actual code.

[0095] Furthermore, in some embodiments, data elements are received from an external source via a user interface.

[0096] In additional embodiments, the operation further includes accessing a software-based router associated with a plurality of virtual web pages and configuring the software-based router to generate different versions of each of the plurality of virtual web pages based on one or more segments of an incoming URL.

[0097] In some embodiments, a subset of each group of at least one data element is organized by a repeater function, and the repeater function generates one or more displayed instances of each subset of each group of at least one data element.

[0098] Furthermore, additional embodiments include a live view of a corresponding actual web page containing one or more instances.

[0099] This specification also discloses a computer implementation for updating a backend database containing datasets to be populated on multiple web pages of a website. The method may include: receiving a plurality of data elements via a user interface, wherein the data elements are organized into one or more groups of at least one data element, each group being intended for display on an individual web page of the website; storing the group of at least one data element in a database; generating a plurality of virtual web pages, each virtual web page being a preview of the corresponding actual web page before the corresponding actual web page is operational, and each of the corresponding actual web pages is not designed to have the functionality to update the database; displaying each group of at least one data element on an individual page of the plurality of virtual web pages; displaying an editing tool so that a user can edit virtual web pages from the plurality of virtual web pages; translating edits to the virtual web pages into updates for the database; storing the updates in the database; and enabling the display of the corresponding actual web page with the updates made to the virtual web page during the preview, while the corresponding actual web page associated with the virtual web page is live view.

[0100] In some embodiments, each of the multiple virtual web pages can be displayed within a frame associated with the editor interface of the user interface.

[0101] Furthermore, in some embodiments, the method further includes the step of displaying user-selectable features that allow the user to navigate across multiple virtual web pages in order to display each of the multiple virtual web pages individually and dynamically.

[0102] In additional embodiments, the method further includes the step of displaying a user-selectable feature that allows a user to select a specific virtual webpage from a group of virtual webpages based on the identifier of the specific virtual webpage.

[0103] In a further embodiment, the identifier of a particular virtual web page is a particular virtual web page Based on the associated data elements.

[0104] Furthermore, in some embodiments, the method further includes the step of associating a unique URL with each of a plurality of virtual web pages.

[0105] In an additional embodiment, each of the multiple virtual web pages is generated based on a sitemap that references the unique URL of each of the multiple virtual web pages.

[0106] Furthermore, in some embodiments, the editing tool is configured to receive edits to a group of at least one data element stored in the database.

[0107] According to an additional embodiment, the editing tool is configured to receive edits to the attributes of multiple virtual web pages.

[0108] In a further embodiment, the editing tool is configured to receive edits to the code used to generate multiple virtual web pages.

[0109] Furthermore, in some embodiments, the editing tool is configured to display multiple segments of skeleton code representing the actual code used to generate multiple virtual web pages, and to receive edits to the skeleton code which are then translated into edits to the actual code.

[0110] In additional embodiments, data elements are received from an external source via a user interface.

[0111] Additional embodiments disclosed relate to a system for enabling the dynamic editing of a webpage to update a backend database containing a dataset to be populated into the webpage. The system may comprise an online database configured to store a plurality of data elements for display on a plurality of webpages, wherein the data elements are organized into one or more groups of at least one data element, each group for display on an individual webpage of a website, and each individual webpage does not have the capability to update the online database; and at least one processor configured to perform an operation. The operation may remotely provide instructions to a browser to provide an interface for displaying an editable version of a first webpage generated based on a group of at least one data element, the interface for the user to edit at least one data element, the edits to the editable version of the first webpage received via the interface, the edits to be converted into updates for the online database, the updates to be stored in the online database, and the first webpage to be displayed with the updates made to the editable version of the first webpage during a live view of the first webpage.

[0112] Further embodiments include the operation of generating multiple individual editable versions of a web page, each of which is viewable within a frame associated with the editor interface of the interface.

[0113] A particular embodiment of this disclosure relates to a system for previewing dynamic web pages via an online editor interface. The system is an online database configured to store a first instruction for storing a plurality of data elements for display on a plurality of web pages and for organizing the data elements into a plurality of groups, each of which comprises at least one data element, and An online database associated with at least one individual web page, each of which is further made available by at least one of a browser-executable front-end code and a back-end server-executable remotely from the browser, for the purpose of configuring multiple scrollable virtual web pages, each of which is a plurality of groups, and at least one processor remotely provides the browser with a second instruction to display an interface that allows a user associated with the browser to add data elements to the database, associate each added data element with at least one of the plurality of groups, and modify at least one of the front-end code and the back-end code, and the data elements added by the user, the association of the added data elements with at least one of the plurality of groups, and the front-end code and back-end code The system may include at least one processor configured to execute a third instruction for generating a plurality of scrollable virtual web pages based on at least one modification of a code, the plurality of scrollable virtual web pages being configured to be generated independently by at least one processor and edited independently by a user, and to remotely provide a browser with a fourth instruction for displaying a preview interface configured to display the plurality of scrollable virtual web pages before the generation of the corresponding final web page, the preview interface being configured to allow the user to selectively scroll across the plurality of scrollable virtual web pages based on each of a plurality of groups of at least one data element, and to visualize how the group of at least one data element will appear on the corresponding final web page before the corresponding final web page is launched.

[0114] According to some embodiments, the system may remotely provide the browser with additional instructions to display an online editor interface so that the user can drag and drop a selected from at least one build element onto a web page template, to associate at least one website build element with one of the data elements for building the front end of a corresponding final web page.

[0115] Furthermore, according to some embodiments, the system includes a web page template, which is a dynamic web page template configured to include adjustable data components for rendering a corresponding final web page associated with each of several groups.

[0116] Furthermore, according to some embodiments, the system may include a preview interface configured to be displayed in a browser within a frame associated with the online editor interface.

[0117] In addition, according to some embodiments, the system may include multiple scrollable virtual web pages that can be displayed within a frame associated with an online editor interface.

[0118] Furthermore, according to some embodiments, the system may include a preview interface that can include user-selectable features that allow the user to scroll across multiple scrollable virtual web pages.

[0119] Furthermore, according to some embodiments, the system includes a preview interface that may include a user-selectable feature that allows the user to select a specific virtual webpage to display based on the identifier of each virtual webpage.

[0120] Furthermore, according to some embodiments, the system may include identifiers for each virtual web page based on data elements stored in a database.

[0121] In addition, according to some embodiments, the system can associate a unique URL with each of multiple groups.

[0122] Furthermore, according to some embodiments, the system includes multiple scrollable virtual web pages that may be generated based on a sitemap referencing the unique URL of each web page.

[0123] Furthermore, according to some embodiments, the system may include a database that includes a centralized online database configured to store data associated with multiple user-generated websites of multiple remote users.

[0124] Furthermore, according to some embodiments, at least one individual webpage is indexable by a search engine.

[0125] In addition, according to some embodiments, the system may include at least one of front-end code and back-end code configured to perform the functions of a software-based router.

[0126] Furthermore, according to some embodiments, a software-based router can configure at least one separate web page in multiple different ways based on multiple different possible URL segments provided by the user.

[0127] Furthermore, according to some embodiments, the system may include at least one of the front-end code and back-end code associated with at least one individual web page.

[0128] Furthermore, this system may include at least one of the front-end and back-end code associated with a particular software-based router.

[0129] In addition, multiple groups may be associated with at least one of a website containing multiple separate web pages and related groups of websites.

[0130] Furthermore, according to some embodiments, the system may include a subset of multiple data elements organized by a repeater function, the repeater function generating one or more display instances of the subset of multiple data elements.

[0131] Furthermore, according to some embodiments, one or more instances may be part of a preview interface configured to display multiple scrollable virtual web pages.

[0132] A particular embodiment of this disclosure relates to a computer implementation for previewing a dynamic web page via an online editor interface. The method comprises the steps of storing a plurality of data elements for display on a plurality of web pages, and storing a first instruction for organizing the data elements into a plurality of groups, each of which groups comprises at least one data element and is associated with at least one separate web page, and each of the plurality of groups further comprises a browser-executable front end code for configuring a plurality of scrollable virtual web pages. The process involves: providing the browser with a second instruction to display an interface that allows a user associated with the browser to add data elements to a database, associate each added data element with at least one of several groups, and modify at least one of the frontend and backend code; and executing a third instruction to generate multiple scrollable virtual web pages based on the data elements added by the user, the association of the added data elements with at least one of several groups, and the modification of at least one of the frontend and backend code. Steps may include: a step of configuring a plurality of scrollable virtual web pages to be generated independently by at least one processor and edited independently by a user; and a step of remotely providing a browser with a fourth instruction to display a preview interface configured to display the plurality of scrollable virtual web pages before the generation of a corresponding final web page, wherein the preview interface allows the user to selectively scroll across the plurality of scrollable virtual web pages based on each of a plurality of groups of at least one data element, and to visualize how the group of at least one data element will appear on the corresponding final web page before the corresponding final web page is launched.

[0133] According to some embodiments, the method includes the step of remotely providing a browser with additional instructions to display an online editor interface so that a user can drag and drop a selected one of at least one build elements onto a web page template to associate at least one website build element with one of the data elements for building the front end of a web page.

[0134] Furthermore, according to some embodiments, the web page template is a dynamic web page template configured to include adjustable data components for rendering the corresponding final web page associated with each of several groups.

[0135] Furthermore, according to some embodiments, the preview interface is configured to be displayed in a browser within a frame associated with the online editor interface.

[0136] Certain embodiments of the present disclosure relate to a system for navigating between dynamic web pages, the system comprising an online database storing multiple data elements for display on multiple dynamic web pages. The database may also store first instructions for organizing the data elements into multiple groups, each of which includes at least one data element and is associated with at least one of the multiple dynamic web pages, and each of the multiple groups is available to at least one of browser-executable front-end code and browser-remote back-end code for composing the multiple dynamic web pages, each of which is configured to be generated and edited independently. The system may also comprise at least one processor configured to remotely provide the browser with second instructions for displaying a navigation interface as part of at least one of the multiple dynamic web pages, the navigation interface being automatically generated based on each of the multiple groups of at least one data element on multiple dynamic web pages Each page is configured to allow users to navigate selectively, and the navigation interface is not a native element of multiple dynamic web pages.

[0137] Furthermore, according to some embodiments, the system may perform at least one of the following: searching for multiple dynamic web pages which can be navigated by selecting a dynamic web page via a displayed function; sequentially scrolling through multiple web pages; and directly navigating to the next, previous, first, last, bookmarked, or other specific web page.

[0138] Furthermore, according to some embodiments, dynamic web pages have an order determined based on a sitemap.

[0139] In addition, according to some embodiments, the system may include a navigation interface configured to be displayed in a browser within a frame separated from other aspects of multiple dynamic web pages.

[0140] Specific embodiments of this disclosure relate to a system for hosting websites implemented in a server environment. The system comprises at least one hosting server configured to co-host multiple websites generated by multiple users, wherein the hosting server includes a hosted common editing tool accessible to multiple users to enable each of the multiple users to selectively modify a particular website generated by each of the multiple users, and the hosting server is further configured to prevent at least some of the multiple users from modifying a particular co-hosted website generated by other of the multiple users, and the hosting server includes an interface for viewing by at least one subset of the multiple users to enable at least one subset of the multiple users to upload to the hosting server plugin code associated with plugins for a particular co-hosted website generated by at least one subset of the multiple users. A processor configured to include at least one processor, wherein the plugin code for at least one particular plugin includes at least one of either client-executable frontend plugin functionality code or backend plugin functionality code executable on a plugin server; and memory for storing user-uploaded plugin code associated with at least one particular plugin, such that the user-uploaded stored plugin code is centrally hosted on a common domain with a specific co-hosted website generated by multiple users, wherein a single instance of at least one particular plugin is shared by multiple specific co-hosted websites, and for each of the multiple specific co-hosted websites sharing at least one uploaded plugin, the at least one processor uses an isolation mechanism.It is further configured to securely allow at least one of the executions of front-end plugin functional code on the client or back-end plugin functional code on the plugin server, and based on an isolation mechanism, prevents malicious code contained in at least one uploaded plugin from affecting other sites of a specific co-hosted website on the hosting server.

[0141] According to some embodiments, the plugin server and the hosting server included in this system are the same server.

[0142] Furthermore, according to some embodiments, the system is separate from the hosting server. It may include an isolation mechanism that enables the execution of backend plugin functionality code on the plugin server.

[0143] Furthermore, according to some embodiments, the system may include an isolation mechanism that enables the execution of backend plugin functionality code in a virtual machine.

[0144] In addition, according to some embodiments, the system may include an isolation mechanism that enables the execution of backend plugin functionality code in a Docker container.

[0145] Furthermore, according to some embodiments, the system may include an isolation mechanism that includes the execution of backend plugin functionality code via an isolated process in the plugin server.

[0146] Furthermore, according to some embodiments, the system may include an isolation mechanism that enables the execution of front-end plugin functional code in a secure sub-area of ​​a specific co-hosted website.

[0147] Furthermore, according to some embodiments, the system may establish a secure communication channel for controlling communication between a sub-area of ​​a particular co-hosted website and other sub-areas of that same co-hosted website.

[0148] In addition, according to some embodiments, the system may include a secure communication channel configured to restrict access of at least one uploaded plugin to other aspects of a particular co-hosted website.

[0149] Furthermore, according to some embodiments, the system may include a secure communication channel created using an application programming interface configurable to restrict interaction between at least one uploaded plugin and a specific co-hosted website.

[0150] Furthermore, according to some embodiments, the system may include an isolation mechanism that enables the execution of frontend plugin functionality code via an iframe in the client's browser, and the iframe is configured to function as a secure sandbox for the execution of the frontend plugin functionality code.

[0151] Furthermore, according to some embodiments, the system can associate client-executable front-end plugin functionality code with a separate webpage sub-area of ​​a specific co-hosted website.

[0152] In addition, according to some embodiments, the system can associate two or more trusted plugins with a specific co-hosted website.

[0153] Furthermore, according to some embodiments, the system can enable at least one uploaded plugin to communicate with and control at least one component of a specific co-hosted webpage on which front-end plugin functionality code is executed.

[0154] Furthermore, according to some embodiments, the system may co-host multiple co-hosted specific websites on a shared platform accessible to multiple users.

[0155] Furthermore, according to some embodiments, the system may include at least one uploaded plugin that is separated from cookies associated with specific co-hosted website web pages.

[0156] Certain embodiments of this disclosure relate to computer implementations for hosting a website implemented in a server environment.This method comprises the steps of co-hosting multiple websites generated by multiple users on a hosting server, making a common editing tool available to multiple users so that each of the multiple users can selectively modify a specific website generated by each of the multiple users, preventing at least some of the multiple users from modifying a specific co-hosted website generated by other of the multiple users, and generating an interface for viewing by at least one subset of the multiple users so that at least one subset of the multiple users can upload plugin code associated with a plugin for a specific co-hosted website generated by at least one subset of the multiple users to the hosting server, wherein the plugin code for at least one specific plugin is either client-executable front-end plugin functionality code or plugin server-executable back-end plugin functionality code. The method may include: a step of storing user-uploaded plugin code associated with at least one specific plugin, such that the stored plugin code uploaded by the user is centrally hosted on a common domain with specific co-hosted websites generated by multiple users, wherein a single instance of at least one specific plugin is shared by multiple specific co-hosted websites; and a step of securely enabling, using an isolation mechanism, at least one of the execution of front-end plugin functional code on the client or back-end plugin functional code on the plugin server for each of the multiple specific co-hosted websites sharing at least one uploaded plugin, thereby preventing malicious code contained in at least one uploaded plugin from affecting other sites of the multiple specific co-hosted websites on the hosting server.

[0157] According to some embodiments, the method may include at least one uploaded plugin that is separated from cookies associated with a specific co-hosted website webpage.

[0158] Furthermore, according to some embodiments, the plugin server and the hosting server are the same server.

[0159] Furthermore, according to some embodiments, the method may include an isolation mechanism that enables the execution of backend plugin functionality code on a plugin server separate from the hosting server.

[0160] In addition, according to some embodiments, the method may include an isolation mechanism that enables the execution of backend plugin functionality code in a virtual machine.

[0161] Furthermore, according to some embodiments, the method may include an isolation mechanism that enables the execution of backend plugin functionality code in a Docker container.

[0162] Furthermore, according to some embodiments, the method may include an isolation mechanism that enables the execution of backend plugin functionality code via an isolated process on the plugin server.

[0163] Furthermore, according to some embodiments, the method may include client-executable front-end plugin functionality code, which is configured to generate a user interface in a browser iframe.

[0164] Please understand that the above general description and the following detailed description are for illustrative and illustrative purposes only and do not limit the invention as described in the claims. [Brief explanation of the drawing]

[0165] The accompanying drawings incorporated herein and constituting part of this specification illustrate several embodiments and, together with the description, serve to illustrate the principles of this disclosure.

[0166] [Figure 1] Figure 1 shows an exemplary online website building system that interacts with other systems and components, according to some embodiments of the present disclosure.

[0167] [Figure 2] Figure 2 shows an exemplary online website building system according to several embodiments of the present disclosure.

[0168] [Figure 3] Figure 3 shows the path to execution of backend code associated with a trigger in some embodiments of the present disclosure.

[0169] [Figure 4] Figure 4 shows an exemplary online editor interface for updating backend functionality according to some embodiments of the present disclosure.

[0170] [Figure 5] Figure 5 is a block diagram showing an exemplary dynamic web page in development mode according to some embodiments of the present disclosure.

[0171] [Figure 6] Figure 6 is a flowchart illustrating a method for developing backend functionality according to several embodiments of the present disclosure.

[0172] [Figure 7] Figure 7 is a flowchart showing how to trigger the execution of backend code according to some embodiments of the present disclosure.

[0173] [Figure 8]Figure 8 is a block diagram of an on-demand web server execution instance system according to some embodiments of the present disclosure.

[0174] [Figure 9] Figure 9 is a schematic diagram illustrating the interactions between components of various on-demand web server execution instance systems according to several embodiments of this disclosure.

[0175] [Figure 10] Figure 10 is a flowchart illustrating a method for responding to web requests submitted regarding a website, according to some embodiments of the present disclosure.

[0176] [Figure 11] Figure 11 shows an on-demand web server execution instance system for determining whether a website is hosted, and for generating and instantiating web server execution instances, according to some embodiments of the present disclosure.

[0177] [Figure 12] Figure 12 shows the instantiation of a web server execution instance element on a website according to some embodiments of the present disclosure.

[0178] [Figure 13] Figure 13 shows load monitoring and management of instances in use for a hosted website according to some embodiments of the present disclosure.

[0179] [Figure 14] Figure 14 shows the monitoring of the number of web server execution instances available for hosting, according to some embodiments of the present disclosure.

[0180] [Figure 15] Figure 15 shows an exemplary website real-time testing system according to several embodiments of the present disclosure.

[0181] [Figure 16a] Figure 16a is a schematic diagram of deployment environment access to data elements according to some embodiments of the present disclosure.

[0182] [Figure 16b] Figure 16b is a schematic diagram of test environment access to data elements according to some embodiments of the present disclosure.

[0183] [Figure 17] Figure 17 illustrates website access to live and test data in a test environment according to several embodiments of the present disclosure.

[0184] [Figure 18] Figure 18 shows the generation of test data used in a test environment for testing a website, according to some embodiments of the present disclosure.

[0185] [Figure 19] Figure 19 is a flowchart showing how to access a website in a deployment environment according to some embodiments of the present disclosure.

[0186] [Figure 20] Figure 20 is a flowchart showing how to access a website in a test environment according to some embodiments of the present disclosure.

[0187] [Figure 21] Figure 21 is a flowchart showing a method for processing data requests in a test environment according to some embodiments of the present disclosure.

[0188] [Figure 22] Figure 22 is a flowchart showing a method for processing read requests in a test environment according to some embodiments of the present disclosure.

[0189] [Figure 23a] Figure 23a is a flowchart of a method for updating data elements in a test environment according to some embodiments of the present disclosure.

[0190] [Figure 23b] Figure 23b is a flowchart of a method for updating data elements in a deployment environment according to some embodiments of the present disclosure.

[0191] [Figure 23c] Figure 23c is a flowchart illustrating a method for adding data elements in a test environment according to several embodiments of the present disclosure.

[0192] [Figure 24] Figure 24 is a flowchart showing a method for removing data elements from a test environment according to some embodiments of the present disclosure.

[0193] [Figure 25] Figure 25 shows an overlay process for generating results obtained by querying test data, according to some embodiments of the present disclosure.

[0194] [Figure 26] Figure 26 is a flowchart showing the steps involved in editing a database during a website preview, according to some embodiments of the present disclosure.

[0195] [Figure 27] Figure 27 is a diagram of a system for developing and previewing web pages according to some embodiments of the present disclosure.

[0196] [Figure 28] Figure 28 is a block diagram of a virtual web page according to some embodiments of the present disclosure.

[0197] [Figure 29]Figure 29 shows a timeline display of a dynamic refresh of a web page according to some embodiments of the present disclosure.

[0198] [Figure 30] Figure 30 is a block diagram of a dynamic preview system according to some embodiments of the present disclosure.

[0199] [Figure 31] Figure 31 shows a preview of a virtual web page being edited, according to some embodiments of the present disclosure.

[0200] [Figure 32] Figure 32 is a schematic diagram illustrating the relationship between a data group and a website in some embodiments of the present disclosure.

[0201] [Figure 33] Figure 33 is a schematic diagram showing components involved in the generation of a virtual web page according to several embodiments of the present disclosure.

[0202] [Figure 34] Figure 34 is a flowchart showing the steps involved in previewing a virtual web page according to some embodiments of the present disclosure.

[0203] [Figure 35] Figure 35 is a schematic diagram of the interaction between a user and a website hosting system according to some embodiments of the present disclosure.

[0204] [Figure 36] Figure 36 shows controlled access to a co-hosted website according to some embodiments of the present disclosure.

[0205] [Figure 37]Figure 37 shows a group of co-hosted websites that share plugin code under a common root, according to some embodiments of the present disclosure.

[0206] [Figure 38] Figure 38 shows an isolated execution environment for backend plugin code according to some embodiments of the present disclosure.

[0207] [Figure 39] Figure 39 shows controlled access and execution of front-end plugin code according to some embodiments of the present disclosure.

[0208] [Figure 40] Figure 40 shows the client-side isolated execution of plugin code according to some embodiments of the present disclosure.

[0209] [Figure 41] Figure 41 is a flowchart illustrating the steps involved in accessing and executing website and plugin code according to some embodiments of the present disclosure.

[0210] [Figure 42] Figure 42 shows an exemplary user interface for editing web pages and creating database collections, according to some embodiments of the present disclosure.

[0211] [Figure 43] Figure 43 shows an exemplary user interface for editing web pages and configuring permissions for a database collection, according to some embodiments of the present disclosure.

[0212] [Figure 44]Figure 44 shows exemplary user interfaces for editing entries in web pages and database collections, according to some embodiments of the present disclosure.

[0213] [Figure 45] Figure 45 shows an exemplary user interface for editing web pages and displaying output from a database collection, according to some embodiments of the present disclosure.

[0214] [Figure 46] Figure 46 shows an exemplary user interface for editing web pages and creating repeater functionality, according to some embodiments of the present disclosure.

[0215] [Figure 47] Figure 47 shows an exemplary user interface for editing a web page and displaying the results of a repeater function, according to some embodiments of the present disclosure. [Modes for carrying out the invention]

[0216] The following detailed description includes many specific details to ensure that the exemplary embodiments of this disclosure are fully understood. However, those skilled in the art will understand that the principles of the exemplary embodiments can be practiced without all specific details. To avoid obscuring the principles of the exemplary embodiments, well-known methods, procedures, and components are not described in detail. Unless expressly stated, the exemplary methods and processes described herein are not restricted to any particular order or sequence or to any particular system configuration. In addition, some of the embodiments or elements described may occur or be performed simultaneously, at the same time, or in parallel. Hereinafter, embodiments of this disclosure are described in detail, and examples thereof are shown in the accompanying drawings. Unless expressly stated, transmission and reception as used herein should be understood to have a broad meaning, including transmission or reception in response to a specific request, or transmission or reception without such a specific request. Thus, these terms encompass both the active and passive forms of transmission and reception.

[0217] Systems and methods consistent with this disclosure cover website building systems that include customized front-end and back-end functionalities. In some embodiments, the website building system may include options for user configuration of back-end functionality development capabilities.

[0218] Figure 1 illustrates an exemplary system, according to several embodiments of the present disclosure, that interacts with other components and users over a network. As shown in Figure 1, the website building system (WBS) 100 includes a WBS editor 110, which may be a tool for creating and editing websites. The WBS 100 may also include a WBS content management system (CMS) 120, which includes widgets and other tools used in websites, databases, or similar data storage structures, code or data representing a built or developing website, and data created, updated, and viewed using the built or developing website (e.g., e-shop inventory that underlies an e-commerce website). ) and could be repositories.

[0219] The WBS Editor 110 can be an editor for building and editing websites. The editor allows you to build websites and website pages starting from a blank canvas, or based on pre-developed sites, site sections, or pages (collectively referred to as templates) that can be stored in the WBS CMS 120. The WBS Editor 110 can define the visual layout and other attributes of the pages of the website being built. Templates can define the web pages and their initial content that belong to the website being built. The WBS Editor 110 may also include a UI section for determining the site's structure by defining navigation between various pages. The WBS Editor 110 defines the page layout by allowing users to arrange components on the web pages as they want them to appear on the actual web pages.

[0220] In some embodiments, as further described below, WBS100 can host websites and individual pages via virtual machines, container instances, or serverless code. These techniques can reduce load times and user latency. For example, if a website incorporates backend or frontend code that must be executed, or contains site-specific components, such code and components can be loaded into a stateless server execution instance when the stateless server execution instance is first associated with a request made by a browser (e.g., web browser 131) regarding a given site. Such a stateless server instance can then be reused for further browser requests involving the same site. Furthermore, WBS100 offers the advantage of being able to use server resources based on the actual requests being processed, which is far more efficient than using dedicated web service execution instances (such as servers, VMs, or containers) and infrastructure.

[0221] The build tool 121 may include widgets, which are components laid out on the page being edited by the WBS editor. In some embodiments, widgets may include apps developed by the user building the web page, other users, the WBS vendor itself, or third-party application providers. Apps may be obtained from repositories such as the Wix App Market. Examples of widgets include simple widgets (such as text fields and shapes) or complex widgets (such as calendars, form generators, image editors, video editors, visitor counters, and social media integrations).

[0222] The WBS CMS120 can store both the components for building a website and the built website itself. In some embodiments, the components and the website are maintained in separate CMS systems. As shown in Figure 1, the build tool 121 is stored in the WBS CMS120, which includes widgets and other tools to facilitate the easy construction of websites.

[0223] The builder tool 121 is a website building block that facilitates the process of building a website and adding content to it. The builder tool 121 can include both component tools or widgets such as tabs, search bars, buttons, galleries, and slide decks, as well as manipulative tools such as alignment tools. The builder tool 121 can include both simple widgets (e.g., buttons, text fields) and complex widgets (e.g., galleries, calendar widgets) and can be configured to perform advanced functions. The builder tool 121 is a web building block that facilitates the process of building a website and adding content to it. It can be represented as an abstraction of code representing Jet and other tools. The build tool 121 may include public default tools provided to all users of the system and private tools provided only to specific websites or users. Private tools may include public tools or new tools customized for a user or website. Private tools may be created by users of the system or third-party vendors who build websites. The build tool 121 may be shared among multiple websites built and owned by different user groups. The build tool 121 can also be customized by editing the code of an existing build tool 121 (for example, updating the stylesheet of a button to create a new stylesheet for a new button). Custom build tools may be stored in the system area database 122 along with the original build tool 121.

[0224] The WBS editor 110 provides remote access to the build tool 121 stored in the system area database 122 of the WBS CMS 120. Instances of selected widgets from the build tool 121 can be created when a user places a widget on a page being edited by the WBS editor 110. Instances of selected widgets from the build tool 121 can be created by references to widgets on the page. Instances of selected widgets from the build tool 121 can also be created by copying the code representing the selected widget onto a web page of the website being built.

[0225] The WBS editor 110 is typically server-hosted software, and some or all of its elements can be loaded onto the user's website browsing device 130 (or its web browser 131) for execution. In some embodiments, the WBS editor 110 may share the system area database 122 with the build tool 121, or it may share a common server. Nevertheless, in other embodiments, the WBS editor 110 and the system area database 122 are hosted separately.

[0226] The site area database 124 stores websites built using the WBS editor 110. As shown in the figure, website 123 is a website built using the WBS editor 110 and stored in the site area database 124. Website 123 stored in the site area database 124 may contain text representing code and data that can be accessed, updated, and displayed using the website development device 140. Website 123 may contain one or more web pages, including indexable web pages 125. In some embodiments, for example, one or more indexable web pages 125 all share the same common domain (e.g., http: / / www.my-site.com), subdomain (e.g., http: / / my-site.wix.com / ), or URL prefix (e.g., http: / / www.wix.com / wixsites / my-site / ). Indexable web pages 125 may include a front end 126 and a back end 127. An indexable webpage 125 may contain special files or code that include or reference a frontend 126 and a backend 127, as indicated by the dashed line, or it may simply be the name of a collection of frontends 126 and backends 127. The frontend 126 may consist of widgets and other UI elements that may be instances of the build tool 121, containing instance-specific information (such as location, size, attribute values, etc.), and such instance-specific information may also contain containment information (i.e., which components are contained within which containers). The frontend 126 may also contain code elements such as code segments that run on the frontend 126 (which may affect widgets during runtime). The frontend 126 may contain page metadata, title, etc. It may be further composed of any other elements.

[0227] The frontend 126 includes instances of the build tool 121 located on an indexable webpage 125 of the website 123 built using the WBS editor 110, such as instances that are always visible to the user, instances that are visible by default, or instances that are visible at least for a limited time. The backend 127 represents functionality that can be activated when a user interacts with the frontend 126, or through non-interactive events such as incoming communications to the website 123, time-based triggers, or changes to a database connected to the website 123. The backend 127 may be seen only occasionally or never at all by users of the website development device 140 and the WBS vendor staff device 150. The frontend 126 and backend 127 may be stored in the site area database 124 as code or structured data (e.g., XML, JSON, JSON-LD, etc.). The code may be stored in either text format or compiled object code. The code representing the frontend 126 and backend 127 may be in the same programming language or structured data format. In some embodiments, the code representing the backend 127 and the code that is part of FE126 are translated into different programming languages ​​before being stored in the site area database 124.

[0228] In some embodiments, the code and data for website 123 may share a database or have separate databases. In some embodiments, the code representing the frontend 126 and backend 127 may be stored in the site area database 124 as plain text in a database table. In other embodiments, the code may be stored as a file object, and the site area database 124 may store the location of the file. In some embodiments, the code is stored in a single location in the site area database 124 or in a column of files. In some embodiments, the code may be split into multiple files.

[0229] In some embodiments, the indexable webpage 125 is a dynamic webpage, and the frontend 126 is a template, which may not be an actual webpage. As will be further described below, a dynamic webpage may be a webpage configured to change its appearance or content based on customized backend functionality. Examples of customized backend functionality, further described below, include updating the data displayed on the webpage, resizing or changing images on the webpage, and triggering the rendering of video content on the webpage. In some embodiments, the frontend 126 of a dynamic webpage may be a template that is directly bound to data from a database table to update the content and appearance of various dynamic webpages.

[0230] In some embodiments, the WBS100 may include more or fewer components than those shown in Figure 1. For example, databases 122 and 124 may be a single database or separate databases. The databases may be a distributed set of databases. Both databases 122 and 124 may be relational databases, object-oriented databases, data language file repositories (for languages ​​such as XML or JSON), or NoSQL databases. Furthermore, databases 122 and 124 may be maintained in an on-premises network (e.g., a local area network with internet access), a cloud-based network (e.g., a public or private cloud architecture), or a hybrid of on-premises and cloud-based networks.

[0231] As shown in Figure 1, the website 123 stored in the site area database 124 of the WBS CMS 120 can be accessed by a website browsing device 130 (e.g., a desktop computer, tablet, laptop, smartphone, etc.) via a web browser 131. A user of the website browsing device 130 (not shown) can request access to the website 123 via the network 160 (e.g., the Internet, including an intermediate network between the website browsing device 130 and the WBS 100). The web browser 131 on the web browsing device 130 (e.g., Apple's Safari, Google's Chrome, Mozilla's Firefox, Microsoft's Explorer, etc.) can be used to view the website 123 and the data created and edited using the website 123. A website development device 140 can be used to build the website 123 using the WBS editor 110. The web browser 141 on the website development device 140 can be used to request access to the WBS editor 110 in order to build the website 123. The WBS vendor staff device 150 may be used to provide customer support for users (not shown) of the website development device 140 when building and maintaining the website 123. The WBS vendor staff device 150 may also be used by third-party vendors to create and customize the build tools 121. The WBS vendor staff device 150 may also be used to configure the WBS 100 itself, for example, to manage site designer and user accounts, to manage the above site or page templates (creating new templates or editing existing templates), or to manage various elements including the WBS 100.

[0232] In some embodiments, the website browsing device 130, the website development device 140, and the WBS vendor staff device 150 may be physically different devices. In other embodiments, they may be different views accessed from the same device using different credentials and / or different roles. In some embodiments, the web browsers 131, 141, and 151 may be the same browser or different browsers on the same or different devices, or different tabs on the same browser.

[0233] The website browsing device 130, the website development device 140, and the WBS vendor staff device 150 can access the website 123 via the network 160. In some embodiments, the website browsing device 130, the website development device 140, and the WBS vendor staff device 150 may be mobile devices, laptops, desktop computers, tablets, etc.

[0234] As shown in Figure 1, search engines 170 (e.g., Google, Yahoo, Bing, etc.) can access indexable web pages 125 of websites 123 stored in the site area database 124 via the network 160, regardless of whether they interact with the WBS 100. Search engines 170 index the indexable web pages 125 of websites 123 to make them more discoverable, thereby increasing the number of users who use website browsing devices 130 to view websites 123. In some embodiments, build tools 121 further enable users to optimize websites 123 for indexing and searching via search engines 170. For example, build tools 121 enable users to optimize text displayed in the header of a particular indexable web page 125, text displayed in a specific location on an indexable web page 125, or text associated with an indexable web page 125 (e.g., as metadata). Make it selectable.

[0235] Figure 2 shows an exemplary structure of WBS100 according to several embodiments of the present disclosure. As shown in Figure 2, WBS100 includes a site area database 124 containing components for both website construction and hosting, as described above in relation to Figure 1.

[0236] In some embodiments, the indexable webpage 125 may be a dynamic or virtual webpage into which data from a data group 210 can be populated into components of the front-end 126. The data group 210 may be associated with multiple webpages. The data group 210 may consist of data elements, each containing a data element 211. The data element 211 may be associated with one or more components of a construction tool 121 used in the front-end 126 of the indexable webpage 125. For example, the data group 210 may be an employee database, where each data element 211 may be an employee record containing multiple data fields (such as name, age, and department information). These multiple fields may be used to populate multiple displayed components (display fields) in the front-end 126 of the indexable webpage 125. In some embodiments, the data group 210 is stored in a site area database 124 as part of a table, and the data element 211 is a row in that table. The webpage associated with the data group 210 may be, for example, a dynamic webpage.

[0237] A data element 210 may be associated with a URL association DB 220. When a user accesses an indexable webpage 125 of a website 123 by entering a URL using a web browsing device 130, the URL (or a segment thereof) may be matched for reference against a URL or URL segment stored in the URL association DB 220. A data group may be associated with a URL or URL segment in the URL association DB 220. A URL or URL segment in the URL association DB 220 may help determine which data group to use when generating a virtual or dynamic webpage using the associated indexable webpage 125. In some embodiments, the indexable webpage 125 is a template for a dynamic or virtual webpage, and the actual webpage is generated using data from a data group 210 determined using the URL in the URL association DB 220.

[0238] Data element 210 can be determined using a software-based router that analyzes a URL (or URL segment) entered by a user using a web browsing device 130 or otherwise provided to access a web page 125 of website 123. Analysis of the URL by the software-based router can generate a key for accessing data element 211 of data group 210. For example, using the URL http: / / mysite.wix.com / users / 20, the software-based router can analyze the URL to determine that the prefix "users" is associated with a data group and the suffix "20" is the key, and as a result look up the data element in the "users" related data group identified by the key value "20". As described herein, the software-based router can be configured to analyze the URL suffix or parameters within the URL to determine the version of the web page to display or the content of the web page. All of the above can apply to URLs that the system receives in some way rather than being directly entered by a user (e.g., URLs automatically generated by another page on a website or page-related code). This system also supports multiple concurrently defined software routers, and the website building system 100 initializes the received URL. An analysis is performed to determine which of the defined software routers to use. Such an analysis can be performed based on the received URL, based on the definitions contained in the URL association DB220, or based on additional information or conditions (such as system environment conditions).

[0239] The first set of instructions 240 is accessed by the web browser 141 and may be configurable through the processor 260. The first set of instructions 240 helps the web browser 141 remotely access a library containing tools, including the build tool 121. The online editor interface 243 may be a visual representation of the WBS editor 110 software on the web browser 141. The online editor interface 243 is used to create and edit the front-end 126 layout implementation of the indexable web page 125 with the help of the build tool 121 and the associated front-end 126 and back-end 127 code of the indexable web page 125. Similar to the first set of instructions 240, additional instructions (e.g., second and third instructions 250 and 260, among others) may also be accessible to the processor 260 and the web browser 141.

[0240] The web browser 141 is used to construct the website 123 by displaying a navigation interface 242 for navigating between different parts of the website 123 and an online editor interface 213 for editing the accessed part of the website 123. Code representing the WBS editor 110 within the WBS 100 can be sent to the web browser 141 to display the navigation interface 242 and the online editor interface 243.

[0241] Figure 3 illustrates the path to execution of backend code associated with a trigger in some embodiments of the present disclosure. As shown in Figure 3, a trigger 310 may result in the execution of code associated with the backend 127. A trigger 310 may occur, for example, when a user of a web browsing device 130 interacting with an indexable web page 125 of website 123 performs a specific action (e.g., a mouse or touchpad click, selection, cursor hover, reload request, text input, or multimedia content upload). A trigger 310 may also occur during non-interactive events. For example, a periodic time-based action or a database update may trigger and execute code in the backend 127 and / or frontend 127. A trigger 310 is customizable and can take many different forms. Furthermore, any interaction that needs to result in the execution of code associated with the backend 127 may occur via a programmable event 320. A programmable event 320 passes control to the backend 127 for execution via a hook linking the frontend 126 and the backend 127. The type of hook used to pass control between the programmable event 320 and the backend 127 may be configurable and may depend on the type of interaction or other type of event that triggered the trigger 310. The programmable event 320 uses one or more of the following other possible types of hooks, including data hooks 330, web hooks 340, or data binding router hooks 350, to pass control to the backend 127 to execute code in the backend 127.

[0242] On an indexable webpage 125 of a website 123 displayed in a web browser 131, when a user of a web browsing device 130 enters a data update, a data hook 330 can be used to pass control from a programmable event 320 to a backend 127. For example, submitting a form can be considered a data update, and a data hook 330 can be used to pass control to a backend 127. In some embodiments, the quend 127 creates or updates database entries. Similarly, as another example, posting text to a blog or social media interface can be a data update associated with the data hook 330. The data hook 330 can also be used to programmatically pass control to the backend 127 via an API call. For example, a periodic time-based action trigger 310 may result in entries in the database that are older than the period they are marked as deleted or inactive.

[0243] The webhook 340 may be used to pass control from a programmable event 320 to the backend 127 when a web module function is imported and invoked by code that is part of the frontend 126. In some embodiments, for example, the code that is part of the frontend 126 is called a frontend script and is executed when a user of a web browsing device interacts with the frontend 126 component of an indexable webpage 125 of a website 123 displayed in a web browser 123. For example, the webhook 340 may be based on a user of the indexable webpage 125 using an app, making a purchase, subscribing to content on the indexable webpage 125, etc.

[0244] The data binding router hook 350 can be used to pass control from a programmable event 320 to a backend 127 when a specific dynamic webpage is requested by a user of a web browsing device 130 by navigating to a specific URL in a web browser 131. For example, navigation can be done by typing the URL into the address bar of the web browser 131, clicking a hyperlink on an indexable webpage 125 of a website 123 displayed in the web browser 131, or by performing an action that automatically navigates to a predefined or programmatically generated URL. The data binding router hook 350 helps determine the data group 210 and the backend 127 code function to execute in order to apply the data elements 211 of the determined data group 210 to a webpage template defined in the function of the backend 127 code.

[0245] In some embodiments, the data binding router hook 350 may work in conjunction with a software-based router. For example, when a user accessing an indexable webpage 125 enters the URL of the indexable webpage 125, the software-based router can determine the data to display on the indexable webpage 125, and even determine the specific webpage to display. The router may be associated with a prefix, which is the first part (or another segment of the URL). For example, in the URL http: / / www.wix.com / label, "label" may be the prefix. Furthermore, in the URL http: / / www.wix.com / label / sub-label, "sub-label" may be the suffix. Based on a specific segment of the provided URL (e.g., prefix, suffix, or parameter value), the router can determine what content associated with either, or a specific webpage associated with either, should be displayed. For example, the prefix may be associated with a router, and the suffix may be passed to a selected router to determine which page to access or which data to use on that page. The router may also be used to generate a complete virtual or dynamic page based on selected data and templates. In this way, the indexable web pages 125 of website 123 can be made dynamic and customizable based on how users interact with such web pages.

[0246] The data binding router hook 350 also connects to the website browsing device 130. The system may function to pass control based on internal events following user interaction with website 123. For example, data binding router hook 350 may be registered to perform a function before determining routing to a page, as described above, to check whether the user has permission to access the page to which it is routed. Data hook 330 may, depending on the case, be executed before or after data binding router hook 350 with respect to the same trigger 310. For example, after querying a database connected to website 123, data hook 330 may be executed to filter out entries that are no longer active (for example, a store website may filter out products that are no longer sold from the database query search results). Thus, the system can support the operation of various combinations of hooks and the inter-chaining of hooks.

[0247] Figure 4 is a block diagram showing an exemplary dynamic web page 125 in development mode, accessed on a web development device 140 via a web browser 141, according to some embodiments of the present disclosure. As shown in Figure 4, the online editor interface 243 consists of an integration interface 410 and a preview interface 420.

[0248] The integrated interface 410 may be used to develop or build indexable web pages 125 of website 123. As described above, the integrated interface 410 may provide access to build tools 121. Build tools 121 may include editing tools 411 that help edit indexable web pages 125 of website 123. In some embodiments, the integrated interface 410 may be a separate section displayed on the web browser 141 during development. In other embodiments, the integrated interface 410 may be a collective term for various tools and user interface sections. In some embodiments, the integrated interface 410 may be a separate section of the displayed web page or a floating window or frame. In some embodiments, components of the integrated interface 410 may float within a section of the web browser 141.

[0249] The front-end 126 and back-end 127 may be displayed or represented together or in separate windows in edit mode. In some embodiments, they may be displayed only one at a time. Also, the back-end 127 may not be specific to the displayed web page 125 or website 123, and some or all of it may be shared among the website and different website developers. When a developer saves website 123, the front-end may be saved in the form of front-end 126.

[0250] The preview interface 420 helps the user visualize the website 123 being built by displaying the web page 125 as it would appear in the real world, i.e., as it would appear in the web browser 131 of a web browsing device 130 displaying the virtual web page 421. Each virtual web page 421 may be associated with a unique identifier 422. In some embodiments, the unique identifier 422 is a URL or URL segment stored in the site area database 124 along with other URLs 210. Other forms of the identifier 422 are also possible.

[0251] FIG. 5 is a block diagram showing an exemplary dynamic or virtual web page in development mode according to some embodiments of the present disclosure. For example, as described above in connection with FIG. 4, the dynamic or virtual web page can be the virtual web page 421.

[0252] As shown in FIG. 5, the integration interface 410 displays the construction tool 121 and the indexable web page 125. In this exemplary figure, the front end 126 is shown using a WYSIWYG editor to visually edit the content of the page (e.g., text, graphics, widgets, etc.). In some embodiments, the front end 126 can be edited directly as code. In some embodiments, the construction tool 121 is a user interface section within the integration interface 410. In further embodiments, the construction tool 121 can be accessed by a menu item of the online editor interface 243. In some embodiments, a particular website construction tool selected from the construction tool 121 can be dragged and dropped in the front end 126 section of the integration interface 410. The front end 126 of the indexable web page 125 shows the visual configuration of the construction tool 121.

[0253] In some embodiments, the back end 127 is shown as a floating window within the integration interface 410. In other embodiments, the back end 127 can be a separate section similar to the front end 126. The code representing the back end 127 may be hidden and may not be displayed unless requested. In some embodiments, all the back end 127 code is always displayed, and in other embodiments, only the back end 127 code associated with a single element from the construction tool 121 is displayed.

[0254] ​​WBS100 may be configured to automatically generate skeleton code when elements are selected from the construction tool 121 and placed in the front end 126. The generated skeleton code shown in the back end 127 may include, for example, a shell function 521 and shell code 522. Both the shell function 521 and the shell code 522 represent programmable events 320 within the code executed by the trigger 310. In some embodiments, as illustrated, the shell function 521 called buttonClick is code representing the event of clicking a button. The trigger for the button click results in the programmable event buttonClick.

[0255] FIG. 6 is a flowchart showing a method 600 for developing a back-end function 127 according to some embodiments of the present disclosure. In some embodiments, the method 600 may be executed by components of the WBS100 as described above.

[0256] As shown in FIG. 6, in step 610, when the user makes a request regarding website 123 development via the web browser 141, WBS100 receives a request from the user of the web development device 140 to access the construction tool 121 of the site area database 124. As described above, examples of the construction tool 121 include widgets, graphics, and other content.

[0257] In step 620, the WBS 100 sends a first instruction 240 in response to a request from the website development device 140 via the web browser 141. The request is received by the WBS 100 via the network 160. The request is forwarded to the website CMS 120. The website CMS 120, upon request from the processor 260, provides access to the first instruction 240, which is then sent to the website browser 141. The first instruction 230 provides access to the build tool 121 stored in the site area database 124, which enables the construction of the front end 126 and back end 127 of the web page 125.

[0258] In step 630, when WBS100 receives a request from the website development device 140 via network 160 to use the tools in the build tool 121, the rules Based on this, the skeleton code for the selected tool in the build tool 121 is automatically generated. For example, as mentioned above in relation to Figure 5, the skeleton code can be associated with events such as mouse clicks, hovers, and content selections.

[0259] In step 640, the WBS 100 may send skeleton code to the website development device 140 for display in the web browser 141.

[0260] In step 650, the WBS 100 may provide the front-end 126 with access to a customized back-end function 127 associated with the web page 123 on which the front-end 126 is being edited or created. As described above, the back-end function 127 can take various different forms and may be configured to occur based on various defined events.

[0261] In step 660, the WBS 100 can receive specifications from the user of the website development device 140 via the web browser 141 and configure a programmable event 320 to activate a customized backend function 127.

[0262] In step 670, the WBS 100 can receive user-editable code that implements the backend functionality 127 from a user of the website development device 140 via the web browser 141. The user can edit the code by changing its functionality or updating it.

[0263] In step 680, the WBS 100 can store the edited user-editable code received from the website development device 140 via the network 160 in the site area database 124. The edited user-editable code can then be made deployable and provide customized backend functionality 127 for the indexable web pages 125.

[0264] Figure 7 is a flowchart of a method 700 that triggers the execution of backend code 127 according to some embodiments of the present disclosure. As described above, method 700 may be executed in conjunction with method 600. In line with the above discussion, method 700 may be executed in the WBS100 system.

[0265] As shown in Figure 7, a user of a website browsing device 130 can trigger a programmable event 320 associated with the backend 127 by any of the following: navigating to an indexable webpage 125 as shown in step 711; interacting with the indexable webpage 125 as shown in step 712; or entering an update to the indexable webpage 125 and triggering the trigger 310 as shown in step 713. For example, step 711 may include the user clicking a nested hyperlink to the indexable webpage 125 that is associated with another webpage portion of the same website 123. Similarly, step 711 may include the user clicking a “next” or “continue” hyperlink on the indexable webpage 125 to browse subsequent related pages. Step 712 may include, for example, the user hovering the cursor over a graphic or text on the indexable webpage 125, pausing for a predetermined period of time, or clicking an image or text on the indexable webpage 125. Step 713 involves the user updating text content on indexable webpage 125, uploading an image or video file to indexable webpage 125, filling out a form on indexable webpage 125, and identifying This could include a timer that triggers an action, a database update, etc.

[0266] In step 720, when WBS100 receives notification of a programmable event 320, it responds by accessing the trigger 310 associated with the programmable event 320. As described above, the programmable event 320 may be based on various types of hooks, such as data hooks 330, web hooks 340, and data binding router hooks 350. The hook associated with the programmable event 320 may include accessing internal data of the website 123 (e.g., Wix data) stored in the site area database 124.

[0267] In step 730, the WBS100 may optionally retrieve data from outside the online site area database 124 and the remote web browser 141 (e.g., from an external database, another website, a remote service, etc.). In some embodiments, such data may be used as part of a programmable event 320.

[0268] In step 740, the WBS 100 can request the processor 260 to execute the edited user-editable backend code 127. Thus, in programmable event 320, the customized backend function may occur on the indexable web page 125. As described above, this customized backend function can be defined by user input in terms of its functionality, data source, and timing. The user may be given guided control over the creation and editing of the code for each of these attributes of the customized backend function (for example, they may not need to code the entire function from scratch, but instead be provided with a template or sample code).

[0269] Systems and methods consistent with this disclosure also cover on-demand website hosting systems that include functions for hosting websites, delivering websites to clients, monitoring website load, and responding to website load dynamics. In some embodiments, on-demand executable instances may monitor website usage activity and automatically spin up or remove some or all of the executable instances. Furthermore, as described below, web server executable instances spun up to deliver a website or page may include a combination of generic website code and site-specific or page-specific code, resulting in fast and highly efficient response times for delivering highly tailored individual websites and pages.

[0270] In general, when a user interacts with a website, they can make various HTTP requests. For example, an initial HTTP request may be made to load a web page (which, depending on the situation, may trigger additional HTTP requests to load additional page elements such as images or scripts). In addition, users can make HTTP requests during a session (e.g., selecting values ​​in a field, clicking on a hyperlinked image). Furthermore, users can make data-related HTTP requests, such as submitting a form. In addition, users can make backend HTTP requests, which may activate backend functionality (e.g., via backend code as described herein).

[0271] To speed up the process of loading pages and processing HTTP requests, this system (e.g., WBS100) can be configured to utilize the fast startup of Docker containers or serverless code configured for a specific website or page. In one embodiment, as described herein, a pool of standby containers or other virtual computing resources may be provided with all relevant non-site-specific code, but not with user-specific or site-specific code. The system may then listen on a live port for requests to a server for a particular website. If there is a live container or other virtual computing resource associated with a particular website, the system may connect to it. Otherwise, the system may use a standby container in the pool and populate the pool with the requested site-specific content, or instruct the pool to load such content. Once the site-specific content for a given site is loaded, the container joins the pool of containers associated with the given site. As described herein, the populated site-level content may or may not include actual site pages. Such site page information may include, for example, actual browser-readable page material (e.g., a collection of HTML, CSS, and JavaScript® code), underlying site definition data (e.g., using XML files or JSON representations) that is converted into browser-readable material by client-side or server-side code (e.g., a WBS viewer module), or front-end or back-end code (e.g., JavaScript code called by the page to run on the client, server, or both).

[0272] Figure 8 shows a block diagram of an on-demand web server execution instance system 800 according to some embodiments of the present disclosure. As shown in Figure 8, the on-demand system 800 comprises a processor 260, memory 820 for storing currently or recently served websites, and persistent storage 830 for storing all websites available to serve. In some embodiments, the on-demand system 800 may also include, or be associated with, a proxy server 840 to help determine whether a new web server execution instance needs to process a website request.

[0273] The WBS system 100 and the on-demand system 800 store code for editing a website and access the code to process web requests. The WBS editor 110 is used to present web pages of the website in relation to edit requests received from the web development device 140. Web server execution instances are instantiated with code and page definitions created and edited using the WBS editor 110 and stored in the site area database 124 for browsing indexable web pages 125 during editing and execution of the website 123. In some embodiments, the on-demand system 800 may be a subsystem within the WBS 100. In some other embodiments, the WBS 100 and the on-demand system 800 may share access to the front-end 126 and back-end 127 of the indexable web pages 125 of the website 123. In some embodiments, the persistent storage device 830 may be a database similar to the site area database 124 of the WBS 100. While WBS100 can store the frontend 126 in a structured data format, the on-demand system 800 may convert the frontend 126 into a code format understood by the web browser 131 of the web browsing device 130. Unlike WBS800, the on-demand system 800 typically has read-only access to the stored frontend 126 and backend 127 of the indexable web page 125 (when used for runtime services of the website). However, when used in conjunction with the WBS editor 110, the on-demand system 800 can modify the frontend 126 and / or backend 127 of the website 125, as well as other components of the website 125. The WBS100 editor is on-demand (with the editor code being part of the generic website server code 824). While it can interact with the On-Demand System 800, we want to make it clear that the editor itself can function as a higher layer of the On-Demand System 800 and does not directly influence its functionality and decisions (e.g., the allocation of execution instances to handle incoming requests).

[0274] The processor 260 may be associated with one or more servers hosting elements of the on-demand system 800. For example, the processor 260 may be associated with a single server or a group of cooperative servers (e.g., a server farm). Furthermore, in some embodiments, each of the elements (e.g., each element in memory 820, each element in persistent storage 830, proxy server 840, etc.) may have its own processor 260 (e.g., as part of a dedicated server). Regardless of the number or type of processors 260, each of the elements shown in the on-demand system 800 can function both independently and cooperatively.

[0275] Memory 820 may have one or more web server execution instances for providing a website or page to a client. The instance 821 in use may be a web server execution instance that is currently or actively providing a website. On the other hand, the available instance 822 may be a set of web server instances available in memory 820 that are not currently hosting a particular website but are capable of hosting it. In some embodiments, the number of web server execution instances within the available instance 822 may be a fixed number. In some other embodiments, the number of web server execution instances within the available instance 822 may vary and may depend on the number of web server execution instances of the instance 821 in use. For example, if there are a total of 10,000 execution instances, an increase in the instance 821 in use can mean a decrease in the available instance 822, and vice versa. The number of web server execution instances within the available instance 822 can also be a ratio of the number of web server execution instances of the instance 821 in use. The instance 821 in use may, in some embodiments, be represented by a data structure that includes a unique identifier identifying the web server execution instance 823 and other instances that are currently providing a website. In some embodiments, a similar data structure can be maintained for each website hosted by the on-demand system 800, and all such data structures collectively represent the instance 821 in use.

[0276] A web server execution instance 823 may be one of the instances 821 in use that handle requests to the website with the help of the web server. A web server execution instance 823 may include generic website server code 824 and website N-specific code 833. For example, generic website server code 824 may be common code included in all web server execution instances. Such common code may include, for example, underlying web server execution instance system elements (operating system, web server (e.g., Apache), database server, etc.). In some embodiments, such common code may also include the WBS100 editor or runtime environment, along with common external services and plugins. In addition, in some embodiments, the common code may include server-side elements at the common website application level, such as libraries, and code related to key common items, such as the WBS100 vertical application. The common code may also include elements of common components of co-hosted websites (e.g., galleries), particularly those described below. For all of the above, generic code may include actual server-side elements (which may be stored and executed on the server) and client-side elements (which are stored on the server and loaded into the WBS100 runtime client to be executed in response to web page requests). In some embodiments, different groups of websites may include different generic website server code 824. Thus, for example, a common ownership group of websites may include common generic code. A website server may have its own generic website server code 824. This can also apply to multiple sites based on the same vertical market application framework (e.g., restaurants and hotels). Alternatively, different websites may have their own generic website server code 824, which may apply to all web pages within each website.

[0277] Website N-specific code 834 may include code specific to a website or page provided by a web server execution instance 823 (such as frontend 126 or backend 127 code created by the website developer / designer 1540 for a particular site). The web server execution instance 823 can serve a website or page containing the website N-specific code 834 using a web server (e.g., Apache, Tomcat, Nginx, etc.) or a WBS-specific server. Website N-specific code 834 may include code for performing functions unique to a particular website or page, such as shopping cart functionality, payment processing, database access, app embedding or execution, or software-based router functionality. The above and hereinafter refer to website-specific code 834 associated with a given website or page, and correspondingly, a web server execution instance 823 capable of handling incoming requests from clients using the given website or page. However, the on-demand system 800 may be implemented at different levels of specific code granularity. A typical level of granularity can be the site level, i.e., the level at which the website-specific code 834 covers the entire site, which is usually the optimal level for reusing the web server execution instance 823. However, the system can also be implemented using the granularity levels of site groups (groups of very similar sites), entire sites, site sections (i.e., a set of pages), and single pages. In the case of site groups, as described above, the common parts of many sites can also be included in the generic website server code 824.

[0278] The available instance 822 web server execution instance 826 can be used to provide the same website as the instance 823 of instance 821 in use, by injecting the website N-specific code 833 into the web server execution instance 826. In this way, the web server execution instance 823 can generate (and provide) individual websites and pages based on the unique website N-specific code 834 associated with each website or page.

[0279] The persistent storage device 830 may contain general and specific codes for all websites hosted by the on-demand system 800 in a first storage location 831 and a second storage location 832, respectively. The general website server code 824 may be stored in the persistent storage device 830 in the first storage location 831, for example. Website-specific codes 833 and 834 may be stored in the second storage location 832 and may be codes specific to websites 1 and N, respectively. In various embodiments, the persistent storage device 830 may be a distributed file system, a database, or another storage system, or it may be cloud-based (e.g., storage as a service). The first storage location 831 and the second storage location 832 may be in different locations within the same storage system, or they may be in different storage systems that together form the persistent storage device 830. In some embodiments, the website-specific codes 833 and 834 may be in different secondary storage locations, or they may be in the same location but labeled separately.

[0280] The general-purpose website server code 824, located in the first storage location 831 of the persistent storage device 830, after the instance is spun up, is the same as the web server execution instance 823. It can be copied to a web server execution instance. In this way, the generic website server code 824 and any website-specific codes 833-834 can be incorporated to provide a website or page containing common systems, web frameworks, libraries, components and plugins, as well as individualized elements.

[0281] In various embodiments, each component of the memory 820, persistent storage 830, and proxy server 840 may be implemented through an on-premises computer network, a cloud computer network, or a hybrid network including both architectures. Examples of cloud hosting environments include Amazon Web Services, Microsoft Azure, IBM Cloud, and proprietary cloud networks maintained by website hosting companies.

[0282] The proxy server 840 helps determine whether a set of instances in use 821 includes web server execution instances available to process requests for websites generated from the web browser 131 of the web browsing device 130. The proxy server 840 determines the availability of web server execution instances, for example, by interacting with memory 820. For example, memory 820 may maintain a list of available instances 822 and instances in use 821, poll web server execution instances 823 and 826 to determine their current status, or receive other report information regarding the availability of web server execution instances. In some embodiments, the proxy server 840 may process HTTP requests (e.g., from a client) to access a particular website or page and determine whether a particular website or page is already hosted by web server execution instance 823. Furthermore, in some embodiments, the proxy server 840 may maintain a status table 941 for use when determining the status of available instances 822 and instances in use 821. Such a status table may identify such resources and the websites or pages they already host.

[0283] Figure 9 shows a schematic diagram of the interactions between components of the on-demand system 800 according to some embodiments of the present disclosure. As shown in Figure 2, the web server execution instance manager 950 of the on-demand system 800 manages web server execution instances by communicating with web server execution instances 823 and 826 and the proxy server 840. In some embodiments, the web server execution instance manager 950 may determine whether a new web server execution instance needs to be added to an available instance 822. This may occur, for example, when traffic related to a particular website or page being hosted increases. In some embodiments, the increased traffic load may be predicted based on prior knowledge inferred from periodic traffic information collected for the site in the past. This historical traffic information may include monthly, weekly, daily, and hourly traffic data collected to understand seasonal trends and other times when the site is most active, so that more web server execution instances serving a particular website can be automatically added. In some other embodiments, the web server execution instance manager 950 may determine whether an instance of instance 821 in use is inactive. In this situation, resources may be wasted because instance 821 is running or capable of running even though there are no requests from clients to respond to the website or pages. Therefore, as further explained below, any inactive instance 821 can be deactivated or shut down. This is similar to the process of adding a new web server running instance for a website. Similarly, using the above-mentioned predictions based on previous usage information, instances can be shut down when expected traffic is low. The web server execution instance manager 950 can delegate the decision to the proxy server 840 to add more instances to the set of available instances 822 and / or mark instances of instance 821 in use as inactive. The proxy server 840 may include a status table 941 to help determine whether to add or remove web server execution instances from instance 821 in use and instance 822 in use, as described above. The status table 941 may maintain information relating specific instances 821 in use and instance 822 in use to their current status, historical status, or expected future status. Such status information may identify specific websites or pages that are currently hosted, may potentially host in the future, or have hosted in the past. Furthermore, the status table 841 may include additional information (e.g., the amount of time instances 821 in use and instance 822 in use have hosted a website or page, the amount of time instances 821 in use and instance 822 in use have been inactive, etc.).

[0284] Figure 10 is a flowchart of a method 1000 for responding to a web request sent regarding a website, according to some embodiments of the present disclosure. The method 1000 in Figure 10 identifies two paths for processing a web request that originates from a web browser 131 of a web browsing device 130 and is received by an on-demand system 800. Setup requirements for processing the request may involve the requested website-specific code being copied to a web server execution instance that processes the request to access a particular website.

[0285] As shown in Figure 10, in step 1010, the on-demand system 800 stores the generic website server code 824 in a first storage location 831 of the persistent storage device 830. As described above, this may include storing code common to a group of websites (e.g., everything owned by a common owner, or based on a common vertical site framework) or code common to a group of pages within a website. Furthermore, the generic website server code 824 may be associated with any defined group of websites or pages. As described above, the generic website server code 824 may include code that specifies the common parts of different software layers, including the operating system, web framework, software libraries, and website components and plugins, as well as the WBS100's own editor and viewer code.

[0286] In step 1020, the on-demand system 800 may store the website N-specific code 834 in a second storage location 832 of the persistent storage device 830. As described above, the website N-specific code 834 may be specific to a particular website or web page. The website N-specific code 834 may include, for example, widgets, apps, or custom backend or frontend functionality. Furthermore, the website N-specific code 833 may function as a router for a particular website or page, as described above, to determine how one or more segments from a URL entered by the user or otherwise provided are assembled on the website or page (e.g., custom images, text, hyperlinks, forms, e-commerce functionality, personalized content, etc.).

[0287] In step 1030, the on-demand system 800 may receive a request to access a website from the web browser 131 on the web browsing device 130. The on-demand system 800 processes the request by determining whether the requested website or page is currently being processed by one or more web server running instances of instance 821 in use. As described above, this may include querying instance 821 in use itself, querying the proxy server 840, or obtaining reports from another service that monitors instance 821 in use. The current operation (or lack thereof) of instance 821 in use can also be determined by referring to a lookup table or status table. In some embodiments, a single server serves multiple websites or multiple clients of the same site, and traffic load and activity to a particular server are tracked and considered when determining which server to use to respond to additional requests.

[0288] In step 1040, the on-demand system 800 checks whether web server execution instance 823 or other web server execution instances within instance 821 in use are providing the requested website. If the answer is "yes", process 1000 may, in some embodiments, jump to step 1070, which is described below.

[0289] If the answer to step 1040 is "no", process 1000 can proceed to step 1050. If none of the web server execution instances in instance 821 in use are able to provide the requested website, the request may be forwarded to an available web server execution instance in available instance 822. In some embodiments, one of the web server execution instances in available instance 822 may be selected to provide the requested website. In other embodiments, as shown in Figure 10, web server execution instance 826 in available instance 822 receives the service provision request.

[0290] In step 1060, a request may be sent to look up a website-specific code 833 in a secondary storage location 832 that matches the requested website. For example, if a request is received for website 1 as shown in the figure, the website-specific code 833 is the matching code. In some embodiments, the website-specific code 833 that matches the requested website is identified and copied to a web server execution instance 826. The web server execution instance 826 is added to the list of instances 821 in use (e.g., in a state table or proxy server 840) and removed from the list of available instances 822. The request is responded to by the web server execution instance 826 (e.g., to the client). The process 1000 can then be repeated (e.g., up to steps 1010, 1020, or 1030). Furthermore, in step 1060, the website-specific code 833 may be fed into the web server execution instance 826 to be incorporated into the construction of the specific website or page requested by the user, as described above.

[0291] Figure 11 shows an on-demand system 800 configured to determine whether a website is hosted and to create or instantiate execution instances, according to some embodiments of the present disclosure. As shown in Figure 11, a proxy server 840 is used to determine the step of processing a request to access a website 123 received from a web browser 131 of a web browsing device 130 over the network 160. Such a determination may, before processing the request, result in immediate processing of the request by a web server execution instance manager 950 using the requested website-specific code, or instantiation of a web server execution instance in an available instance 822.

[0292] As shown in Figure 11, in step 1110, the on-demand system 800 can receive requests regarding website 123 via network 160. As mentioned above, requests may originate from a client computer or application. Requests may be HTTP requests, HTTPS requests, or other types of network requests.

[0293] In step 1120, the on-demand system 800 determines the best way to deliver the requested website 123. As described above, the determination may include identifying whether the current set of in-use instances 821 can handle the request or whether additional web server running instances are needed. For example, the on-demand system 800 may determine that the current load on the in-use instances 821 has exceeded a usage threshold (e.g., a threshold for the number of instances, the amount of bandwidth used, the percentage of bandwidth used, the level of server resource usage such as memory and processor power). In that case, it may determine that one or more available instances 822 need to be spun up or utilized to meet the demand for a particular website or page. Furthermore, as described above, the on-demand system 800 may attempt to predict the future load state of the in-use instances 821. Such predictions can be made, for example, based on previous load levels. Based on the predicted load level of the in-use instances 821, the on-demand system 800 may similarly determine that one or more available instances 822 need to be spun up or utilized to meet the predicted demand for a particular group of websites, websites, sets of pages, or pages. The on-demand system 800 may also decide to direct such incoming requests to one of the instances 821 currently in use (in order to optimize response time), and in parallel, to spin up one or more available instances 822 so that one or more available instances 822 can be used for future requests related to a given website or page.

[0294] In step 1121, as part of the determination process, the on-demand system 800 may pass control to the web server execution instance manager 950 along with a request concerning website 123 (e.g., a copy of the request, or information about the request). The request could be a request to access an indexable web page of website 123, a submission of a form, or any other type of request.

[0295] In step 1122, the web server execution instance manager 950 may delegate the decision to the proxy server 840 to help determine how to handle requests that serve website 123. This may include the types of decisions described above, such as determining the current load status associated with website 123 and predicting future load on the website.

[0296] In step 1123, the proxy server 840 may refer to its state table 941 for instances of the in-use instance 821 that can serve the requested website. In some embodiments, a lookup of the state table 941 may involve examining a column in the table called “Website” 1143 for matching website URLs. Other identifiers (e.g., URL, account name, arbitrary name, etc.) are also possible. In some embodiments, the on-demand system 800 may periodically monitor load levels based on the website traffic trend history and may automatically spin up or shut down web server running instances unless the current traffic trend suggests otherwise, so that step 1122 occurs periodically even if the on-demand system 800 has not received a website serving request. In some embodiments, web server running instances After failing to process the request, manager 950 forwards the request for website 123, indicating that no web server execution instance is available to process the request for website 123.

[0297] In step 1123, the proxy server 840 may send a request to the available web server execution instances 822 to select a first available web server execution instance 826 that is marked to process the request for website 123. In other embodiments, the web server execution instance 826 may be selected based on a policy that takes into account the differences between the web server execution instances 826, which would be appropriate or better suited to processing the request (e.g., geographical location, running application, available memory, processing power, disk / memory fragmentation level, etc.).

[0298] In step 1124, the on-demand system 800 selects a web server execution instance from the available instances 822 to process requests for website 123. In some embodiments, web server execution instance 826 is selected to process requests for website 123.

[0299] In step 1125, web server execution instance 826 may be added to a set of instances 121 in use by injecting website 123-specific code 833 into web server execution instance 826. In some embodiments, the on-demand system 800 may request the proxy server 840 to update the state table 941 with an entry for web server execution instance 826. Thus, the state table 841 may be modified, including adding rows to the state table with identifiers for instance 1142 and website 1143. In some embodiments, a first available instance, such as web server execution instance 826, may be selected to be injected with site-specific code 833. After this injection, web server execution instance 826 is removed from a set of available instances 822.

[0300] In other embodiments, the selection may be based on geographical proximity to the request location of website 123, or the number of potential web requests that may originate from a particular geographic location. In some embodiments, multiple web server running instances may be assigned a website 123-specific code 833 and added to a set of instances 821 in use.

[0301] The decision 1120 that processes the requested website 123 may further have a timeout threshold (e.g., 10 or 100 milliseconds). The timeout period may be consistent with common web standards for processing web page requests. The web server running instance, which is part of the available instances 822, helps reduce the time it takes to spin up the instance when a new website request is made. Thus, the cold start problem of preceding traditional website building systems is mitigated.

[0302] In step 1130, the web server execution instance 826 can process requests for website 123 using website 123-specific code 833. As described above, by providing a website or page generated using website 123-specific code 833, the website content can be tailored to the user or how the user arrived at the site (e.g., using a software-based router). In some embodiments, the submission step itself can modify the submitted material, for example, tailoring the submitted material to the specific user / platform / device or other “environment” conditions making the request (e.g., country, language, accessed database, user access history, etc.). The client code initiating the request adds additional parameters or information to the network request so that the injecting module can perform such adaptations. This additional information can be added directly (e.g., as an added URL or other request parameter) or indirectly (e.g., through an additional request, prior storage in a database, or otherwise).

[0303] Figure 12 illustrates the instantiation of server infrastructure elements in a website according to several embodiments of the present disclosure. The technique in Figure 12 may be implemented in the systems disclosed above and described throughout this disclosure.

[0304] As shown in Figure 12, the website 123 may be served through a web server execution instance by copying the website 123-specific code 833 to a container 1221 or virtual machine 1222. In some embodiments, the website 123 may be served by a separate operating system process 1223 (e.g., via serverless code). The website 123-specific code 833 may include a frontend 126, a backend 127, and a plug-in reference code 1226, as described above in relation to customized backend functionality that may be served by the website. In some embodiments, the frontend 126, the backend 127, and the plug-in reference code 1226 may be copied individually to a container 1221, a virtual machine 1222, or a process 1223. In some embodiments, generic website server code 824 may be copied to a container 1221 or virtual machine 1222 (later including the website 123-specific code 833) as part of the instantiation of the web server execution instance 826.

[0305] In some embodiments, the use of the on-demand system 800, such as through a serverless code implementation, can improve processing time and server utilization while reducing user waiting times. In the serverless code embodiment, there are no dedicated servers to manage. Instead, the code (e.g., frontend 126, backend 126, and plug-in reference code 1226) is provided as code in the cloud and can be executed on demand. Users may be charged proportionally to the actual execution of the code, to the extent that they are charged for the execution of the code (not based on dedicated infrastructure costs or servers that must remain assigned to a given site while waiting for incoming requests). Alternatively, this can significantly reduce costs for online WBS vendors while enabling them to provide better service to users. In some embodiments, the on-demand system 800 may define a set of programming languages ​​or web frameworks that support processing the serverless code. The On-Demand System 800 can also support WebSocket, streaming or chunked communication, additional protocols (e.g., TCP and UDP), memory as a service functionality (e.g., for stateless, side-effect-free code functionality), and native serverless options (e.g., Go, Rust, C). The ability to process serverless code on demand mitigates the problems of traditional website hosting systems (e.g., going through a "cold start" to load a machine or website instance). Website or page startup times (including the running code) can be less than 100 milliseconds, resulting in reduced latency and an improved user experience. In contrast, some traditional systems have website or page startup times of approximately 600 milliseconds to 2 seconds, including overhead scheduling, instance startup, process startup (e.g., code execution), and request handler functionality.

[0306] Website execution instance 826, container 1221, virtual machine 1222, Alternatively, multiple websites can be served via process 1223. In some embodiments, a web server execution instance 826 may have a set of resources dedicated to or available for it: containers 1221, virtual machines 1222, and process 1223. Multiple containers 1221, virtual machines 1222, and process 1223 can serve multiple websites. In some embodiments, a variation of the website execution instance 826 serving multiple websites may include a single container 1221, virtual machine 1222, or process 1223 that can serve multiple websites. A container 1221, virtual machine 1222, and process 1223 serving multiple websites needs to copy site-specific code for multiple websites to handle various website requests.

[0307] Figure 13 illustrates techniques for load monitoring of a hosted website and for managing instances 821 in use, according to several embodiments of the present disclosure. These techniques may be implemented in the system as described above.

[0308] As shown in Figure 13, the web server execution instance manager 950 (as described above in relation to Figure 11) monitors or communicates with the load monitoring unit 1310 to determine whether the load on any of the websites provided by the on-demand system 800 is greater than the desired or planned load. As described above, this can be determined based on current, past, or future load characteristics. In some embodiments, future loads can be predicted based on prior knowledge based on collected periodic loads of past websites / multiple websites hosted by the web server. Past loads may include monthly, weekly, daily, and hourly loads to understand seasonal trends and other times when site usage is most active, so that more web server execution instances providing a particular website or group of websites provided by the web server can be automatically added.

[0309] If the website load is relatively light, some instances are removed from a set of active instances 821 of a particular website and returned to available instances 822. In some embodiments, the load monitoring unit 1310 lists all websites 1311 and their loads 1312 hosted by the on-demand system 800 in a tabular format. In some embodiments, the load monitoring unit 1310 table listing the website loads may be managed by the proxy server 840 or be part of an accessible status table 941. In some other embodiments, the load monitoring unit 1310 may be a separate table within the proxy server 840. In other embodiments, the load monitoring unit 1310 may reside in the memory 820 of the on-demand system 800.

[0310] In some embodiments, the instance in use 821 may be a collection of separate sets of instances hosting some or all of the websites of the on-demand system 800. In some embodiments, as shown, websites 123 and 2 are websites hosted by the on-demand system 800. In various embodiments, the website 123 assigned instance 1320 and the website 2 assigned instance 1330 are a set of web server running instances for websites 123 and 2. In some embodiments, the website 123 assigned instance 1320 and the website 2 assigned instance 1330 are together considered to be the instance in use 822.

[0311] The load table of the load monitoring unit 1310 may be updated directly by the web server execution instance manager 950, or an update may be requested from the proxy server 840. In some embodiments, the load table of the load monitoring unit 1310 is updated by the on-demand system 8 The load table of the load monitoring unit 1310 is periodically updated by the proxy server 840 based on the number of access requests to the website 1311 hosted by 00. The load table of the load monitoring unit 1310 may be updated based on usage statistics of other websites. For example, for a multimedia-heavy website, the usage statistics may include the memory and processor cycle usage for processing website requests, including converting video and audio to different formats based on the user's device environment. When the load on the hosting website decreases, the web server execution instance of instance 821 that is currently in use is moved to an available instance 822. Similarly, when the load on a website increases, the web server execution instances of available instance 822 are marked as instance 821 in use, and website-specific code for the heavily loaded website is fed to these web server execution instances.

[0312] In some embodiments, based on the proxy server 840 observing that the load on website 123 is light, the on-demand system 800 may move web server execution instance 826 from the website 123 allocated instance set 1320 to the available instance set 822. In some embodiments, web server execution instance 1323 is moved to the available instance set 822. In some embodiments, multiple web server execution instances are moved to the available instance set 822 simultaneously. If the proxy server 840 observes in the load monitoring unit 1310 that the load on website 2 is heavy, it may move web server execution instance 1127 from the available instance set 822 to the website 2 allocated instance set 1330. As part of step 1342, website 2 may have site-specific or page-specific codes that are put into web server execution instance M 1127 before it is moved to the website 2 allocated instance set 1330. Naturally, steps 1341 and 642 are independent and do not need to occur together or in a particular order.

[0313] Figure 14 illustrates the monitoring of available web server execution instances for hosting according to some embodiments of the present disclosure. As shown in Figure 14, the web server execution instance manager 950 monitors the number of available instances 822. As described above, if the number of web server execution instances in a set of 822 available instances is below a threshold, the web server execution instance manager 950 can spin up new instances and add them to the pool of 822 available instances. If the number of web server execution instances is greater than the threshold, the web server execution instance manager 950 can shut down instances in a set of 822 available instances. These techniques for spinning up and shutting down execution instances may take into account current, past, or anticipated future demand for a particular website or page, as described above.

[0314] In some embodiments, the web server execution instance manager 950 may wait for a certain period of time before spinning up a new instance to ensure that inactive instances identified through the state table 841 are not added back to the pool. Similarly, in some embodiments, the web server execution instance manager 950 may wait for a certain period of time before shutting down an available instance to ensure that it is not necessary to inject website-specific code into the instance to handle new website requests. Instance shutdown and spin-up can be time-consuming processes, and the website execution instance manager 150 avoids doing so frequently by waiting after discovering that the number of available instances has deviated from a threshold number.

[0315] In some embodiments, the web server execution instance manager 950 spins up and shuts down web server execution instances if the current number of instances in the set of available instances 822 differs from a specified number or percentage from a threshold. This allows a range of values ​​to exist at any given time with respect to the number of available instances 822. In other embodiments, the web server execution instance manager 850 can react immediately to deviations from the threshold by spinning up and shutting down instances.

[0316] Figure 15 shows an exemplary website real-time testing system according to several embodiments of the present disclosure. As shown in Figure 15, the website real-time testing system 1500 comprises a processor 260, memory 820, a site area database 124 for storing data used by the website, and a deployment environment 1510 that provides access to data related to the website being accessed. In some embodiments, the website real-time testing system 1500 may also comprise a test environment 1520 that provides access to data related to the website being accessed for testing purposes. The terms test / deployment may be replaced with alternative terms such as development / runtime, staging / production, and test / live.

[0317] In some embodiments, the on-demand system 800 may be a subsystem included as a whole in the website real-time testing system 1500. In some embodiments, the website real-time testing system 1500 may be partially composed of the on-demand system 800 or may include the on-demand system 800.

[0318] Deployment environment 1510 can be a set of software components running on a web server execution instance of on-demand system 800.

[0319] The test environment 1520 is a set of software components that run on a web server execution instance of the on-demand system 800. In some embodiments, the test environment 1520 is generated based on the type of device used to access the website. For example, a website 123 accessed via a web browser 141 on a web browsing device 140 may produce a test environment 1520 that may look and feel different depending on whether the web browsing device 140 is a desktop computer or a mobile phone. In some other embodiments, the test environment 1520 may be generated based on which user is accessing the website. For example, a developer / designer 1540 requesting access to website 123 may create a test environment 1520. In some embodiments, the test environment 1520 may be shared among users. The test environment 1520 may differ for each user. In some embodiments, the test environment 1520 may be shared across multiple websites stored in a site area database 124. In some embodiments, an instance of the test environment 1520 is always available, and the developer / designer 1540 can choose to access a given website via the test environment 1520 or via the deployment environment 1510.

[0320] The end user 1530 can access the website and its data in the deployment environment 1510 via the network 160. In some embodiments, the end user 1530 may access the website 123 via a web browser 131 on a website viewing device 130, consistent with the embodiments described above.

[0321] Developer / designer 1540 is in test environment 1520 via network 160. The website and its data are accessible. The developer / designer 1540 can access the website 123 via a web browser 141 on the website development device 140. In some embodiments, the developer / designer 1540 can access the website 123 in the deployment environment 1510 by using a web browser 131 on a web browsing device 130. Note that the web browsing device 130 and the development device 140 may be the same device.

[0322] End-user 1530 and developer / designer 1540 may be different roles of the same user accessing website 123. In some embodiments, a user can change roles by accessing website 123 using different devices. For example, a user accessing website 123 using a WBS vendor staff device 150 or a website development device 140 may be considered a developer / designer 1540. A user accessing website 123 using a website browsing device 130 may be considered an end-user 1530. The website may be accessed using either the deployment environment 1510 or the test environment 1520, depending on whether the user is an end-user 1530 or a developer / designer 1540. The website may also be accessed using either the deployment environment 1510 or the test environment 1520, depending on whether the request originates from the website browsing device 130 or the website development device 140. In some embodiments, the website may be accessed using either the deployment environment 1510 or the test environment 1520, depending on the combination of user and device type.

[0323] Figure 16a shows a schematic diagram of a development environment 1510 for accessing data elements according to some embodiments of the present disclosure. As shown in Figure 16a, the deployment environment 1510 may request the processor 260 to assist in accessing live data 1610. The deployment environment 1510 cannot access test data 1620, which is indicated by a dashed line. Figure 16b shows a schematic diagram of a test environment 1520 for accessing data elements according to some embodiments of the present disclosure. As shown in Figure 16b, the test environment 1520 can request the processor 260 to assist in accessing live data 1610 and test data 1620. A developer / designer 1540 accessing website 123 using the test environment 1520 can request data elements associated with indexable web pages 125 of website 123. The test environment 1520 can be configured to receive requests from users for data elements and can forward the requests to test data 1620. In some embodiments, test data 1620 may determine whether the requested data element exists in test data 1620, or it may forward the request to live data 1610. In some embodiments, the test environment 1520 itself may determine whether to request live data 1610 or test data 1620 for a particular data element. In some embodiments, the test environment 1520 may access live data 1610 and test data 1620 after copying them to memory 820.

[0324] Figure 17 illustrates website access to live and test data in a test environment 1520 according to several embodiments of the present disclosure. As shown in Figure 17, an indexable webpage 125 of website 123 is accessed using a web browser 141 on a web development device 140. The indexable webpage 125 and associated data elements are accessed via the test environment 1520.

[0325] The indexable web page 123 can access both the live data 1610 and the test data 1620 as part of accessing the data elements associated with the indexable web page 125. In some embodiments, access to the data elements All requests to be performed may first be sent to test data 1620. Before forwarding the request to live data 1610, test data 1620 may filter out data element access requests that can be processed by test data 1620 itself.

[0326] Figure 18 illustrates the generation of test data used in a test environment 1520 for testing a website, according to some embodiments of the present disclosure. As shown in Figure 18, live data 1610 forms part of test data 1620. In some embodiments, the order in which data marked as inserted 1730 and data marked as deleted 1740 are added may differ. Data marked as inserted 1730 and data marked as deleted 1740 may be traversed in parallel to avoid deleting data marked as deleted in data marked as deleted 1740 after adding data in test data 1620.

[0327] Data marked as inserted 1730 and data marked as deleted 1740 may be retained in the site area database 124. In some embodiments, data marked as inserted 1730 and data marked as deleted 1740 may reside in memory 920 until a session accessing the website 123 in the test environment 1520 becomes active. Once the session becomes inactive, data marked as inserted 1730 and data marked as deleted 1740 may be retained in the site area database 124. For example, a developer / designer 1540 can explicitly request that data marked as inserted 1730 and data marked as deleted 1740 be retained in the site area database 124. In some embodiments, data marked as inserted 1730 and data marked as deleted 1740 may share the same location within the site area database 124. Data marked as inserted 1730 and data marked as deleted 1740 may be retained based on the number of read requests. Data elements within data 1730 that have been marked as inserted may be selectively retained in the site area database 124. Data elements may be selectively retained based on additional criteria, such as the number of times the data element has been requested to be read, the amount of time a particular data element has remained unchanged, or the number of sessions in which the data has been accessed.

[0328] Figure 19 is a flowchart illustrating how to access a website in a deployment environment according to some embodiments of the present disclosure.

[0329] As shown in step 1910, data elements that are updated and added when the website is accessed in the deployment environment 1510 are stored in the live data 1610 of the site area database 124.

[0330] In step 1920, the live data 1610 stored in the site area database 124 associated with the indexable web pages of the website accessed in the deployment environment 1510 is accessed by the website real-time testing system 1500 as part of providing the web pages requested by the user.

[0331] In step 1930, the data elements accessed in step 1920 are applied to an indexable webpage associated with rendering the webpage in the web browser 131 of the web browsing device 130 used by the end user 1530.

[0332] Figure 20 shows access to a website in a test environment according to some embodiments of the present disclosure. This flowchart shows how to do it in 2000.

[0333] In step 2010, the website real-time testing system 1500 may receive a request to perform a test on a website (e.g., website 123) stored in a common database (e.g., site area database 124). In step 2020, the website real-time testing system 1500 processes data requests made as part of the process of testing a website using the test environment 1520. For example, website 123 may be tested by a developer / designer 1540 by accessing website 123 using a web browser 141 on a website development device 140. For example, the developer / designer 1540 may request an indexable webpage 125 of website 123 by entering a URL. Furthermore, in some embodiments, the URL may be specified by an application. The request includes both a request to the frontend 126 and a request to data elements of a data group 210 associated with the indexable webpage 125 of website 123. Data retrieval requests may be made as part of the process of accessing a webpage.

[0334] As shown in Figure 20, in step 2030, the website real-time testing system 1500 checks whether the test is complete. In some embodiments, the website test is considered complete if the website is accessed through the test environment 1520 for a certain period of time. The test may be considered complete after a certain number of data requests. The test may also be considered complete when a developer / designer 1540 who accesses the website via the web browser 141 of the website development device 140 closes the browser tab or window used to access the website. The test may also be considered complete if the developer / designer 1540 explicitly requests completion of the test from the website real-time testing system 1500. If the answer to step 2030 is "no", method 2000 may return to step 2010 and prepare to receive the next data request. If the answer to step 2030 is "yes", method 2000 may proceed to step 2040. In step 2040, method 2000 can apply changes made to data elements and stored in test data 1620 to the corresponding data elements in live data 1610. Step 2040 may be optional, as the developer / designer 1540 may request, for example, to drop data changes incorporated into test data 1620.

[0335] In step 2050, all markers associated with updates to data elements made during testing of website 123 in test environment 1520 may be removed.

[0336] Figure 21 is a flowchart illustrating a method 2100 for processing data requests in a test environment 1520, according to several embodiments of the present disclosure. The method 2100 in Figure 21 identifies one of five exemplary paths for processing incoming requests relating to data elements associated with a website accessed by a developer / designer 1540.

[0337] As shown in Figure 21, in step 2110, the website real-time testing system 1500 receives a data request in the test environment 1520. The data request is part of accessing the website to test in the test environment 1520. For example, a developer / designer 1540 accessing the website 123 via the website development device 140 may bring a request regarding a data element 211 of a data group 210 associated with the website 123.

[0338] In step 2120, the website real-time testing system 1500 is used. The type of request to access data elements associated with the tested website is determined. This determination allows for the processing of various types of requests. A data request may be a read request to access data elements associated with a website being tested by developer / designer 1540 when the developer / designer 1540 requests an indexable webpage by entering a URL. In some embodiments, a data request may be a write request to add data elements. For example, developer / designer 1540 testing website 123 may submit a form on indexable webpage 125 requesting the creation of a new data element to add to data group 210. A data request may be an update request to modify the content of data elements associated with a website being tested by developer / designer 1540. A data request may be a delete request to remove data elements associated with a website being tested by developer / designer 1540.

[0339] In step 2121, the website real-time testing system 1500 determines in step 2120 that the data request is to retrieve data elements associated with the website being tested by the developer / designer 1540, or to view the results of such a retrieval operation.

[0340] In step 2122, the website real-time testing system 1500 determines in step 2120 that the data request is to retrieve data elements associated with the website being tested by the developer / designer 1540.

[0341] In step 2123, the website real-time testing system 1500 determined in step 2120 that the data request is to add data elements associated with the website being tested by the developer / designer 1540.

[0342] In step 2124, the website real-time testing system 1500 determined in step 2120 that the data request is to update a data element associated with the website being tested by the developer / designer 1540.

[0343] In step 2125, the website real-time testing system 1500 determined in step 2120 that the data request is to delete a data element associated with the website being tested by the developer / designer 1540.

[0344] Figure 22 is a flowchart illustrating a method 2200 for processing a read request in a test environment, according to some embodiments of the present disclosure. The method 2200 in Figure 22 identifies three paths to determine whether a response is required to the data request, and if so, which data elements, test data 1620 or live data 1610, to use.

[0345] As shown in Figure 22, in step 2122, the received data request is determined in method 2100 to be a read request for data elements in the site area database 124 and memory 820.

[0346] In step 2210, the website real-time testing system 1500 looks up the requested data element in the test data 1620 and, if a match is found, checks whether it is marked as deleted. If the answer to step 2210 is "yes", method 2200 proceeds to step 2120 and method 2200 can be considered complete. In step 2, the message "Data element not found" is not returned. For example, indexable web page 12 of website 123 A developer / designer 1540 accessing 5 can send a request for data element 1741 of data 1740 that has been marked as deleted in test data 1620, and receive the message "Data element not found".

[0347] If the answer to step 2210 is "no", method 2100 can proceed to step 2130. As shown in Figure 22, in step 2230, the website real-time testing system 1500 looks up the requested data element in the data 1730 that has been marked as inserted into the test data 1620.

[0348] If the answer to step 2230 is "yes", method 2200 can proceed to step 2240. In step 2240, the requested data element is found in test data 1620 and returned. The requested data element may be in data 1730 marked as inserted in test data 1620 because it was previously added as a new data element. Furthermore, the requested data element may be in data 1730 marked as inserted because it was previously updated during testing of the website. For example, a request from developer / designer 1540 to access the data element 1760 for contact 2 in test environment 1520 will return data element 1732 in data 1730 marked as inserted in test data 1620 after method 2200 has performed step 2240. Requesting the same data element in deployment environment 1510 may return data element 1752.

[0349] If the answer to step 2230 is "no", method 2200 can proceed to step 2250. In step 2250, the requested data element is returned from live data 1610.

[0350] Figure 23a is a flowchart illustrating a method 2300 for updating data elements in a test environment, according to some embodiments of the present disclosure. The method 2300 in Figure 23a defines a location to store updated data elements requested during testing of a website.

[0351] As shown in Figure 23a, in step 2124, the received data request is determined in method 2100 to be a request to update data elements present in live data 1610 or data 1730 that has been marked as inserted in test data 1620 during website testing.

[0352] In step 2310, the website real-time testing system 1500 determines the location of the data element that is being updated by first checking in the data 1730 that has been marked as inserted into the test data 1620.

[0353] If the answer to step 2310 is "yes", method 2200 proceeds to step 2320. In step 2320, the data element corresponding to the one being updated is updated.

[0354] If the answer to step 2310 is "no", method 2200 proceeds to step 2330, instructing that the data element for which an update is requested has not been updated in the past and exists only in live data 1610. To avoid future access to the data in test environment 1520, the data element in live data 1610 is copied to data 1740, which is marked as deleted.

[0355] In step 2340, the website real-time testing system 1500 inserts the updated data elements into the test data 1620. In some embodiments, adding data elements involves adding database entries and adding them via the test environment. This includes marking additional columns. Data elements inserted into data 1730 marked as inserted in test data 1620 from the test environment 1620 are not accessible by requests in the deployment environment 1610. For example, a request by developer / designer 1540 to update data element 1752 via website 123 inserts data element 1732 into data 1730 marked as inserted in test data 1620.

[0356] Figure 23b is a flowchart illustrating another method 2300 for updating data elements in a deployment environment 1510, according to some embodiments of the present disclosure. This method ensures that developers / designers 1540 testing the website using a test environment 1520 have live data 1610 available in real time.

[0357] In step 2350, a request to update a data element is received in the deployment environment 1510.

[0358] In step 2360, the data elements in the live data 1610 are updated according to the request.

[0359] In step 2370, a lookup request is made to data 1740, which is marked as deleted, to identify the data element that was updated in live data 1610 in step 2360. The corresponding data element found in data 1740, which is marked as deleted, has been updated or deleted in test environment 1520.

[0360] If the answer to step 2370 is "no", method 2300 proceeds to step 2380, where the task is considered complete, and method 2300 terminates.

[0361] If the answer in step 2370 is "yes", method 2300 proceeds to step 2390. In step 2390, the data elements that were requested to be updated via the deployment environment 1510 are updated in the data 1740 that was marked as deleted. As a result, the data elements that were updated in the live data 1610 are no longer included in the query results, as described in process 2500 below.

[0362] Figure 23c is a flowchart illustrating another method 2300 for adding data elements in a test environment, according to some embodiments of the present disclosure. Method 2300 in Figure 23c defines a location to store new data that is requested to be added during testing of a website.

[0363] As shown in Figure 23c, in step 2123, the received data request is determined in method 2100 to be a request to add a new data element to test data 1620 that is not present in live data 1610 during website testing.

[0364] In step 2392, the website real-time testing system 1500 inserts data elements into the test data 1620. In some embodiments, adding data involves adding a database entry and marking the additional column as added via the test environment. Data elements inserted into the data 1730 marked as inserted in the test data 1620 from the test environment 1620 are not accessible by requests in the deployment environment 1610. For example, if a developer / designer 1540 requests the addition of data element 1731 via the website 123, data element 1731 may be inserted into the data 1730 marked as inserted in the test data 1620.

[0365] Figure 24 shows how to remove data elements from a test environment according to some embodiments of the present disclosure. This is a flowchart of method 2400. As shown in Figure 24, the data element to be deleted may be presented in live data 1610, or it may have been previously added via the test environment and is present in data 1730 that has been marked as inserted.

[0366] As shown in Figure 24, in step 2125, the received data request is determined in method 2100 to be a deletion request for a data element in the site area database 124 or memory 820.

[0367] In step 2410, the website real-time testing system 1500 may insert the data element requested to be deleted into the data 1740 marked as deleted in the test data 1620. Any data element, whether added or updated in the test environment, may be added to the data 1740 marked as deleted, since all data elements in the data 1740 marked as deleted may be skipped when a request is made regarding the data element associated with the website being tested.

[0368] In step 2420, a lookup of the data element to be deleted is performed in the data 1730 marked as inserted in the test data 1620. If no such data element is found in the test data 1620, process 2300 is considered complete. For example, a developer / designer 1540 testing website 123 with web browser 141 requests the deletion of data element 1741, which results in data element 1741 being inserted into data 1740 marked as deleted. The absence of data element 1741 in data 1730 marked as inserted indicates that no data needs to be removed, and process 2400 is considered complete. If the answer in step 2420 is "no", method 2400 does not find the data element 1730 to be deleted in the data 1730 marked as inserted, method 2400 proceeds to step 2430, where the task is completed, and method 2400 terminates.

[0369] If the answer to step 2420 is "yes", then method 2400 finds the data element that was requested to be deleted in the data 1730 that has been marked as inserted. In step 2440, the data element from test data 1620 is removed from the data 1730 that has been marked as inserted.

[0370] Figure 25 illustrates an overlay process for generating results from querying test data according to several embodiments of the present disclosure. As shown in Figure 25, Method 2500 is a four-step process that accesses in parallel live data 1610, test data 1620, data marked as inserted 1730, and data marked as deleted 1740.

[0371] As shown in Figure 25, in step 1, data elements consistent with the query are accessed from live data 1610, data marked as inserted 1730, and data marked as deleted 1740. In some embodiments, data elements are accessed by querying the site area database 124 against live data 1610, as well as the data marked as inserted 1730 and data marked as deleted 1740 of test data 1620. In some embodiments, the query results may be configured as a single fused table 2510.

[0372] The data elements are sorted as requested in the query. In some embodiments, the data elements are sorted in descending order by column "B" of 2510. In some embodiments, the order may include multiple columns. In some embodiments, if there is no requested order... In addition, a random column is selected and sorted in ascending or descending order. In some embodiments, a primary key is added to the column used for sorting.

[0373] In step 2, the system simultaneously traverses the data elements of live data 1610, data marked as inserted 1730, and data marked as deleted 1740 to select the data elements to include in test data 1620.

[0374] To determine which data elements to include in test 1720, pointers are set to the first elements of live data 1610, data marked as inserted 1730, and data marked as deleted 1740. In some embodiments, the pointers are placed on the youngest data element based on column "B". The youngest data element is identified by comparing the current youngest records of live data 1610, data marked as inserted 1730, and data marked as deleted 1740. The youngest that can be found may exist in multiple locations. For example, data elements 2520 and 2530 are the youngest data elements of live data 1610 and data marked as deleted 1740, and have the same content.

[0375] Once the youngest data element is identified, it is determined whether or not to include the data element in test data 1620 based on the following rules: If a data element exists in both live data 1610 and data marked as deleted 1740, the data element is skipped from being included in test data 1620. For example, data elements 2520 and 2530 have the same content and exist in live data 1610 and data marked as deleted 1740, indicating that the deletion of the data element was requested in test environment 1520 during previous website testing. They may also have been updated, and data element 2560 was the resulting updated element.

[0376] If a data element exists only in live data 1610, then the data element is included in test data 1620. For example, data element 2540 exists only in live data 1610, indicating that it was not modified or deleted in the test environment when testing the website associated with data element 2540.

[0377] If a data element exists only in data 1730 that is marked as inserted, it will be included in test data 1620. For example, data element 2540 exists only in data 1740 that is marked as deleted, indicating that it was either inserted as a new data element or inserted as part of an update to data element 2520 during website testing.

[0378] When a data element is included or skipped, only the source of the data element with the youngest data element has a pointer to move to the next data element. In some embodiments, the pointers to live data 1610 and data marked as deleted 1740 are moved to the next record after the first iteration of the traversal.

[0379] Method 2500 terminates when the last data element is reached from all three sources of data elements, and test data 1620 is obtained. The fused table 2560 shows the youngest data element identified in each iteration of step 2 described above. Only the source with the youngest data element is filled in and displayed, the rest remain empty. For example, in the first iteration of step 2, the youngest data elements 2520 and 2530 with the same content are displayed as part of their respective sources, namely live data 1610 and data marked as deleted 1740, and data marked as deleted 1740 is empty, indicating that it did not have the youngest data element. Similarly, in the last iteration, only data marked as inserted 1730 is shown in the last row of the fused table 2560. It has the youngest data element, 2550.

[0380] Figure 26 shows a flowchart illustrating the steps of Method 2600 for editing a database during a website preview, according to several embodiments of the present disclosure. Method 2600 may be implemented in the system environments described throughout the present disclosure, such as Figures 1, 2, and 15.

[0381] As shown in Figure 26, step 2602 may include receiving one or more groups of data elements (for example, from a user of the website building system). Data elements may include various different types of content or records of content that can be incorporated into a website, such as text, images, videos, advertisements, and database output displays, as described above. In some embodiments, a data element may further include a set of data objects (e.g., two instances of text and one image). Each group may have one or more data elements. Thus, a group can define one or more elements of an associated set. For example, a first website or page (e.g., a web page identifier) ​​may be associated with a group containing only text; a second website or page may be associated with a group containing data elements (each containing one text and three images); and a third website or page may be associated with a group containing data elements such as text and video. As described above, a user can identify groups of data elements that should be displayed on or associated with individual web pages of a website or a given virtual page template via a website editing interface.

[0382] In some embodiments, a data group can be a site-level entity that can be used and reused across multiple pages of a website, or an owner-level entity that can be used and reused by a specific website owner. Furthermore, a data group can also be a system-level entity (e.g., a database such as zip codes or geographical area descriptions) or a page-level entity.

[0383] Method 2600 may also include step 2604 storing one or more groups of data elements in a site area database 124, consistent with the embodiments described above. Examples of such databases are described above (for example, in relation to Figures 1, 2, 15, etc.). The database may be configured to maintain each group, to maintain associations between the groups and websites or pages or virtual page templates, and to store other content and information. As will be further described below, when a user edits a virtual web page in preview mode, such edits are translated into edits to the database in real time, so that an up-to-date database is maintained for each web page.

[0384] In addition, method 2600 may include step 2606 of generating one or more virtual web pages. Each virtual web page may represent data elements (consisting of one or more objects) that can be displayed in a (development) preview mode before the actual website or an updated portion thereof becomes live (i.e., accessible to other users over the internet). To publish the collection of virtual web pages in live mode, the user can select an option with a title such as “Publish” or “Post,” which makes the website accessible over the internet (publishing is usually done at the site level, not a single page level). Once published, the virtual pages (i.e., instances derived from web page template 2704) may behave like ordinary (actual) pages, despite being dynamically generated. In this embodiment, each actual web page is not designed to update the database, but a virtual web page may be designed to do so. For example, a hotel booking site may maintain five different virtual page templates for five different types of rooms available at a particular hotel (e.g., single bed, double bed). Each virtual page template can be associated with its own group of data elements (i.e., records for a given type of room), and thus each room may have a virtual web page that can be displayed and edited as a virtual web page during preview mode.

[0385] Furthermore, method 2600 may include step 2608, which displays each group of data elements in at least one separate virtual webpage set. For example, in the hotel website hypothesis described above, during preview mode, each of the five virtual webpage templates corresponding to different types of rooms in the hotel may have associated groups of data elements (e.g., different text describing the room, images of the room, videos of the room, etc.). The generated virtual webpage set (i.e., instances) may be displayed to the user via a browser or other client, as described above in relation to other techniques.

[0386] Method 2600 may also include step 2610, which includes displaying editing tools that allow the user to edit one or more of the virtual webpage templates and instances. Templates can be edited as if they were regular pages. Instances may only be editable in preview mode, as they may not be displayed as part of the normal editor page browsing and editing process. In an alternative embodiment, the system may allow the editing of instances as part of the normal site editing process. Various editing tools may be available, such as rulers and grids (e.g., for aligning data elements), drag-and-drop selectors (e.g., for moving data elements with a cursor), inserting and editing hyperlinks, embedding widgets or apps (e.g., from an app store), inserting and editing buttons, creating and editing text, inserting and editing images, inserting and editing videos, creating and editing slideshows, cursor hover functionality, background styles, repeaters (e.g., for creating multiple versions of a particular data element or group), and software-based routers (e.g., for creating different versions of a webpage based on elements of the URL used for access). The system can display (and operate) different subsets of editing tools available for templates and instances, and can also customize the displayed subset of editing tools depending on the user, virtual page template, specific instance, underlying connected data group or element, etc. As further described below, users can edit virtual web page templates and instances through editing tools, and that editing can be translated into edits to a database that maintains component information and / or content for the web page.

[0387] Method 2600 may also include step 2612 of associating a unique URL with each virtual webpage. For example, a website may have a domain name (e.g., wix.com), and each page within the website may have a different suffix (e.g., wix.com / page1, wix.com / page2, wix.com / page3, etc.). Furthermore, in some cases, the URLs associated with virtual webpages may have different paths or parameter values ​​(referring to files or directories). In some embodiments, a software-based router may be configured for the website or individual webpages. The software-based router may, for example, associate a particular URL prefix, path, segment, or parameter with a particular webpage. It is configurable. Each webpage can be configured to pull different data from a database that stores data elements. For example, in a JavaScript implementation, an incoming request for a webpage may be associated with an object containing information about the request (e.g., URL, where it came from, who it came from, etc.). A software-based router can process this information and determine which webpage (and possibly a virtual webpage) to display and which data elements to include.

[0388] In addition, method 2600 may include step 2614 of displaying user-selectable features (e.g., buttons, scroll bars, links, etc.) that allow the user to navigate between virtual web pages in order to display each of the virtual web pages individually and dynamically. Thus, in the example above, the user-selectable features allow the user to browse each of the five sets of web pages corresponding to different room types in the hotel. Each page is dynamically selected and viewed as a virtual web page.

[0389] Method 2600 may further include step 2616 of receiving edits from a user to one or more virtual webpage attributes. For example, using the editing tools described above, a user may also change the page background, the page layout or template, apps or widgets embedded in the page, URL prefixes or suffixes associated with the page, repeater functionality within the page, or software-based router functionality for the page, or perform various other types of edits. Changes made to the webpage template 2704 may be written directly to the template page definition in the site area database 124. Changes made to a virtual page instance may be stored in a separate database, which shall contain adaptations to the virtual page instance. In such a scheme, the adaptations shall be indexed with a unique index for a particular virtual page instance (for example, "Single Bedroom #1234" in the hotel example above). Each time this virtual page instance is generated for display (for example, during preview or live display), the adaptations are retrieved and reapplied.

[0390] In some embodiments, users are permitted to edit a virtual page instance, but only with respect to field information (e.g., text, graphics, video, etc.). For example, in such embodiments, users may be prohibited from editing other elements of the virtual page instance (i.e., non-content), including layout, attributes, etc.

[0391] Method 2600 may also include step 2618, which receives edits to the data element itself. Such edits may be made directly to the display of the data group (i.e., the display user interface elements that enable viewing and editing of the underlying data group and elements). Alternatively, such edits may be performed through editing the field content of the generated virtual page instance associated with the item. The system may enable such edits by adding additional editing controls to the virtual page instance displayed (in preview mode) (such as a “Select Another Image” button added to each display image derived from the data group). As mentioned above, the data elements may be stored in a database. Edits may include editing text, replacing or modifying images, replacing or modifying videos, changing the functionality that causes the cursor to hover over an element, and various other types of edits.

[0392] In addition, method 2600 may include step 2620 of receiving edits to code associated with one or more virtual web pages. Examples of code may be the front-end and back-end code described above in relation to Figures 1 to 7. For example, the code is This may relate to the collection and storage of data and content in a database, the creation of dynamic pages, the implementation of user-facing widgets and apps, the repetition of data element layouts, and the configuration of a software-based router. In some embodiments, in step 2622, a skeleton code segment may be generated to facilitate user editing of the code associated with the web page. For example, the skeleton code may be a high-level abstraction of the functionality associated with finer-grained source code, which can implement the various types of front-end and back-end functionality described above on the web page. The skeleton code may be displayed to the user via an editing interface, which the user can then edit. User editing of the skeleton code can then be translated into editing of the finer-grained actual code associated with the individual web page. With regard to editing the page attributes and page data / field content described above, the system may support editing of web page templates 2704 (stored in the site area database 124 and subject to sandboxing of pre-publication development changes) or virtual page instances (which may be stored in the virtual page instance adaptive database). This will be described in more detail in the following descriptions of steps 2630 and 2634.

[0393] In Method 2600, step 2624 allows the user to select a specific virtual webpage, and step 2626 allows the user to navigate across the virtual webpages. For example, the user may select pages individually by clicking on hyperlinks or other links associated with images or visual representations of the pages, or they may visually navigate across the pages (e.g., left / right or up / down toggle buttons, or other visualizations of selections).

[0394] According to Method 2600, any edit to a virtual webpage (e.g., editing an instance by step 2616 or 2618) can be translated in step 2828 into an update to a database that maintains data elements for the webpage. For example, if a user replaces an image on a virtual webpage with another image (e.g., an image uploaded by the user), the new image can be stored in the database. Furthermore, if a user replaces text on a virtual webpage (e.g., a description of a particular hotel room), the updated text can also be stored in the database. In some embodiments, updates to the database can be performed automatically based on user edits to the virtual webpage. Since the database is used to build the virtual webpages and associated with the content of the virtual webpages, edits to virtual webpages can be traced back and associated with the database used to build them. In some embodiments, multiple versions of the database are stored at least temporarily so that a user can perform an undo or cancel operation if they want to invalidate changes made to a virtual webpage and revert to a previous version. For example, a user can choose the undo or cancel option, or they can be presented with a timestamp or version identifier associated with a previous version of the virtual webpage from which edits can be undone or resumed. Such version control systems may also support changes to versions of the development database that are not part of the published version until a publishing operation is performed. This is also known as "sandboxing" the development database.

[0395] Method 2600 may also include step 2630, in which edits made by the user to the skeleton code are received. Furthermore, in step 2634, edits to the actual code (e.g., via step 2620) or the skeleton code (e.g., via step 2630) may be converted into edits to the actual code of the web page. As described above, for example, a user can edit the actual code or skeleton code associated with various backend or frontend functions of a virtual web page. Such edits to the code can be stored in the same database that hosts the data elements of the virtual webpage, or in a separate code database.

[0396] Furthermore, in step 2632, method 2600 may include a step of enabling the display of the web page, along with updates made to the virtual web page during preview mode, including both the regular web page and the instance of the virtual web page, during live view of the actual web page associated with the virtual web page. As described above, for example, a user may be able to edit numerous features of the virtual web page (e.g., page structure, data elements, front-end code, back-end code, etc.) during preview mode for both the template and the instance. Such edits are translated into corresponding updates for changes to the page definition or data elements, which may be stored in the site area database 124 and / or separate databases (e.g., a data element database, an instance-fitting database, and / or a separate code database on which the virtual web page is based). Such separate databases may also be hosted by WBS 100, for example, as part of memory 820 or persistent storage 830. Furthermore, such edits may also be translated into corresponding updates to the actual live web page. In various embodiments, the virtual web page and the actual web page may be based on the same database(s) or different (e.g., linked) database(s). It should be noted that these databases (e.g., Site Area Database 124, and other databases such as Data Element Database, Instance Adaptive Database, or separate Frontend / Backend Code Databases) can be implemented as a single database, a set of databases, or a combination of databases (each potentially supporting a subset of the required functionality).

[0397] Figure 27 shows a system 2700 for developing and previewing web pages, according to some embodiments of the present disclosure. As described above, the system 2700 may operate within a system similar to the systems described in relation to Figures 1, 2, 15, etc. In some embodiments, the system 2700 may include a site area database 124 that stores data elements and / or code for one or more web pages 2704. As shown, a number of web pages 2704 may be maintained, each of which may have its own corresponding data elements. As described above, the data elements may be organized into data groups 210 of one or more data elements. As described above, such data groups 2710 may be system-wide, site group-specific, site-specific, or page-specific (typically for a given web page template 2704).

[0398] As shown in Figure 27, the site area database 124 can communicate with a web browser 131 or other client applications over the network, which can be operated by the user. The web browser 131 can use data elements in data group 210 to display virtual web pages 2712 corresponding to each web page template 2704 in the site area database 124. Furthermore, each virtual web page 2712 may be associated with a data element 211. In addition, the user may have individual displays of data elements (e.g., data element 1 211 and data element 2 2718) as part of a data element group 2714. As described above, the user can interact with the displayed virtual web page 2712, which includes its elements 2710, 2714, 211, and 2718, to edit various functions of the virtual web page 2712. Edits may include specific data elements, page structure functions, front-end code, back-end code, etc. As described above, such edits may be received by the site area database 124 and / or other databases.

[0399] Figure 28 is a block diagram 2800 of a virtual webpage according to some embodiments of the present disclosure. In line with the above examples, the virtual webpage 2712 may include various user-selectable functions 2802, including display functions 2804, search elements 2806, bookmarks 2810, scroll functions 2810, and other functions. The virtual webpage 2712 may further include data elements 2714 and front-end code 2812, as described above. Furthermore, the virtual webpage 2712 may be associated with back-end code (not shown), such as dynamic webpage code. As described above, a user can view, interact with, and edit the virtual webpage 2712. Such edits may be received by one or more components of a website construction system, such as a site area database 124. The display of the virtual webpage 2712 allows the user to visualize the edits they are making before the corresponding webpage goes live. To publish the virtual webpage 2712 in live mode, a user can select the "Publish" or "Render" link, as described above.

[0400] Figure 29 shows a timeline display 2900 of a dynamic refresh of a web page according to some embodiments of the present disclosure. In particular, when a user edits a virtual web page 2712, the edits can be refreshed in the site area database 124 and therefore in the user's browser. As shown in Figure 29, the data group 2710 may include data element 1 211 and data element 2 2718, among other data elements. A tab 1 2902 may be displayed within data element 1 211, and a test tab 2 2904 may be displayed within data element 2 2718. Tabs 1 2902 and test tab 2 2904 may be displayed on the virtual web page 2712 together with other elements (e.g., a search bar, a dropdown menu, etc.) as shown.

[0401] As time progresses in the timeline display 2900, the user can edit the virtual webpage 2712. For example, as shown in the figure, the user can edit test tab 2 2904 to create edited tab 2. Furthermore, a new data element 3 2906 can be added to the virtual webpage 2712 as part of data group 2710. When edits are made to the virtual webpage 2712, corresponding edits may be made in the live environment 2908. For example, if the user selects the "Publish" or "Render" function, the live environment 2908 may be updated to display updates to data group 2710 and other aspects of the virtual webpage 2712. For example, the initial version of the actual webpage 2910 may not include edited tab 2 or tab 3, but subsequent versions of the actual webpage 2912 may include these updates. In various embodiments, updates to the virtual webpage 2712 may be performed automatically or when the user selects the refresh or update function. Furthermore, updates to the actual web pages 2910 and 2912 in the live environment 2908 may occur when the user confirms the transition to the live environment 2908 (for example, by selecting the "Publish" or "Render" link).

[0402] Figure 30 shows a block diagram of a dynamic preview system 3000 according to some embodiments of the present disclosure. As shown in Figure 30, the dynamic preview system 3000 helps to display a web page when it appears in, for example, a deployment environment 1510. The preview interface 3010 may be a frame or other graphical interface within the online editor interface 243 that displays the web page. In some embodiments, the preview interface 3010 may be a separate tab opened on a web browser used to display the online editor interface 243.

[0403] Preview Interface 3010 is for static web pages and virtual web pages (sun It can be used to display both a virtual webpage and an instance of a given webpage template 2704. A navigation interface 242 may accompany the virtual webpage generated for viewing in the preview interface 3010. The preview interface 3010 may allow the navigation interface 242 to include scrollable functionality, enabling the user to scroll across multiple virtual webpages generated for viewing in the preview interface 3010. The navigation interface 242 may enable both sequential navigation and direct access to specific virtual webpages, as well as navigation between virtual pages by search (e.g., by using the value of a key data item used to identify a specific virtual page). The navigation interface 242 may support virtual webpages that can be directly accessed to specific virtual webpages and bookmarked for selective viewing. For example, a virtual webpage displayed in the preview interface 3010 may have links to the first, last, previous, or next virtual webpage. WBS100 may also support other configurations of virtual pages, not just a linear configuration. For example, WBS100 can support a hierarchical structure of virtual pages that can be navigated using additional options such as "move to a higher level in the tree" or "expand a level below the current page."

[0404] Figure 31 shows a preview of a virtual webpage 3110 being edited according to several embodiments of the present disclosure. As shown in Figure 31, the front end 126 is associated with a data group 210. The build tools 121 included in the front end 126 may be associated with specific data elements of the data group 210. The virtual webpage 3110 can display an indexable webpage 125 including the front end 126 and may be previewed in the preview interface 3010. In some embodiments, the preview interface 3010 may be a frame or other graphic representation within the online editor interface 243. The preview interface 3010 can preview the virtual webpage 3110 so that it can be displayed on various mobile and desktop devices that use different languages, are adapted to accessibility requirements, or are modified in any way for a specific audience.

[0405] Figure 32 is a schematic diagram illustrating the relationship between data groups and websites according to some embodiments of the present disclosure. As shown in Figure 32, a group of virtual web pages 3220 of a website may be associated with the same data group 210. In some embodiments, a group of virtual web pages 3220 may be associated with a set of data groups 3230. In some embodiments, a group of websites 3240 may share the same set of data groups 3230. A group of websites 3240 sharing a set of data groups 3230 may have the same owner or operator, or they may be granted appropriate permissions (via an access control mechanism) to access a particular data group 210. In some embodiments, a group of websites 3240 sharing a set of data groups 3230 may be built by the same developer / designer 1540, as described above.

[0406] As shown in Figure 32, the repeater 3213 is a construction tool displayed on the front end of a web page, displaying different content items or groups in different sections where the design or layout is repeated. In some embodiments, the repeater 3213 may be part of a virtual web page 3111 generated using a software-based router, as further described herein, or part of a regular (static) indexable web page 125. The repeater 3213 displays different content based on data element 1 211 and data element M 3212 of data group 210. The repeater can be directly associated with a subset 3213 of data group 210. For example, the repeater can be used to create five different groups of text and images. Each group can automatically arrange the text and images at the same ratio and layout. Nevertheless, in some embodiments, the actual content of the text and images may differ in each group.

[0407] Figure 33 is a schematic diagram showing the components involved in the generation of virtual web pages according to some embodiments of the present disclosure. As shown in Figure 33, the web page template 2704 can be associated with data group 210 and other data groups, as well as indexable web pages. As described above, data elements in data group 210 can be bound using the software-based router 3310 and applied to the web page template 2704 to generate virtual web pages 3111, 3313, and 3312. The software-based router 3310 can select / filter / sort data elements in data group 210 and apply them to the web page template 2704 and virtual web page groups based on URLs submitted by the user. The software-based router 3310 identifies the web page template 2704 based on the URL prefix. The software-based router 3310 may identify data elements in data group 210 to be applied to the web page template 2704 to generate virtual web pages based on URL elements (e.g., suffix components, text segments, or parameter values) following the URL prefix. In some embodiments, the URL prefix "prefix1" identifies the software-based router 3310 of the webpage template 2704. The software-based router 3310 can generate virtual webpages 3111 and 3312, respectively, based on the suffix values ​​"label1" and "label2". The software-based router 3310 can generate a sitemap prefix1 sitemap 3313 that lists all possible URLs of all virtual webpages that can be generated using the webpage template 2704, the associated data group 210, and other data groups. The prefix1 sitemap 3313 can help the search engine 170 index the virtual webpages 3111 and 3312.

[0408] Figure 34 is a flowchart 3400 illustrating the steps involved in generating and previewing a virtual web page according to several embodiments of the present disclosure. The flowchart 3400 represents steps that may be performed in the system embodiments described above.

[0409] As shown in Figure 34, in step 3410, the dynamic preview system 3000 can store data elements in the site area database 124. As described above, data elements can take various different forms, such as records consisting of text, images, videos, backgrounds, and combinations of any of these object types.

[0410] In step 3420, the dynamic preview system 3000 can store instructions that enable the organization of stored data elements into data groups. For example, a group may be defined in a database. Furthermore, a group may be defined by the relationships between elements within the group, or by fields of data elements whose values ​​depend on other fields. In accordance with the above embodiments, data groups may be defined before visual elements, fields, or a particular web page are defined.

[0411] In step 3430, the dynamic preview system 3000 adds additional data elements to a data group previously created in the site area database 124. Further instructions can be provided to the web browser displaying the online editor interface 243. In this way, existing groups can be supplemented or edited to include different or additional elements. The user can repeat step 3420 and return at any time to add more data elements. Similarly, this step may include instructions to perform additional operations on data elements, such as deletion or updating. For example, the user can cycle through steps 3410, 3420, and 3430, or proceed directly to step 3430.

[0412] In step 3440, the dynamic preview system 3000 may execute commands to help associate previously inserted data elements of data groups stored in the site area database 124 with the website being edited in the online editor interface 243. The user can repeat step 3420 and return at any time to create further associations between the web pages of the website being built and the data elements organized as data groups stored in the site area database 124.

[0413] In step 3450, the dynamic preview system 3000 provides instructions to help associate data element groups with web pages of a website. This may include linking form fields to each other and activating / deactivating and filtering the potential values ​​allowed in the fields, as described above (for example, a form for entering an address may have a "City" field value listed depending on the selection in the State field).

[0414] In step 3460, the dynamic preview system 3000 provides instructions to the online editor interface 3000 to enable a preview of the web pages of the website being built in the online editor interface 243. As described above, the preview may allow the user to edit in real time.

[0415] The user can repeat steps 3430, 3440, 3450, and 3460 any number of times in any order.

[0416] Figure 35 is a schematic diagram of a user interacting with a website hosting system 3500 according to some embodiments of the present disclosure. As shown in Figure 35, the website hosting system 3500 comprises a hosting server 3510 including one or more systems for building and displaying websites, a plugin server 3520 for executing plugin code, a processor 260, memory 820 for storing plugin components and code, and an interface 3570 for developing and uploading plugin code and other components.

[0417] The hosting server 3510 may be one or more servers hosting the co-hosted websites 3511, 3512, and 3513. The hosting server 3510 may be, for example, a web server execution instance in the on-demand system 800 or another type of website hosting system. In some embodiments, the hosting server 3510 may be multiple web server execution instances of the on-demand system 800. The hosting server 3510 may also be a WBS 100 that stores the websites edited and accessed by the developers / designers 1540 and end users 1530, as described above.

[0418] The editing tool 411 is a common tool for editing websites shared on the hosting server 3510, as described above. In some embodiments, the editing tool 411 is used on co-hosted websites 3511-35 13 may be shared across multiple hosting servers 3510 that host it.

[0419] The plugin server 3520 may be one or more servers that run the plugin code in the isolated environment 3521. In some embodiments, the plugin server 3520 uses the same infrastructure as the hosting server 3510 (which may be the physical server or web server execution instance described above). The plugin 3530 resides in memory 820 and can be displayed or accessed via the user interface 3531, the front-end plugin code 3532, and the back-end plugin code 3533.

[0420] Users 3540 to 3560 can access the editing tool 411 from the hosting server 3510 to edit websites 3511 to 3513, respectively. In some embodiments, for example, website 3511 being edited by user 3540 may include a plugin 3530. For example, website 3511 may allow video playback via the video player plugin 3530 when accessed using a web browser 131 on a web browsing device 130. User 3540 modifying website 3511 may include editing and uploading plugin code via interface 3570. In some embodiments, interface 3570 may be part of the editing tool 411.

[0421] Users 3540-3560 interact with websites 3511-13 on hosting server 3510 via a shared platform 3580. The shared platform 3580 allows a group of users to edit a group of websites. The shared platform 3580 may be software configured to determine which group of users 3540-3560 has access to edit which websites 3511-13. In some embodiments, the hosting server 3510 that hosts multiple websites 3511-13 may itself function as the shared platform 3580.

[0422] When an end user 1530 browses a website 3511 using a web browser 131 on a web browsing device 130, this may include the user interface 3531 of the plugin 3530. For example, if the plugin 3530 is a video player, the user interface 3531 may include playback control buttons styled to match the video player plugin 3530. The front-end plugin code 3532 may also be passed through the user interface 3531 when the end user 3540 accesses the website. When the end user 1530 interacts with the user interface 3531 of the plugin 3530, the front-end plugin code 3532 of the plugin 3530 may be executed in the web browser 131. In some embodiments, the end user 1530's interaction with the website 3511 may also cause the back-end plugin code 3533 to be executed on the plugin server 3520. For example, when an end user 3540 clicks the playback control of the video player plugin, the front-end plugin code 3532 is executed to make a video streaming request, and the back-end plugin code 3533 may compress the video based on the availability of network bandwidth.

[0423] Figure 36 illustrates a technique for controlled access to co-hosted websites according to several embodiments of the present disclosure. As shown in Figure 36, users 3540 and 3550 are grouped together and are granted access to co-hosted websites 3511 and 3512. Users 3621 and 3622 may have access to co-hosted websites 3611 and 3612. Users may access one or more co-hosted websites While a user may have access to a website, they may not be permitted to access websites that are not part of an authorized group. A user's access rights may be defined based on factors such as whether they are the owner of a particular website, a registered user, or authenticated.

[0424] Figure 37 illustrates a group of co-hosted websites sharing plugin code under a common root, according to some embodiments of the present disclosure. As shown in Figure 37, a web hosting system 3500 has two sets of co-hosted websites, each set distinct from the others by its URL root. For example, co-hosted website 3711 under common root 1 may share the domain www.a.com, and co-hosted website 3731 under common root 2 may share the domain www.b.com. Alternatively, co-hosted website 3711 under common root 1 may have a common subdomain a.wixsite.com, and co-hosted website 3731 under common root 2 may have a common subdomain b.wixsite.com. Websites with a common root can be co-hosted on a hosting server or hosting environment to create an isolated environment and eliminate interaction with other sets of co-hosted websites. Co-hosted websites may also have different plugin servers to create an isolated environment for executing plugin code. The co-hosted website 3711 on common route 1 and the co-hosted website 3731 on common route 2 may further share the same processor 260 and memory 820, or they may have different processors and memory. Figure 38 shows isolated execution environments for backend plugin code 3533 according to some embodiments of the present disclosure. As shown in Figure 38, the backend plugin code 3533 in the plugin 3530 isolated environment may be based on a container (e.g., Docker) 3810 or a virtual machine 3820 or an operating system process 3830. In some embodiments, the isolated environment 3521 may include one or more containers 3810, virtual machines 3820, and operating system processes 3830 (e.g., serverless code), each running separate plugin backend code 3533. In some embodiments, the plugin server hosting the plugin 3530 may include multiple isolated environments.

[0425] Figure 39 illustrates controlled access and execution of frontend plugin code 3532 according to several embodiments of the present disclosure. As shown in Figure 39, accessing website 3511 provides access to frontend plugin 1 code 3532 for plugin 3530 and frontend plugin 2 code 3931 for another plugin. Website 3511 can ensure that each of the plugins runs in its respective separate sub-areas 3910 and 3930. The website hosting system 3500 can also create a secure communication channel (e.g., SSL, secure tunnel) to allow access only to other specific sub-areas of the website. The secure communication channel can restrict frontend plugins' access to other sub-areas of the website. For example, frontend plugin 1 code 3532 running in sub-area 3910 may be able to communicate with another sub-area 3920 but may be denied access to sub-area 3940. The sub-areas accessible by a plugin may be listed in tabular form, a trusted registry, a configuration file, or a secure database. For example, in a cloud computing-based configuration, the cloud orchestrator platform can maintain a list or mapping of virtual computing resources (e.g., sub-region 3910, sub-region 3920, sub-region 3940, etc.) and define their connection permissions. Such a list or mapping may allow certain connections or actions by sub-region 3910, sub-region 3920, and sub-region 3940, and deny other connections or actions. In some embodiments, all communications pass through one or more hubs (e.g., hubs that perform authentication or authorization checks). This enables a secure communication channel. Such a hub can reside, for example, on a system client, a system server, or both. Secure communication can also be established by verifying the unique identifier of the sub-domain initiating the communication. For example, the getId() method call can be used to identify the source sub-domain ID of a communication message and determine whether it is included in an allow list or mapping.

[0426] Figure 40 illustrates the isolated client-side execution of plugin code according to some embodiments of the present disclosure. As shown in Figure 40, a website 3511 accessed by an end user 1530 using a web browser 131 may result in access to the front-end plugin code 3532 of plugin 3530. End user 1530 access may create an iframe for the front-end plugin code 3532 to run independently. In some embodiments, the front-end plugin code 3532 may be copied to different sub-regions 3712-3713 of website 3511 for independent execution. For example, website 3511 may display multiple video players, each streaming a different video stream but using the same plugin code. In some embodiments, the plugin code 3532-3533 running in the iframe may not have access to client-side cookies (e.g., HTTP cookies).

[0427] Figure 41 is a flowchart illustrating the steps involved in accessing and executing a website and plugin code according to some embodiments of the present disclosure. As shown in Figure 41, in step 4110, the website hosting system 3500 hosts a website that shares one or more common data elements, templates, parts of code, routes, or other functions within a common host server or set of servers. The server may also be co-hosted based on ownership or administrative and editing privileges of multiple users. For example, the website hosting system 3500 may host a website created and managed by multiple independent, unaffiliated entities or individuals.

[0428] In step 4120, the website hosting system 3500 provides access to the editing tool 411 to further edit the website co-hosted by the system. As described above, the editing tool 411 allows the user to edit various aspects of the website.

[0429] In step 4130, based on the user's attempt to access the website for editing purposes, the web hosting system 3500 evaluates whether the user making the request has access rights or privileges to edit the website. The evaluation may depend on the ownership of the particular website. In some embodiments, the website owner or administrator may use the editing tool 411 to grant administrator and / or editing access to other users. Furthermore, in some embodiments, editing rights may depend on whether the user is a registered user or authenticated to access the web hosting system 3500.

[0430] If the answer to step 4130 is "no," the requested access to the website is denied, and the user may need to request editing permission from the website administrator. Process 4100 is considered complete if access to edit the website was not obtained. Alternatively, process 4100 may cycle back to step 4120 or 4130.

[0431] If the answer to step 4130 is "yes," process 4110 proceeds to step 4150. In step 4150, an interface for uploading the plugin is presented to the user requesting access to edit the website. This interface may be similar to the interfaces described above for users to edit the front-end or back-end code.

[0432] In step 4160, the website hosting system 3500 receives and stores the changes to the plugin. User-uploaded plugins may include, for example, edits to the backend plugin code 3533 of plugin 3530. In some embodiments, user edits may include edits to the frontend plugin code 3532 of plugin 3530. Alternatively, the user may also edit the user interface 3531 of plugin 3530. In some embodiments, the user may edit all of the user interface 3531, the frontend plugin code 3532, and the backend plugin code 3533.

[0433] User-editable plugin code (e.g., frontend plugin code 3532 or backend plugin code 3533) can edit the plugin code across multiple sessions, allowing for the repetition of steps 4120-4160 and fewer or more steps.

[0434] In step 4170, the web hosting system 3500 executes the plugin 3530 when the website 3511 is accessed by a user (e.g., end users 1530, 3540, 3550, 3560). Executing the plugin code involves creating an isolated environment 3521 for executing the code. The isolated environment 3521 may include the separation of the web browser's client-side and server-side for executing the front-end 3532 and back-end 3533 plugin code 3530, respectively.

[0435] Figure 42 shows exemplary user interfaces for editing web pages and creating database collections according to some embodiments of the present disclosure. For example, web pages may be generated through a website development system such as that provided by Wix.com. As shown in the figure, a database can be created that supports one or more dynamic web pages.

[0436] The site structure sidebar 4202 may include various options for editing and structuring the website, such as lists of various pages (e.g., Home, University, Events, Scholarships, Student Area, Degree Courses, and News), as well as options for public, backend, and database functions. Furthermore, the toolbar 4204 may include various options for adding and editing content on web pages.

[0437] As shown in the diagram, interface 4206 allows the user to configure the database. Interface 4206 may be generated, for example, when the user selects the "Database" option from the site structure sidebar 4202. The user can customize the database by giving it a unique name in field 4208. In this example, the database might be called the "Course" database.

[0438] Figure 43 is an exemplary user interface for editing web pages and configuring permissions for a database collection, according to some embodiments of the present disclosure. For example, continuing the above example, a user creating a “course” database can configure various different permissions for the database and the corresponding dynamic pages that may be obtained based thereon. Permission 4310 is accessible. Permission 4310 may address web page content, data entry into forms, user-generated content on a page, content restricted to registered members, forms that can only be completed by registered members, and certain private data that can only be accessed by specific users (e.g., administrators).

[0439] Figure 44 shows exemplary user interfaces for editing entries in web pages and database collections according to some embodiments of the present disclosure. For example, the “Courses” database may consist of fields 4412 (Title), 4414 (Description), 4416 (Image), 4418 (Instructor), etc. These fields may contain information about a course that can be extracted from the database and included in a particular dynamic web page. In particular, the fields may include text content (e.g., fields 4412, 4414, and 4418) and other content such as images and videos (e.g., field 4316). As shown in the figure, field 4416 contains an image corresponding to a course titled TING. In some embodiments, the user may further define the type or layout of each dynamic web page and specify a URL for each dynamic page. For example, the URL suffix may correspond to a column in the database (e.g., Title).

[0440] Figure 45 is an exemplary user interface for editing a web page and displaying output from a database collection, according to some embodiments of the present disclosure. For example, the created dynamic web page may contain content from a database. As shown in the figure, content 4520 contains a course description from the database. Content 4520 is automatically extracted from the database without requiring the user to manually copy it to the web page. Using this technique, a large number of dynamic pages can be created, each linking to a different part of the database and having a unique configuration of content based on the links to the database.

[0441] Figure 46 is an exemplary user interface for editing a web page and creating a repeater function, according to some embodiments of the present disclosure. As described above, a repeater function can be added to a website or page to create two or more instances of elements that have similar structure or layout (e.g., a combination of text and images). Using repeaters, it is possible to create two or more instances of elements that differ in at least one respect (e.g., having different text, images, etc.).

[0442] As shown in the diagram, the user can access the Repeater menu 4622 to configure the Repeater. For example, using the toolbar 4204, the user can select the List & Grid option, which allows the creation of the Repeater and various other elements that display multiple objects. To populate the Repeater instances with content, the user can link the Repeater or individual instances to a dataset, such as data stored in a database. In some embodiments, the user may decide to add one element to each instance similarly. Adding an element to one instance will automatically add the element to each instance. Alternatively, the user may attempt to specify that each instance created by the Repeater has different content (for example, through backend or frontend code).

[0443] Figure 47 is an exemplary user interface for editing a web page and demonstrating the results of the repeater function according to some embodiments of the present disclosure. As shown in the figure, the user creates three combinations of elements 4724 via the repeater. Each combination 4247 has a similar structure: an image, text (place name), text (description), and a "Read More" hyperlink icon. In editing mode, the user can, for example, edit a text element The layout and appearance of these instances can be further edited by changing the position of images, modifying hyperlinks, or resizing fields. Furthermore, as mentioned above, each element of an instance can be connected to a different part of the database. For example, three combinations of element 4724 can each link to different columns in the database corresponding to the content that should be extracted from the database. In this way, the three combinations of element 4724 have a common layout, but each has different text or graphic content.

[0444] This specification describes various operations or functions that may be implemented or defined as software code or instructions. Such content may be in direct executable form ("object" or "executable" form), source code, or differential code ("delta" or "patch" code). Software implementations of embodiments described herein may be provided through a product storing the code or instructions, or through a method of operating a communication interface that transmits data via the communication interface. Machine or computer-readable storage media include any mechanism that causes a machine to perform the described functions or operations and stores information in a form accessible by a machine (e.g., computing device, electronic system, etc.), such as a recordable / non-recordable medium (e.g., read-only memory (ROM), random access memory (RAM), magnetic disk storage medium, optical storage medium, flash memory device, etc.). Communication interfaces include any mechanism that interfaces with any medium, such as wired, wireless, or optical, for communicating with another device, such as a memory bus interface, processor bus interface, internet connection, or disk controller. Communication interfaces may be configured by transmitting signals to prepare the communication interface to provide configuration parameters and / or data signals that describe the contents of the software. The communication interface can be accessed via one or more commands or signals sent to the communication interface.

[0445] This disclosure also relates to a system for performing the operations described herein. The system may be built specifically for the required purpose, or it may comprise a general-purpose computer that is selectively started or reconfigured by a computer program stored in the computer. Such computer programs may be stored in computer-readable storage media such as, but are not limited to, floppy disks, optical disks, CD-ROMs, and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of disk suitable for storing electronic instructions connected to a computer system bus, respectively.

[0446] Embodiments of the present disclosure may be implemented in computer executable instructions. Computer executable instructions may be organized into one or more computer executable components or modules. Embodiments of the present disclosure may be implemented in any number and organization of such components or modules. For example, embodiments of the present disclosure are not limited to specific computer executable instructions or specific components or modules illustrated and described herein. Other embodiments may include different computer executable instructions or components having more or fewer functions than those illustrated and described herein.

[0447] Computer programs based on the written descriptions and methods of this specification are within the scope of the software developer's skills. Various programs or program modules can be created using various programming techniques. For example, a program section or program module can be written in JavaScript, Scala, Python, Java, etc. It may be designed using C, C++, assembly language, or any such programming language, as well as data encoding languages ​​(such as XML, JSON), query languages ​​(such as SQL), presentation-related languages ​​(such as HTML, CSS), and data transformation languages ​​(such as XSL). One or more of such software sections or modules may be incorporated into a computer system, non-temporary computer-readable media, or existing communication software.

[0448] The words "comprising," "having," "containing," "including," and other similar forms are intended to be interpreted as semantically equivalent and non-restrictive, in that the one or more items following any one of these words do not mean an exclusive enumeration of such one or more items, or that the list is limited to only the one or more items enumerated. In addition, the singular forms "a," "an," and "the" are intended to include multiple referents unless otherwise indicated by the context.

[0449] While embodiments have been described in detail, it is clear that modifications and variations are possible without departing from the scope of the embodiments of the present invention as defined in the appended claims. Since various changes can be made to the above-described structures, products, and methods without departing from the scope of the embodiments of the present invention, all matters included in the above description and shown in the appended drawings are intended to be interpreted as illustrative rather than restrictive.

[0450] Technical background On-demand web server execution instances for website hosting and website building systems Table of Contents Website and Stateless Serving Architecture 1 System 2 of the present invention Use scenarios for conventional systems and the system of the present invention (3) Use of the present invention system in a WBS context 5 Six acronyms used

[0451] Website and Stateless Serving Architecture 1. When a user interacts with a website, they typically spend much of their time interacting with client-side pages, web applications, and FE code running on their client machine / browser, rather than directly with BE code or the web server. However, this client-side website / application still makes multiple HTTP (or other) server requests, which may include, for example: 1.1. The initial HTTP request made to load the page. This may trigger further HTTP requests to load additional page elements (such as included images and scripts). 1.2. HTTP requests during a session. For example, when selecting a value for a field, the page makes an HTTP request to retrieve a set of possible values ​​for a given field. 1.3. Data-related HTTP requests, such as submitting forms filled out by the user. 1.4. BE-related HTTP requests to activate BE functionality. This can be performed using the system providing the website or an external (third-party) web service. 2. In this context, "server" may refer to an actual physical server, It may also refer to other website server execution instances such as VMs or containers (also known as Docker). The HTTP requests described throughout this document may also refer to HTTPS requests or any other network requests. 3. Users expect the system (client + server + communication medium) to respond very quickly from the time a request is made until the first response is received. Response time is often measured as "server-side time from receiving the request until the first response byte is sent" (usually expected to be less than 100 milliseconds). Server-side time measurement is used to exclude variable network transfer times from consideration. 4. It may take a considerable amount of additional time to actually complete the response. For example, when loading a new page, users expect the page to start appearing in the browser immediately, but it may take a considerable amount of additional time for the page to load, and users may start interacting with the page even before it has fully loaded. 5. Server systems (typically consisting of multiple servers or server farms) may respond to these requests using stateless or stateful systems / protocols. While the HTTP protocol is inherently stateless, it should be noted that the use of stateful servers can be implemented using non-protocol techniques (such as URL rewriting or hidden form fields). 6. Stateful systems are typically used when a client interacts with a pre-assigned server. While such servers can provide a continuous session context, scaling up this configuration is extremely difficult because the server needs to be continuously associated with (one or more) users and can be idle or partially idle while waiting for the next HTTP request to arrive. 7. In a stateless system, each HTTP request, even one from a single page, can be handled by a different server (or server execution instance). The "jumps" between different servers for different HTTP requests go unnoticed by the user, and these different servers can transparently access the external resources (such as database servers) required for the response. 8. Stateless systems, or systems using stateless servers, offer many advantages. In particular, because incoming requests are directed to any (stateless) server within the system, the system is highly scalable and does not require special handling for broken connections. 9. Because the (multiple) stateless servers in the existing system must be completely interchangeable, they cannot be adapted to a specific website or related pages. Therefore, such a configuration is suitable for simple, static websites. This configuration will not work well if you are providing a complex website that requires site-specific BE code (including user-provided code in some cases), site-specific components, or site-specific plugins.

[0452] The system of the present invention 10. As described herein, the system of the present invention includes fast booting of a Docker container (or website server execution instance) which runs a web server instance configured for a particular site (including specific plugins and server-side user-provided code for the site), and which performs this execution without timeouts and fast enough to respond to HTTP requests within a total time frame acceptable to the user. 11. Typically, starting a new virtual machine takes several minutes. Starting a new Docker container still takes 2-3 seconds. Both of these times are unacceptable. 12. The system described herein may provide a pool of standby containers that contain all relevant site-specific code but no user / site-specific code. 13. This system may listen on live ports for requests to connect to a server for a specific website. In that case, the system may connect to it. Otherwise, a standby container from the pool mentioned above may be used to populate the pool with the requested site-specific content, or to be instructed to load such content. Once the site-specific content for a given site is loaded, the container joins the pool of containers associated with that site. 14. Note that such a stateless container instance can process a specific HTTP request (including, for example, data validation) without becoming the instance that processed the original page loading the HTTP request. 15. The submitted site-level content may or may not include actual site pages. Such site page information may include, for example, the following: 15.1. Actual browser-compatible page materials (e.g., a collection of HTML, CSS, and JS code). 15.2. Underlying site definition data (e.g., XML file or JSON representation) that is converted into browser-compatible material by client-side or server-side code (e.g., WBS viewer module). 15.3. Frontend / backend code, e.g., JavaScript code called by a page to run on the client, server, or both. 16. If a site is inactive for a given period (e.g., 15 minutes), this system may drop the standby container. 17. To maintain the user's state and give the user the feeling that they are working within a single session (with a continuous context), a persistent context is maintained using a combination of client-side storage (e.g., browser local storage, cookies, etc.) and server-side storage (e.g., storage in a server database).

[0453] Use scenarios of conventional systems and the system of the present invention 18. Assume the following typical youth scenario. 18.1. The user enters a URL page into their browser and requests the page to load. The loaded page contains a data entry form and has a significant amount of relevant (site-level specific) FE and BE code. An HTTP request is made to the server to retrieve the page and its site-level associated FE code, while the BE code is loaded on the server but not sent to the client. The site also uses several components (such as display widgets) that have their own UI, FE code, and BE code. 18.2. The user fills out the form over a period of 10 minutes, and typically, <form>Work locally in a browser that runs a local page containing HTML tags. This can also be done using JavaScript or HTML setup that can initiate Ajax or Fetch calls, or HTTP requests. 18.3. The form may make several requests during this time that are sent to the server (e.g., to retrieve a list of allowed values ​​from the DB for a given field). Each of these requests activates a server-side BE script that performs the actual DB access and information retrieval (e.g., to avoid sending DB access credentials in the code to the client). Such requests may be implemented as HTTP requests or using different mechanisms. 18.4. When a user submits a form, the form is verified by the FE script. The form is then sent to the server, activating a server process that executes the associated BE code, which may (for example) save the form to the database. 19. In the above scenario, user activity is an HTTP request or other mechanism Using Nism, it's possible to generate (for example) 20 requests in a 10-minute period. Many of these requests activate site-specific BE scripts or component-specific BE scripts (for components used on the site). 20. Conventional stateless / stateful technologies handle this scenario as follows: 20.1. When using a stateful server, the server that initially provided the page containing the form must continue running until the completed form is submitted, which may take up to 10 minutes, even if it is doing nothing except processing intermediate requests (such as "Get a list of values ​​for field X" above). 20.2. Traditional stateless server technologies could not cold-start a server, or even a VM or container, in a timely manner for each specific HTTP request (which would contain site-specific code). Therefore, they had to either support sites that lacked specific BE functionality or keep a specific server instance running throughout the entire form entry session (and thus were not truly stateless). 21. Using the technology of the present invention, a stateless server instance (e.g., a container) is allocated to handle each of a particular HTTP request (loading a page, retrieving a list of values ​​for field X, saving the completed form to the DB). This results in server time usage being (e.g.) 20 request processing times (e.g., 20 x 200 milliseconds = 4 seconds) instead of the entire duration of a 10-minute form entry session. The allocated server may be a new container (with site-specific elements populated) or an existing, available site-adapted container. 22. Thus, in the same use scenario, the system of the present invention can use significantly fewer server resources than conventional systems, requiring the server only for 4 seconds instead of 10 minutes (although the server instance is idle for most of the 10 minutes, it is still waiting for a request from a specific user). 23. This allows website hosting providers to offer the same level of service using very few resources (servers, containers, etc.). 24. Incidentally, because the user is working locally on the form, when the user closes and reopens the browser window, an empty form (rather than a partially filled-out form) is usually displayed. The system of the present invention may provide an API that can retain the form's content in the browser's local storage. Therefore, when the user closes and reopens a partially filled-out form window, the reopened form will contain the previously entered values. This also works even if the browser is completely closed. 25. Similarly, BE tasks can still provide context information to each other, for example, by storing context information in a server-side database, or by providing information maintained by the client and passed to subsequent BE calls. Such information may persist as needed, even if only for the duration of the session (for example, using the browser's local storage). 26. It should also be noted that the ingestion of specific component code and associated FE / BE scripts is typically done site-wide (i.e., all special components and scripts used on all pages within the site), rather than at a specific page-level granularity. Thus, each time a new HTTP request arrives for this site (from the same user or another user), the ingested container may be reused on any page within the site. 27. However, this system can implement different levels of granularity depending on the amount of "material" being input and on the other hand on its usage pattern. Thus, this system can implement input granularity levels of (for example) pages, page groups (i.e., site sections), sites, or site groups. For example, the site group case may be relevant when many sites are very similar and use common related components and scripts. In this way, content specific to site groups is input. By reusing the container, requests can be processed not only for a single site, but for any site within the group.

[0454] Use of the present invention system in a WBS context 28. The online WBS is characterized by having two usage modes. 28.1. Editing the Site - The site definition (e.g., XML / JSON data, or DB records, or actual HTML page material) is typically edited by a visual editor application that runs in a browser with server support. Such a site may include FE code and BE code (which may also be editable in the editor), as well as specific components required by the site (e.g., third-party applications). The editor can also call up the site in preview mode. The editor may also support a publish operation to publish a version of the site for use by external users. 28.2. RT (Runtime) Mode - The system provides the user with a publicly accessible site while activating FE or BE code as needed. 29. The system of the present invention described above can be used in both the system's editing mode and RT mode. 30. When operating in edit mode. 30.1. The edited site context includes the following: 30.1.1. The complete site definition (pages, components, and associated data) is typically maintained by the editor client as a client-side in-memory structure (e.g., as a JSON representation). 30.1.2. Site FE code. 30.1.3. The BE code for the site. 30.2. The actual editor code (Editor FE code loaded on the client and Editor BE code executed on the server) is part of the system's general code (in the "General Sections" preloaded into the container). 30.3. The site's JSON / FE site code / BE site code is stored in the database (if explicitly saved by the user). 30.4. Because temporary storage of FE / BE code is limited, users can continue editing the same code via the "moved" container. This is necessary because the site's FE / BE code is not part of the site's JSON code. 31. Note that while site code is stored in the DB, it can be used when running a preview, and the editor does not have to load the entire site code (which may be large), but only the relevant sections related to the page being edited or the current page are stored. 32. When operating in runtime mode, the system operates as described above for providing a normal website. WBS may have a viewer module (required for all sites edited with WBS), and such a module is part of the general system code preloaded onto the launched server / container instance. 33. Therefore, the system of the present invention can be used by WBS for both editing and RT.

[0455] Acronyms used BE:backend FE: Frontend VM: Virtual Machine WBS: Website Construction System

[0456] Home > Wix Code > Wix Code Basics Use the site structure sidebar Visit the Wix Code Resource Center to learn more. The Site Structure sidebar displays all the files that make up your site, including pages, lightboxes, files, and database collections. Using this sidebar, you can perform various actions that affect your site, as detailed below. [Table 1] To hide the sidebar, click the hide icon in the lower left corner of the editor. To display the sidebar, click the display icon in the lower left corner of the editor.

[0457] page The Pages section in the sidebar lists all of your site's regular pages, dynamic pages, and router pages. Regular pages appear directly below the Pages section title. Dynamic pages and router pages appear in subgroups.

[0458] Regular page The site's regular pages are displayed directly below the page section title. To change the page settings, click the settings icon that appears when you hover your cursor over the page name. You can set any page other than the site's homepage as a dynamic page.

[0459] Dynamic Pages To add a new dynamic page to a group, hover your cursor over the section name and the table will appear. Click the settings icon that appears. To change page settings such as URLs and SEO data, click the settings icon that appears when you hover over the dynamic page name, and either remove the dynamic connection to convert the dynamic page back to a regular page, or delete the dynamic page.

[0460] Router page If you have created a router, all pages associated with that router's prefix will be grouped together in the same section. For example, if you have created a router with the prefix "myrouter", the section name will be "Myrouter Pages(Router)". Each router page is given a default name used in the router's code. You can change the name if needed. The page name is not visible to page visitors. To rename the router prefix and related functions implemented in the routers.js file, or to add a new page to the router, click the settings icon that appears when you hover over the router section name. To change the settings of a page, rename it, delete it, or remove it from the router and return it to a regular page, click the settings icon that appears when you hover your cursor over the router page name. To add a new router, click the plus icon that appears when you hover your cursor over the page section header.

[0461] Lightbox If you have added lightboxes to your site's pages, they will appear in the Lightboxes section of the sidebar. This section will only appear if you have added at least one lightbox to your site. To add a new lightbox, use the Add menu in the editor. Selecting an existing lightbox in the sidebar will put the editor into lightbox mode. The Public section in the sidebar contains files that are publicly accessible from your site. You can create JavaScript and text files for public use and organize these files into folders. Page and site code are also publicly accessible, but they are not displayed in the Public section. Use the code panel to edit page and site code. To add a new file or folder to a public section, click the plus icon that appears when you hover over the section name. To add new files or folders, or to delete folders, click the settings icon that appears when you hover your cursor over the folder name. To rename or delete a file, click the settings icon that appears when you hover your cursor over the file name.

[0462] backend The backend section in the sidebar lists files that are not publicly accessible from your site. The backend section is where you place the code that runs on the server side. You can create JavaScript files, web modules, and text files for use in the backend, and organize these files into folders. The backend section of a site may contain two special JavaScript files: the data.js file contains code for data hooks, and the routers.js file contains router and data binding router hooks. This includes code for the . To add a new file or folder to a backend section, click the plus icon that appears when you hover over the section name. To add new files or folders, or to delete folders, click the settings icon that appears when you hover your cursor over the folder name. To rename or delete a file, click the settings icon that appears when you hover your cursor over the file name.

[0463] database To add a new collection, click the plus icon that appears when you hover your cursor over the section name. To add new dynamic pages based on a collection, update collection permissions, or remove a collection, click the settings icon that appears when you hover over the collection name.

[0464] Related content About dynamic pages About lightboxes About database collections About routers About data binding router hooks

[0465] Home > Wix Code > Wix Code Basics Use the code panel • Visit the Wix Code Resource Center to learn more. Click here to view this article in full screen. You edit your site's code in the code panel that appears at the bottom of the editor. The code panel has a special toolbar and two tabs containing code for various elements of your site. You can also add any other code you want to either tab, depending on how and where you'll be using it. Hint: You can open the code panel by simply dragging it upwards from the bottom of the page. Elements within the editor can appear on a specific page or on all pages of a site. You can add code that is relevant only to a specific page, or code that is relevant to all pages on the site. On the left side of the code panel, there are two tabs: Pages and Site. • Pages: The Pages tab contains code for elements that appear on a specific page. When you add events to elements using the Properties panel, the code for those events is automatically placed in the Pages tab. If you have code that is only relevant to a specific page, add it here. • Site: To add code to an element that appears on all site pages and has consistent functionality across the entire site, add that code to the Site tab. When you add an event to an element that appears on all pages using the Properties panel, the code for that event is automatically placed in the Site tab. If you have code that is relevant to all pages of your site, add it here. If you have an element that appears on every page, and you want to add code specific to that element for a particular page, add the code to the page tab of that page.

[0466] Wix code syntax and autocomplete Select a specific element Wix Code allows you to code using standard JavaScript. Additionally, Wix Code has a specific set of syntax or rules for selecting elements on a page, which are as follows:

number

number

[0467] Select multiple elements To select multiple elements by name, refer to the elements using the same syntax as above, as follows: Separate each element with a comma.

number

[0468] Select all elements of a specific type To select all elements of a specific type, use the element type name without hashtags, like this: The element type name is the element name displayed in the Wix Code API.

[0469] JavaScript template In addition to autocomplete directly related to Wix code, the code panel also includes autocomplete for standard JavaScript templates and keywords. For example, if you type the word "for," the autocomplete list will include the "for statement" template and the keyword "for." Each template includes a link to the standard JavaScript API where you can find more detailed information.

number

number

[0470] Make sure the element is loaded before referencing it. >Advanced information about onReady When a page loads in the browser, the page's code may execute before the page has finished loading. In that case, an error may occur if the code attempts to reference elements within the page before the page has loaded.

number

[0471] Use elements Every element in the editor has properties, methods, and event handlers that you can use to interact with the element and add functionality to your site. If you select an element and then type a period, a complete list of all those items will be displayed.

number

number

[0472] property Properties contain information about an element. Some of these are read-only, but others allow you to set values. For example, a text element has an `isVisible` property, which returns whether the element is actually visible on the screen. This property is read-only. A text element also has a `text` property, which contains the current text of the text element. This property is both readable and settable.

[0473] Method The method performs an action on the element. For example, the button element has a `hide` method that prevents the button from being displayed on the site. Some methods have additional options that affect how the action occurs. For example, you can add animation to the hide method by specifying it in parentheses like this:

number

[0474] Event handler Event handlers allow elements to respond to user actions (events). When adding an event handler to an element, you also need to specify what to do when the event occurs. For example, let's say you have a button that says "Join Tour." You want to add a feature that changes the text to "Let's go" when a visitor hovers over the button. In that case, you would add the following code to your site (comments explaining each part of the code have been added):

number

[0475] Warnings and errors When you're writing code in the code panel, you may see warnings and errors. Warnings are displayed in yellow, and errors in red. These appear as a colored wavy line under the relevant code and an icon to the left of the line number. To view a warning or error message, hover your cursor over the icon.

[0476] caveat Warnings in code are informative messages that draw your attention to code that might need changing. Warnings do not stop the execution of your code and can often be safely ignored. Warnings are indicated by a yellow triangle and an underline with a yellow wavy line.

number

number

number

[0477] error Errors in your code mean that the code won't function properly. Depending on the type of error, the code might not work as expected or might not execute at all. Make sure to fix all errors in your code before publishing your site for site visitors to use.

number

number

number

[0478] Media Manager Integration In Wix code, you can use images saved in the Wix Media Manager. When using an element that includes an image property such as `src`, a popup window will open.

number

[0479] Test the code The code will run on a public site, but we recommend testing the code before publishing to ensure it works as expected. To test your code before publishing, preview your site. The code on your site will run exactly the same way in preview mode as it will in the published version. You can also debug your code on the published site.

[0480] Code version recording When you save, the corresponding code is saved along with that version of the site. If you go to the site history and revert to a saved version of the site, the code saved in that version will also be restored.

[0481] Related content Using JavaScript with Wixcode Test and debug your code using Wix Code.

[0482] Home > Wix Code > Database Collections About database collections Visit the Wix Code Resource Center to learn more. The site's database consists of several collections. Each collection can be thought of as a table of data, similar to a spreadsheet. Each row in the table represents an item within the collection. Each column in the table represents a field. Therefore, each item contains fields defined by the columns of the collection. For example, the following collection includes four fields and five items. [Table 2]

[0483] Create a new collection 1. In the Site Structure sidebar, hover your cursor over the database section name and click the plus icon. 2. Name the collection. Please note that you cannot change the name later. 3. By default, the "Site Content" collection permission preset is selected. This allows anyone to view the content, but only the creator can add, modify, and delete it. You can click the dropdown to select a different preset or define custom permissions. Permissions can be updated later. 4. Once finished, click [Create Collection].

[0484] Edit collection Within each collection in the database, there are both a sandboxed version and a live version of the data. Edit the sandbox version in the editor's content manager, and edit the live version in the dashboard. Clicking the "Edit Live Data" link at the top of the screen will take you to the dashboard's content manager.

[0485] Normal Field Each field in the collection has a field name, a field key, and a field type. [Table 3]

[0486] field name The field name is the label that appears at the top of the column in the Content Manager. The field name is also used when connecting page elements to a dataset in the editor. For example, when connecting a text element to a field from a collection, you use the field name from the Text Connections panel. [Table 4] When you add a new field in the Content Manager, you specify a field name. If you change the field name after it has been created, all connections to that field will be updated.

[0487] Field Key Field keys are used when referencing fields in your code using the Data API or Dataset API. For example, to insert an item using the Data API, you would use a field key. When you add a new field in the Content Manager, a field key is automatically created based on the field name. You can specify your own field key if needed. important: You cannot change the field key after the field has been created.

[0488] Field Type The field type defines the type of data contained in the field. When you add a new field in Content Manager, select one of the following field types. Read here for information on field type support and limitations. ·reference ·text ·image ·Boolean Numerical values • Date and time • Rich text URL ·document Field types are also used when connecting page elements to fields in a collection. Certain input elements can only be connected to fields of their corresponding field type. For example, a text element can be connected to a text or URL field, but not to an image field. The Content Manager does not allow you to add new values ​​to the wrong field type, but it does not validate data imported from a CSV file or added via code. For example, you can import text values ​​into a numeric field. In this case, the Content Manager will display an error. Use the lookup field type to select an item from the primary field of the lookup collection. For more information, see "To create a lookup field." Note:

[0489] Primary field Every database collection has a primary field, which is indicated in the Content Manager by a lock icon next to the field name. By default, the title field is the primary field, but any other text field in the collection can be set as the primary field, except for the ID system field. When you enter information into a reference field, you select the value from the primary field of the referenced collection. If you change the primary field of the referenced collection, the value displayed in the reference field will change to match the value of the new primary field. It is recommended that each item have a unique value in its primary field. For more details, see "About Reference Fields".

[0490] System Fields All database collections include the following default fields, which cannot be edited and are hidden by default. [Table 5] The ID field value can be assigned when adding items using the Data API or when importing new data from a CSV file. It cannot be changed later. In all other cases, the values ​​for these fields are automatically generated and cannot be modified.

[0491] Calculated fields When you create a dynamic page, a new field is added to the collection from which the dynamic page pulls data. This field contains a calculated URL that includes the dynamic page's prefix and the value of a field that determines the data bound to the page. For example, suppose you have a dynamic item page that displays items from a dish collection based on a title field. The collection has a field called Dish(Title) which has URLs such as / Dishes / pizza and / Dishes / checken. When a visitor goes to a dynamic page, all items in the collection with a URL that matches the page's URL are bound to the page's dataset. For dynamic item pages, each item has a unique URL. In this case, multiple items share the same URL. You cannot edit the content of a calculated field. However, if you change the URL of a dynamic page, the URL in the collection will also change accordingly. If you create multiple dynamic pages based on a collection, the collection will have one calculated field for each dynamic page. For more information, see "About Calculated Fields". A permission model allows you to manage which visitors are allowed to manipulate data within a collection and what actions they are allowed to perform. Permissions are set per collection. You assign permissions that determine which user roles can perform which actions. For example, you can grant site members create permissions for the comments collection, but prevent them from creating items in other collections. For more information, see "About Database Collection Permissions".

[0492] Importing and exporting data You can export data from a collection to a CSV file and import data from a CSV file back into the collection. Please refer to the article below. • About Sandbox and Live Data

[0493] Related content Make the database structure usable. Change field type About reference fields Regarding collection permissions To import collection data into the Content Manager About sandbox data and live data Remove a field from a collection About the calculated fields About dynamic pages To export collection data in Content Manager

[0494] Home > Wix Code > Advanced About routers Visit the Wix Code Resource Center to learn more. By using Wix code, you can create a router that gives you complete control over how incoming requests to your site are handled. To do this, you configure the router to receive all incoming requests with a specified prefix and define the logic to execute when a request with that prefix is ​​received. You decide what action to take, what response to return, where to route the request, and what data to pass to the page. You can use a router to do the following: • Display dynamic pages using content from any data source. • Customize URLs to make them more meaningful and improve SEO results. • Authenticate users and display user-specific content. • Returns a custom HTTP response code. Please refer to this link for router API references.

[0495] URL prefix When creating a router, the router determines which requests to process based on the specified URL prefix. You choose how to process the request. All incoming requests with that URL prefix will be sent to the router for processing. The URL prefix is ​​also used as the router name. The prefix is ​​part of the URL shown in bold in the following example. • Premium site: https: / / domain.com / prefix / category / item • Free site: https: / / user.wixsite.com / yoursite / prefix / category / item The routing logic is defined in the routers.js file. This file is located in the backend section of the site structure sidebar. It has two main functions, which are entry points to the router. These are named according to the following rules: ·<router prefix> _router(request) ·<router prefix> _sitemap(sitemapRequest)

[0496] router() The router() function sends a page request with a defined prefix. The router receives a WixRouterRequest object containing information about the incoming request. The function then determines how to process the request and returns the appropriate WixRouterResponse. Typically, the router() function determines which page to display (if any) and what data to pass to the page. The response is then sent using the forbidden(), notFound(), ok(), redirect(), or sendStatus() function.

[0497] sitemap() The sitemap() function handles sitemap requests. Use this function to ensure that search engines can find links to your pages on your router. Each WixSitemapEntry contains information about the page, such as its URL, title, and name. The sitemap() function is also used to populate the item preview widget, allowing you to switch URLs in preview mode.

[0498] Router data The `router()` function allows you to choose to send data to the page you are routing to. To access that data in your frontend page code, use the `getRouterData()` function from the `wix-window` module.

[0499] Related content Create a router

[0500] Home > Wix Code > Advanced Create a router By creating a router, you gain complete control over how incoming requests to your site are handled. This article explains the code you need to write to make a router work. For more information on what a router is and why you should create one, see "About Routers".

[0501] Add a router To add a router: 1. Click the plus icon that appears when you hover your cursor over the page section header in the site structure sidebar, and select "Add Router". 2. Enter the router's URL prefix and click [Add and Edit Code]. All incoming requests with the specified URL prefix will be sent to the router for processing. If you want to add a router: The router() and sitemap() functions for the router are added to the routers.js file, along with sample code for a simple routing scenario. The routers.js file is located in the backend section of the site structure sidebar. • A new section will also be created at the bottom of the page for the router. The section will be named using the prefix you selected earlier and will contain one page to get you started. For example, if you named your router "myRouter", a section called MyRouter Pages(Router) will be added with a page named myRouter-page.

[0502] Sample Scenario The sample code added to the routers.js file has four parts. 3. router() function 4. sitemap() function

[0503] import statement The functionality used to create routers is included in the Router API. To use this functionality, you need to import it. By default, the ok() and notFound() functions, and the WixRouterSitemapEntry object are imported.

number

[0504] Sample data In the sample scenario, the router uses static data contained in an object named peopleData.

number

[0505] Router function Note that all incoming requests with the URL prefix specified when the router was created are sent to the router for processing. The router() function handles these requests. The router() function is named according to the following rules:

number

number

number

number

number

number

number

number

number

number

[0506] Router data To use the data returned by WixRouterResponse using the ok() function, use the wix-window getRouterData() function. For example, you can retrieve data passed by the sample router code and use it to display personal information on the created myRouter-page page. First, you need to add text and image elements that will serve as placeholders for the individual's title and image.

number

[0507] Sitemap Function Similar to the router() function, the sitemap() function is named according to the following rules:

number

number

number

[0508] Related content About routers

[0509] Home > Wix Code > Advanced SEO and routing SEO settings for router pages differ slightly from those for regular pages. For more information on Wix page SEO, please see here. Just like with regular pages, you can define the page title, description, and social network images for router pages. The difference is that router pages do not contain static data and need to dynamically set SEO information, so they reflect the actual content they hold when displayed. Setting up SEO for your router page involves two parts. • Create meta tags so Google can learn about the page. • Create a sitemap for Google to use to find pages.

[0510] Meta tags When creating the router's router() function, you set the SEO meta tag on the router's page. Within that function, you create a HeadOptions object and pass it to the routing destination page using the ok() function. For example, in the sample code provided when adding a router, the following code uses the data obtained by the router to construct a HeadOptions object and passes it to a page named myRouter-page.

number

[0511] Sitemap A site's sitemap is what Google uses to find all the pages on your site. Pages on your site that don't belong to your router are added to your site's sitemap. However, to have complete control over which pages are available to your router, including all dynamically different versions, you should create a sitemap that includes all possible URLs that connect to your router's prefix so that Google can find them. To add router pages to your site's sitemap, you create a sitemap() function for the router. Within that function, you create a WixRouterSitemapEntry object for each URL the router can route. Each WixRouterSitemapEntry contains information about the page, such as its URL, title, and name. You can also add additional information about each page, such as how often the content changes, the last modified date, and its relative priority within the site. Google uses sitemap entries to discover all the pages on your site. For example, in the sample code provided when adding a router, the following code: The data obtained by the router is used to construct a HeadOptions object, which is then passed to a page named myRouter-page.

number

[0512] Home > Wix Code > Advanced Accessing third-party services You can use Wix code to create code that accesses third-party web services. You can call third-party services directly from client-side code. However, if you have security concerns such as exposing API keys, you can call the service from a backend web module. Note: If the site is an HTTPS site, you cannot request HTTP content from the service. An invalid request will cause an error. This can be verified using your browser's developer tools. To fix the request, either retrieve the requested resource from the HTTPS site using the HTTPS protocol, or turn off SSL on the site and retrieve the HTTP resource. >Advanced: Modules available for calling services

[0513] Calling client-side services For example, consider a case where you call a third-party service to look up exchange rates. In this example, we created a simple form with the following elements: [Table 6] Once you've set up the form, you can configure the button's properties so that the onClick handler calls the following function:

number

[0514] Call the backend service Service calls from the backend are done in two parts. First, you write the code to make the service calls in the backend web module. This avoids security concerns such as exposing API keys. For example, consider calling a third-party weather service to find the current weather for a city selected by the user. First, we create a function in the backend web module that calls the weather service and retrieves data.

number

number

[0515] Related content A web module calls server-side code from the frontend.

[0516] ←All topics Dynamic Pages article > About dynamic pages When are dynamic pages necessary? To select a dynamic page type To add a dynamic item page: To add a dynamic category page: > Use dynamic page dataset settings Preview dynamic pages Link to a dynamic page >Delete dynamic pages To convert between dynamic pages and regular pages >Create a dynamic page URL >About dynamic pages and the items they display Make multiple dynamic page URLs unique >Regarding URL prefixes and page grouping of dynamic pages > SEO settings for dynamic pages >Page information settings for dynamic pages > Use page settings for dynamic pages in mobile view > About the calculated fields

[0517] Home > Wix Code > Dynamic Pages About dynamic pages Visit the Wix Code Resource Center to learn more. When creating dynamic pages, you design a single page layout that can be reused and displays a different item from the database collection each time. Dynamic pages differ from regular pages because they display a different item each time they are displayed. Content is stored within the page itself, but content for dynamic pages is stored in a database collection. Dynamic pages are useful in the following situations: If you're duplicating pages and manually changing the content or design of each page, dynamic pages allow you to create a single page that displays items one at a time, or multiple items in groups. • When editing site content without making any changes in the editor or without changing the site's design. There are two types of dynamic pages. • Dynamic item page: A page designed to display a single item within a collection. • Dynamic category pages: Pages designed to display multiple items from all collections that match the same criteria. These items can be displayed in a repeater, gallery, or table.

[0518] example Let's say you're creating a recipe website. When you create a new database collection, a title field is automatically added to the collection. You'll use this field to store the name of the recipe. You'll add a meal field to the collection, indicating whether the recipe is for breakfast, lunch, or dinner. You'll also add a course field, indicating whether the recipe is an appetizer, main course, or dessert. Next, we'll design the site so that each recipe can be displayed on its own page. In this example, the page displaying individual recipes is a dynamic item page, and the page displaying all recipes based on a meal is a dynamic category page. Let's take a look at some of the collection's content to see how it works. [Table 8] Now let's see how this content will appear on the dynamic item page. Note: This example demonstrates what you can do with the capabilities of dynamic pages. For information on how to configure them, see "Adding Dynamic Item Pages" and "Adding Dynamic Category Pages."

[0519] Dynamic Item Page To display each item from the collection, we create a dynamic item page. This would look like this: [Table 9] Note that in this layout, the only elements that actually contain content are the headings "Recipe," "Meal," and "Course." The content displayed next to these headings (the parts with "<>" in the text) has not yet been placed on the page. For example, "<Recipe Title>" is merely placeholder text for a text box where the actual recipe name will be displayed. Also, the images in between are simply placeholder images (not images from the collection). The actual content that these elements display will be retrieved from the collection. Now, let's preview this dynamic item page for the cupcake recipe. [Table 10] How each placeholder was replaced with specific information from a cupcake recipe, and how the images displayed cupcake images from the collection. Please pay attention to this. On the same page, you can preview the Eggs Benedict recipe and see how the placeholder content has changed. [Table 11] Now let's see how this content will appear on the dynamic category page.

[0520] Dynamic category page You can create dynamic category pages that display different groups of recipes based on selected criteria. Let's consider creating a page that displays recipes based on the meals provided. We can use a table to display those recipes. [Table 12] Similar to item pages, this dynamic category page doesn't have any actual content. Let's take a look at what it looks like when you preview a lunch recipe. [Table 13] [Table 14]

[0521] Link to a dynamic page Because dynamic pages display their content dynamically, you cannot link to them in the same way you would link to a regular page. For more information, see "Linking to Dynamic Pages." Hint: Please refer to the article below. • Create dynamic page URLs • About dynamic pages and the items they display • Make dynamic page URLs unique

[0522] Related content Create a dynamic page URL Make multiple dynamic page URLs unique. About database collections About dynamic pages and the items they display Link to a dynamic page

[0523] Home > Wix Code > Advanced About data hooks Data hooks execute code before or after specific interactions with a site's collections. Using data hooks, you can intercept interactions immediately before or after they occur. Hook code can also be used to influence the interactions themselves. For example, you might intercept an item before adding it to a collection to perform final validation or fine-tune the data you actually put into the collection. Generally, hooks are executed regardless of whether the interaction with the collection is initiated by a page element or programmatically using the Data API. However, Data API calls from your site's backend code will pass an optional WixDataOptions object, which you can use to ensure that no hook is invoked for that particular interaction.

[0524] Hook type There are several different points in the data exchange lifecycle that can be hooked. Different hooks accept different arguments and return different values. For more information, see the Data API Reference. • item: The current item. For example, in beforeInsert, this is the item that is about to be inserted. If there are many items, for example, as might happen in afterQuery, the hook function will be called repeatedly, once for each item. • itemId: The ID value of the current item. • query: The WixDataQuery object to be executed. • count: The number of items in the count. • error: Error object. [Table 15]

[0525] Related content To use data hooks Use the Data API

[0526] Home > Wix Code > Advanced About data binding router hooks When a request arrives for one of the dynamic pages, the router uses the request's URL to determine which page to display and which data to bind to the page's dataset. You can add data binding router hooks to intercept this process at specific points and inject additional logic. Some hooks can also be used on router pages.

[0527] hook Data binding router hooks are defined in the routers.js file. This file can be found in the backend section of the site structure sidebar. Hook functions are named according to the following rules:

number

number

[0528] beforeRouter() This hook is triggered before the router navigates to the requested page. You can use this hook to route the request to a different page or return an error response. For example, you can check who is requesting the page and, based on the user's role, decide whether to have the router proceed to the next step or return an error type response code.

[0529] customizeQuery() This hook is triggered before the page's data query is executed. You can use this hook to further refine or modify the query that determines which data is bound to the page's dataset. For example, you can filter the query to return only items whose status field is set to active.

[0530] afterRouter() This hook is triggered after the router has bound the data but before the page is displayed. You can use this hook to modify the router's response based on the retrieved data. For example, you might have two versions of a page: one for portrait images and one for landscape images. After pulling images from the database, you can display the page corresponding to the image orientation.

[0531] afterSitemap() This hook is triggered after the sitemap is created. You can use this hook to modify the list of pages in the sitemap. For example, you can add information about the search page to the sitemap.

[0532] Home > Wix Code > Advanced Create a data binding router hook. By creating a data binding router hook, you can intercept the process by which data for dynamic pages is bound to the page. This article explains the code you need to write to make a data binding router work. For more information on what a data binding router hook is and why you should create one, see "About Data Binding Router Hooks".

[0533] Add a data binding router hook. To add a data binding router hook, 1. In the Site Structure sidebar, hover your cursor over one of the dynamic pages, click the settings icon that appears, and then click [Settings] to display the page information settings for that page. 2. Under [Other Functions], click [Add Hook] to display the [Add Hook] dialog box. 3. In the [Add Hook] dialog box, select the hook you want to add and click [Add and Edit Code]. When you add a data binding router hook, a function stub for the selected data binding router hook is added to the routers.js file. The routers.js file can be found in the backend section of the site structure sidebar. Data binding router hook functions are named according to the following rules:

number

number

Claims

1. A non-temporary computer-readable medium for updating a backend database containing datasets to be populated on multiple web pages of a website, wherein the computer-readable medium is executed by at least one processor. A step of receiving multiple data elements via a user interface, wherein the data elements are organized into one or more groups of at least one data element, and each group is intended to be displayed on an individual web page of a website. The steps include storing the group of at least one data element in a database, A step of generating multiple virtual web pages, wherein each virtual web page is a preview of the corresponding actual web page before the corresponding actual web page is operational, and each of the corresponding actual web pages is not designed to have a function for updating the database, The steps include displaying each group of data elements on an individual page among the plurality of virtual web pages, The steps include: displaying an editing tool so that the user can edit the virtual web pages from the aforementioned multiple virtual web pages; The steps of converting the edits on the virtual webpage into updates for the database, The steps include storing the update in the database, The steps include: during a live view of the corresponding actual web page associated with the virtual web page, enabling the display of the corresponding actual web page in the state after the updates have been made to the virtual web page during the preview; A non-temporary computer-readable medium containing instructions that cause at least one of the processors to execute.

2. The non-temporary computer-readable medium according to claim 1, wherein each of the plurality of virtual web pages is displayable within a frame associated with the editor interface of the user interface.

3. The non-temporary computer-readable medium according to claim 1, further comprising the step of displaying user-selectable features that allow the user to navigate between the plurality of virtual web pages in order to display each of the plurality of virtual web pages individually and dynamically.

4. The non-temporary computer-readable medium according to claim 1, further comprising the step of displaying a user-selectable function that enables the user to select a particular virtual web page from the plurality of virtual web pages based on an identifier of the particular virtual web page.

5. The non-temporary computer-readable medium according to claim 4, wherein the identifier of the specific virtual web page is based on a data element associated with the specific virtual web page.

6. The non-temporary computer-readable medium according to claim 1, wherein the step further includes associating a unique URL with each of the plurality of virtual web pages.

7. The non-temporary computer-readable medium according to claim 6, wherein each of the plurality of virtual web pages is generated based on a sitemap that references the unique URL of each of the plurality of virtual web pages.

8. The non-temporary computer-readable medium according to claim 1, wherein the editing tool is configured to receive edits to at least one group of data elements stored in the database.

9. The non-temporary computer-readable medium according to claim 1, wherein the editing tool is configured to receive edits to the attributes of the plurality of virtual web pages.

10. The non-temporary computer-readable medium according to claim 1, wherein the editing tool is configured to receive edits to the code used to generate the plurality of virtual web pages.

11. The non-temporary computer-readable medium according to claim 1, wherein the editing tool is configured to display a plurality of segments of skeleton code representing the actual code used to generate the plurality of virtual web pages, and to receive edits to the skeleton code which are converted into edits to the actual code.

12. The non-temporary computer-readable medium according to claim 1, wherein the data elements are received from an external source via the user interface.

13. The operation is, Accessing the software-based router associated with the aforementioned multiple virtual web pages, Configuring the software-based router to generate different versions of the plurality of virtual web pages based on one or more segments of the received URL, A non-temporary computer-readable medium according to claim 1, further comprising:

14. The non-temporary computer-readable medium according to claim 1, wherein a subset of each group of at least one data element is organized by a repeater function, and the repeater function generates one or more displayed instances of the subset of each group of at least one data element.

15. The non-temporary computer-readable medium according to claim 14, wherein the live view of the corresponding actual web page includes one or more instances.

16. A computer-based method for updating a backend database containing datasets to be populated on multiple web pages of a website, wherein the method is A step of receiving multiple data elements via a user interface, wherein the data elements are organized into one or more groups of at least one data element, and each group is intended to be displayed on an individual web page of a website. The steps include storing the group of at least one data element in a database, A step of generating multiple virtual web pages, wherein each virtual web page is a preview of the corresponding actual web page before the corresponding actual web page is operational, and each of the corresponding actual web pages is not designed to have a function for updating the database, The steps include displaying each group of data elements on an individual page among the plurality of virtual web pages, The steps include: displaying an editing tool so that the user can edit the virtual web pages from the aforementioned multiple virtual web pages; step of converting the edits on the virtual web page into updates for the database. and, The steps include storing the update in the database, The steps include: during a live view of the corresponding actual web page associated with the virtual web page, enabling the display of the corresponding actual web page in the state after the updates have been made to the virtual web page during the preview; A computer implementation method, including

17. The computer implementation method according to claim 16, wherein each of the plurality of virtual web pages is displayable within a frame associated with the editor interface of the user interface.

18. The computer implementation method according to claim 16, further comprising the step of displaying user-selectable features that allow the user to navigate between the plurality of virtual web pages in order to display each of the plurality of virtual web pages individually and dynamically.

19. The computer implementation of claim 16, further comprising the step of displaying a user selectable function that allows the user to select a specific virtual web page from the plurality of virtual web pages based on an identifier of the specific virtual web page.

20. The computer implementation method according to claim 16, wherein the identifier of the specific virtual web page is based on a data element associated with the specific virtual web page.

21. The computer implementation method according to claim 16, further comprising the step of associating a unique URL with each of the plurality of virtual web pages.

22. The computer implementation method according to claim 21, wherein each of the plurality of virtual web pages is generated based on a sitemap that references the unique URL of each of the plurality of virtual web pages.

23. The computer implementation method according to claim 16, wherein the editing tool is configured to receive edits to the group of at least one data element stored in the database.

24. The computer implementation method according to claim 16, wherein the editing tool is configured to receive edits to the attributes of the plurality of virtual web pages.

25. The computer implementation method according to claim 16, wherein the editing tool is configured to receive edits to the code used to generate the plurality of virtual web pages.

26. The computer implementation method according to claim 16, wherein the editing tool is configured to display a plurality of segments of skeleton code representing the actual code used to generate the plurality of virtual web pages, and to receive edits to the skeleton code which are to be converted into edits to the actual code.

27. The computer implementation method according to claim 16, wherein the data elements are received from an external source via the user interface.

28. A system that enables the dynamic editing of a web page in order to update a backend database containing a dataset to be populated into the web page, wherein the system An online database configured to store multiple data elements for display on multiple web pages, wherein the data elements are organized into one or more groups of at least one data element, each group being for display on an individual web page of a website, and each individual web page does not have the functionality to update the online database; At least one processor, Remotely provide a browser with instructions to provide an interface for displaying an editable version of a first web page generated based on a group of at least one data element, the interface enabling the user to edit the at least one data element. Edits to the editable version of the first web page received via the interface are converted into updates for the online database. The updates are stored in the aforementioned online database. During live viewing of the first webpage, the first webpage is displayed in a state in which the editable version of the first webpage has been updated. A system comprising at least one processor configured as follows: A system equipped with these features.

29. The system according to claim 28, wherein the at least one processor is further configured to generate a plurality of separate editable versions of a web page, each of which is displayable within a frame associated with the editor interface of the interface.

Images