Editing a database while previewing a virtual web page

Abstract

To update a database containing data sets that populate a plurality of web pages of a website.SOLUTION: A method according to the present invention includes: receiving via a user interface, a plurality of data elements; storing groups of at least one data element in a database; generating a plurality of virtual web pages, wherein each virtual web page is a preview of a corresponding actual web page before the corresponding actual web page goes live; displaying each group of at least one data element on a separate one of the plurality of virtual web pages; displaying an editing tool to permit a user to edit a virtual web page from the plurality of virtual web pages; translating the edits to the virtual web page into updates for the database; storing the updates in the database; and enabling the corresponding actual web page to be displayed in an updated state.SELECTED DRAWING: None

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Provisional Patent Application No. 62 / 536,403, filed July 24, 2017, and U.S. Provisional Patent Application No. 62 / 702,278, filed July 23, 2018, both of which are incorporated herein by reference in their entireties.

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

[0003] The present disclosure relates to a website building system for building indexable websites and web applications that incorporate custom backend functionality running on a system that is fully managed by a third party. For example, embodiments may utilize a stateless server environment (e.g., container, serverless code, or other) to execute web applications when programmable events associated with front-end components or system activity are triggered, without requiring users of the system to be involved in managing client-server interactions. This involves developing custom backend functionality that can run on a virtual machine or other device.

[0004] Additionally, the present disclosure relates to hosting and managing the load of a website by instantly providing on-demand running instances of the website or individual web pages. The instances may, in some embodiments, be spun up as virtual machines, containers, or serverless code elements. More specifically, the present disclosure relates to systems and methods for monitoring the load and activity of hosted websites to automatically add and remove instances that provide the hosted website from the system 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] Still further, the present disclosure relates to website visualization and testing with real-time access to data generated in a production environment for and by end users of the website and data linked to the website. More specifically, the present disclosure relates to providing website developers or designers access to data typically seen by end users of the website to test the functionality and experience of the website.

[0006] Additionally, the present disclosure relates to editing a database during a preview of a virtual web page. For example, a user may store a group of data elements (e.g., text, graphics, video, etc.) in a database, and one or more virtual web pages may be generated to display a preview of the web page. While the virtual web page is displayed, the user may edit the virtual web page, and the user's edits may be converted into updates for the database. Furthermore, during a live view of an actual web page corresponding to the virtual web page, updates to the database may be reflected in the displayed live view.

[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. While traditional website development systems provide a templated front-end UI with limited or no back-end control via calls to external services or embedded code snippets that invoke server-side code, the system is limited to web pages with minimal or no options for data manipulation or other custom functionality. Other systems require significant involvement in setting up client-server interactions to access full back-end control.

[0008] Traditional website development systems lack the ability to create web page layouts that are populated with data to create multiple dynamic pages that can be indexed. Furthermore, traditional systems lack the ability to incorporate software-based routers for web pages that allow web pages to contain different content and functionality depending on how a user accesses or interacts with the web page. Traditional systems also lack the ability to monitor website user interactions and present resulting output based on previously registered functionality associated with those interactions.

[0009] Traditional managed website hosting systems either use dedicated servers that require significant expense and resources to keep ready and operational, or they rely on cold starting new instances when a new website is requested or when the load on a particular website exceeds a certain latency threshold to respond to a request. are used to process requests to websites. This process of cold starting a new instance of a website or web page 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 the previewed page or convert 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 actions, more bandwidth, and more cumbersome operations.

[0011] The website testing system disclosed herein can be set up to create a realistic experience for end users using a website without disrupting the end user's experience. However, conventional website testing systems provide a limited preview interface for reviewing a site as an end user would experience the website, but do not provide real-time access to data generated by the website being tested. Furthermore, conventional systems do not provide the ability to add new data or delete data generated for a site without impacting the end user experience.

[0012] Traditional website hosting systems are also vulnerable to plugins (e.g., software that may be incorporated into the front end or back end of a website) that contain malicious code (e.g., malware). When such code is uploaded by one website owner or user, it can spread through the website hosting system and affect websites of other owners or users. Traditional website hosting systems lack the ability to isolate uploaded plugins and prevent them from infecting other websites commonly hosted by the system. Summary of the Invention

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

[0014] Additionally, there is a need for technical solutions for new on-demand systems that process website requests without significant delay. Such technical solutions should utilize virtual computing resources such as virtual machines, containers, and serverless code. Furthermore, such solutions should enable highly customized websites that include both functionality common to many pages or sites and functionality unique to particular pages or sites.

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

[0016] Additionally, there is a need for technical solutions to isolate uploaded plugins and prevent them from spreading infections to co-hosted websites. Such techniques include: There is a need to be able to separate both front-end and back-end plugins while still allowing website owners and users to upload and use such plugins.

[0017] Certain embodiments of the present disclosure relate to a system for building websites. The system may include an online website building system configured to enable a website builder to add back-end functionality to a centrally hosted website, the centrally hosted website including one or more web pages indexable by a search engine. The online system enables page editing and dynamic previewing to use a common online database that can be simultaneously accessed by designers and users. The system may include an online database configured to store a library of website building elements for constructing a front end for an indexable web page, and at least one processor configured to perform certain operations. The operations may include sending first instructions to a user's remote web browser, the first instructions enabling the user to remotely access the stored library and enable the user to utilize a selection of building elements for constructing a front end of an indexable web page via an integrated interface displayable by the remote web browser, the integrated interface providing the user with access to both the building elements and customized back-end functionality associated with the indexable web page; enabling the user via the integrated interface displayable by the remote web browser to configure programmable events for activating user-editable code that provides the customized back-end functionality associated with the indexable web page; receiving user edits to the user-editable code for implementing the customized back-end functionality associated with the programmable event via the integrated interface; storing the edited user-editable code in a code storage system in communication with an online database; and executing the edited user-editable code for implementing the customized back-end functionality in response to a trigger associated with the programmable event.

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

[0019] Additionally, in some embodiments, the hook is a web hook, a data hook, or a data binding router hook.

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

[0021] Additionally, in some embodiments, the system includes a function associated with a website building element selected by the user and a snippet of code associated with that function as part of the automatically generated skeleton code.

[0022] Additionally, in some embodiments, the system includes a unified interface displayable by a remote web browser, the remote web browser including a front-end website editing window and a customized back-end editing window.

[0023] Additionally, in some embodiments, the system includes triggers for data activity that include specific data sets associated with customized backend functionality.

[0024] Still further, in some embodiments, the system includes triggers for updates entered on indexable web pages.

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

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

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

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

[0029] Additionally, 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] Additionally, in some embodiments, the system includes a storage system that is both an online database and a code storage system.

[0031] Certain embodiments relate to a computer-implemented method for building websites with customized back-end functionality, the method including: maintaining an online database configured to store a library of website building elements for constructing a front-end of an indexable web page; sending first instructions to a user's remote web browser, the first instructions enabling the user to remotely access the stored library and enable the user to utilize a selection of the building elements for constructing the front-end of the indexable web page through a unified interface viewable by the remote web browser, the unified interface providing the user with access to both the building elements and customized back-end functionality associated with the indexable web page; receiving from the user, via the unified interface viewable by the remote web browser, specifications for configuring programmable events for activating user-editable code that provides the customized back-end functionality associated with the indexable web page; receiving, via the unified interface, user edits to the user-editable code for implementing the customized back-end functionality associated with the programmable event; storing the edited user-editable code in a code storage system in communication with the online database; and executing the edited user-editable code for implementing the customized back-end functionality in response to a trigger associated with the programmable event. and

[0032] Further, in some embodiments, the method includes obtaining data outside of the online database and outside of the remote web browser for use in executing the edited user-editable code to implement the customized backend functionality in response to the trigger.

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

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

[0035] Additionally, according to some embodiments, the method includes a hook that is either a web hook, or a data hook, or a data binding router hook.

[0036] Further, according to some embodiments, the method includes generating, by at least one processor based on rules stored in an online database, skeleton code associated with the website building elements selected by the user, and transmitting the skeleton code to a remote web browser for activation of the skeleton code.

[0037] Additionally, according to some embodiments, the automatically generated skeleton code includes the functionality associated with the building element selected by the user and a snippet of code associated with that functionality.

[0038] Additionally, in some embodiments, the method includes providing a unified interface displayable by a remote web browser, the remote web browser including a front-end website editing window and a customized back-end editing window.

[0039] Still further, in some embodiments, the method includes a trigger for data activity involving a particular data set associated with the customized backend functionality.

[0040] Additionally, in some embodiments, the method includes triggering for updates entered on the indexable web page.

[0041] Additionally, in some embodiments, the method includes triggers for defined interactions between a user and an indexable web page.

[0042] Certain embodiments relate to a system for on-demand allocation of web server execution instances for a website server. The system may include at least a first storage location that stores generic website server code for hosting a plurality of websites, and at least a second storage location that stores website-specific code unique to each of the plurality of websites, in a manner separate from the first storage location. The system controls a plurality of web server execution instances, where at least some instances execute website-specific code unique to at least one of the plurality of websites, and at least other web server execution instances execute website-specific code unique to any of the websites. The system may further comprise at least one processor configured to perform operations including: executing generic website server code that lacks unique code; receiving a request to access a specific website, the specific website being built on a platform that includes the generic website server code; determining whether the specific website is already hosted by one of the plurality of web server running instances; if it is determined that the requested specific website is not already hosted by one of the plurality of web server running instances, directing the request to a first of the plurality of web server running instances that executes the generic website server code; populating the first of the plurality of web server running instances that executes the generic website server code with additional website-specific code that is unique to the requested website from at least one second memory location; and responding to the request via the first of the plurality of web server running instances with a combination of both the generic website server code and the populated website-specific code that is unique to the requested website.

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

[0044] Additionally, in some embodiments, the request is an HTTP request, and the system includes an action in response to the request that is performed before the request times out.

[0045] Still further, in some embodiments, the system comprises an action to respond to the request that is performed within 100 milliseconds of receiving the request.

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

[0047] Additionally, in some embodiments, the act of determining further includes querying a web server execution instance manager as to whether the particular website is already hosted by one of the multiple web server execution instances.

[0048] Additionally, in some embodiments, the determining operation further includes forwarding the request to a web server execution instance manager, and, if the request fails, responsively determining that the particular requested website is not currently hosted by one of the plurality of web server execution instances.

[0049] Still further, in some embodiments, the act of determining includes determining, based on the state table, that the particular website is already hosted by one of the plurality of web server running instances.

[0050] Additionally, in some embodiments, the system includes a state table maintained at the proxy server that identifies a list of websites already hosted by one of the multiple running web server instances.

[0051] Additionally, in some embodiments, the system includes an operation of updating the status table to remove inactive websites from the list based on a predetermined period of inactivity of requests associated with the inactive websites.

[0052] Additionally, in some embodiments, additional websites unique to the requested website may be added. The back-end specific code includes back-end code that is unique to the requested website.

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

[0054] Additionally, in some embodiments, the operations further include monitoring a set of web server running instances that are not already hosting the particular website, and instructing the web server running instance manager to spin up additional web server running instances if the size of the set of web server running instances is less than a threshold value.

[0055] Additionally, in some embodiments, the operations further include monitoring a set of web server running instances that are not yet hosting the particular website, and instructing the web server running instance manager to shut down at least one web server running instance if a size of the set of web server running instances is greater than a threshold.

[0056] Certain embodiments of the present disclosure relate to a computer-implemented method for on-demand allocation of web server execution instances for a website server, the method including the steps of: storing generic website server code for hosting a plurality of websites in a first storage location; storing 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, at least some of which execute the website-specific code unique to at least one of the plurality of websites and at least other of which execute generic website server code that is not website-specific; receiving a request to access a particular website, the particular website being built on a platform including the generic website server code; and controlling the plurality of web server execution instances to access the particular website. determining whether the particular requested website is already hosted by one of the plurality of web server running instances; if it is determined that the particular requested website is not already hosted by one of the plurality of web server running instances, directing the request to a first instance of the plurality of web server running instances that executes generic website server code; populating the first instance of the plurality of web server running instances that executes 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 running instances with a combination of both the generic website server code and the populated website-specific code unique to the requested website.

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

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

[0059] Still further, according to some embodiments, the method includes responding to the request being executed within 100 milliseconds of receiving the request.

[0060] Certain embodiments of the present disclosure relate to a system for on-demand allocation of web server execution instances for a website server, which may include at least one memory device that stores generic website server code for hosting multiple websites and website-specific code unique to each of the multiple websites, and at least one processor configured to perform operations. The operations may include controlling a plurality of web server executing instances, at least some of which execute website-specific code unique to at least one of a plurality of websites, and at least other of which execute generic website server code that has no unique code specific to any website; receiving a request to access a particular website, the particular website being built on a platform that includes the generic website server code; determining whether the particular website is already hosted by one of the plurality of web server executing instances; if it is determined that the requested particular website is not already hosted by one of the plurality of web server executing instances, directing the request to a first of the plurality of web server executing instances that executes the generic website server code, the request prompting the first of the plurality of web server executing instances that executes the 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 of the plurality of web server executing instances with a combination of both the generic website server code and the injected website-specific code that is unique to the requested website.

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

[0062] Certain embodiments relate to a system for simultaneously executing live data of a website in a website deployment environment while executing test data of the website in a private website testing environment. The system may include at least one common database that stores both live data of the website and test data of the website, the test data being associated with the live data in the at least one common database; and at least one processor configured to perform operations. The operations may perform functions including: accessing the live data stored in the at least one common database; using the accessed live data to render the website in the 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 the at least one common database in response to the request, the set of test data including one or more test data elements corresponding to respective live data elements, the set of test data being inaccessible in the website deployment environment; and testing the website in parallel in the private website testing environment while the website is running in the website deployment environment such that both sets of test data and live data are simultaneously used by the website in the private website testing environment.

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

[0064] Furthermore, according to some embodiments, the markers are configured to be deleted after testing.

[0065] Additionally, according to some embodiments, the markers indicate instructions to ignore certain live data during testing.

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

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

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

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

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

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

[0072] Still further, according to some embodiments, the system includes a test data element corresponding to each live data element, the test data element including a data element indicating a requested change to be performed on a replica of the respective live data element.

[0073] Additionally, according to some embodiments, the system includes determining a corresponding test data element for the live data element requested to be modified, and, if a corresponding respective test data element exists, performing the requested modification on the corresponding respective test data element.

[0074] Further, according to some embodiments, the system receives a query initiated in the private website test environment, and responds to the query with one or more of the live data elements if one or more live data elements are not associated with a corresponding respective test data element, and responds to the query with one or more of the test data elements if one or more live data elements are associated with a corresponding respective test data element.

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

[0076] Certain embodiments of the present disclosure relate to a computer-implemented method for simultaneously running live website data in a website deployment environment while running test data of a website in a private website testing environment, the method including storing both the live website data and the test website data, wherein the test data is The method may include associating live data in at least one common database; accessing the live data stored in the at least one common database; using the accessed live data to render the website in a website deployment environment; receiving a request to run a test on the website while the website is running in the website deployment environment; accessing a set of test data in the at least one common database in response to the request, the set of test data including one or more test data elements corresponding to respective live data elements, the set of test data being inaccessible in the website deployment environment; and testing the website in parallel in a private website testing environment while the website is running in the website deployment environment such that both sets of test data and live data are used simultaneously by the website in the private website testing environment.

[0077] According to some embodiments, the method may include associating test data with live data using markers configured to cause particular live data elements to be replaced with particular test data elements during testing.

[0078] Furthermore, according to some embodiments, the markers are configured to be deleted after testing.

[0079] Still further, according to some embodiments, the markers indicate instructions to ignore certain corresponding live data during testing.

[0080] Additionally, 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 an area of ​​at least one common database that is hidden from the website deployment environment.

[0082] Certain embodiments of the present disclosure relate to a computer-based system for simultaneously executing test data of a visual application system in a private test environment while executing live data of a visual application system in a deployment environment, the computer-based system comprising: at least one common database that stores both live data of the visual application system and test data of the visual application system, wherein the test data is associated with the live data in the at least one common database; and at least one processor configured to: access the live data of the visual application system stored in the at least one common database; use the accessed live data of the visual application system in the deployment environment; receive a request to run a test on the visual application system while the visual application system is running in the deployment environment; access a set of test data in the at least one common database in response to the request; the set of test data including one or more test data elements corresponding to respective live data elements; 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] Additionally, 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 containing instructions that, when executed by at least one processor, cause the at least one processor to execute certain instructions for updating a backend database that includes a data set to be populated into a plurality of web pages of a website. The instructions may perform operations to receive a plurality of data elements via a user interface, organize the data elements into one or more groups of at least one data element, each group for display on a separate web page of the website, store the at least one group of data elements in a database, generate a plurality of virtual web pages, each virtual web page being a preview of a corresponding actual web page before the corresponding actual web page is run, each corresponding actual web page not designed with functionality for updating the database, display each group of at least one data element on a separate page of the plurality of virtual web pages, display an editing tool to allow a user to edit a virtual web page from the plurality of virtual web pages, translate the edits to the virtual web pages into updates for the database, store the updates in the database, and enable, during a live view of a corresponding actual web page associated with a virtual web page, to display the corresponding actual web page with the updates made to the virtual web page during the preview.

[0085] Additionally, in some embodiments, each of the multiple virtual web pages is displayable within a frame associated with an editor interface of the user interface.

[0086] In a further embodiment, the operations include displaying a user-selectable feature that allows a user to navigate through the plurality of virtual web pages to individually and dynamically display each of the plurality of virtual web pages.

[0087] In an additional embodiment, the action includes displaying a user-selectable feature that allows a 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.

[0088] In a further embodiment, the identifier for a particular virtual web page is based on a data element associated with the particular virtual web page.

[0089] Additionally, according to some embodiments, the operations include associating a unique URL with each of the plurality of virtual web pages.

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

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

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

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

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

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

[0096] In an additional embodiment, the operations further include accessing a software-based router associated with the 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 the received URL.

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

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

[0099] Also disclosed herein is a computer-implemented method for updating a backend database that includes a data set to be populated on multiple web pages of a website. The method may include receiving a plurality of data elements via a user interface, the data elements being organized into one or more groups of at least one data element, each group for display on a separate web page of the website; storing the at least one group of data elements in a database; generating a plurality of virtual web pages, each virtual web page being a preview of a corresponding actual web page before the corresponding actual web page is run, each corresponding actual web page not designed with functionality for updating the database; displaying each group of at least one data element on a separate page of the plurality of virtual web pages; displaying an editing tool to allow a user to edit a virtual web page from the plurality of virtual web pages; translating the edits to the virtual web page into updates for the database; storing the updates in the database; and enabling, during a live view of a corresponding actual web page associated with a virtual web page, the corresponding actual web page to be displayed with the updates made to the virtual web page during the preview.

[0100] In some embodiments, each of the multiple virtual web pages is displayable within a frame associated with an editor interface of the user interface.

[0101] Additionally, in some embodiments, the method further includes displaying a user-selectable feature that allows a user to navigate across the plurality of virtual web pages to individually and dynamically display each of the plurality of virtual web pages.

[0102] In an additional embodiment, the method further includes displaying a user-selectable feature that allows a 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.

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

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

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

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

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

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

[0109] Still further, in some embodiments, the editing tool is configured to display segments of skeleton code representing the actual code used to generate the virtual web pages, and to receive edits to the skeleton code that are converted into edits to the actual code.

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

[0111] An additional disclosed embodiment relates to a system for enabling dynamic editing of web pages to update a backend database that includes data sets to be populated in the web pages. The system may include an online database configured to store a plurality of data elements for display on a plurality of web pages, the data elements organized into one or more groups of at least one data element, each group for display on a separate web page of a website, each separate web page having no functionality for updating the online database; and at least one processor configured to perform operations: remotely providing instructions to a browser to provide an interface displaying an editable version of a first web page generated based on the at least one group of data elements, the interface allowing a user to edit the at least one data element, translating edits to the editable version of the first web page received via the interface into updates for the online database, storing the updates in the online database, and enabling displaying the first web page with the updates to the editable version of the first web page during a live view of the first web page.

[0112] Further embodiments include the act of generating a plurality of separate editable versions of the web page, each of the separate editable versions of the web page displayable within a frame associated with an editor interface of the interface.

[0113] Certain embodiments of the present disclosure relate to a system for previewing dynamic web pages via an online editor interface, comprising: an online database configured to store a plurality of data elements for display on a plurality of web pages and to store first instructions for enabling the data elements to be organized into a plurality of groups, each of the plurality of groups including at least one data element; an online database associated with at least one individual web page, each of the plurality of groups further available to at least one of front-end code executable by the browser and back-end code executable by a back-end server remote from the browser to configure a plurality of scrollable virtual web pages; and at least one processor remotely providing second instructions to the browser for displaying an interface that enables 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 controlling the user's added data elements, the association of the added data elements with at least one of the plurality of groups, and the front-end code and the back-end code. and at least one processor configured to execute third instructions for generating a plurality of scrollable virtual web pages based on a modification of at least one of the data elements, the plurality of scrollable virtual web pages being configured to be independently generated by the at least one processor and independently edited by a user; and remotely provide to a browser fourth instructions for displaying a preview interface configured to display the plurality of scrollable virtual web pages prior to generation of the corresponding final web pages, the preview interface enabling a user to selectively scroll through 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 at least one group of data elements will appear in a corresponding final web page before the corresponding final web page is run.

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

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

[0116] Still further, 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] Additionally, according to some embodiments, the system may include multiple scrollable virtual web pages displayable within frames associated with the online editor interface.

[0118] Additionally, according to some embodiments, the system may include a preview interface that may include a user-selectable feature that allows a user to scroll through multiple scrollable virtual web pages.

[0119] Additionally, according to some embodiments, the system includes a preview interface that may include user-selectable features that allow a user to select particular virtual web pages for display based on the identifiers of the respective virtual web pages.

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

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

[0122] Additionally, according to some embodiments, the system includes multiple scrollable virtual web pages that can be generated based on a site map that references a unique URL for each web page.

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

[0124] Still further, according to some embodiments, at least one individual web page is indexable by a search engine.

[0125] Additionally, 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] Additionally, according to some embodiments, the software-based router is capable of constructing at least one individual web page in a number of different ways based on a number of different possible URL segments provided by the user.

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

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

[0129] Additionally, the multiple groups may be associated with at least one of a website that includes multiple separate web pages and an associated group of websites.

[0130] Additionally, according to some embodiments, the system may include a subset of the plurality of data elements organized by a repeater function, which generates one or more display instances of the subset of the plurality of data elements.

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

[0132] Certain embodiments of the present disclosure relate to a computer-implemented method for previewing dynamic web pages via an online editor interface, the method comprising the steps of storing a plurality of data elements for display on a plurality of web pages, and storing first instructions for enabling the data elements to be organized into a plurality of groups, each of the plurality of groups including at least one data element and associated with at least one distinct web page, each of the plurality of groups further comprising front-end commands executable by a browser to configure a plurality of scrollable virtual web pages. remotely providing to the browser second instructions for displaying an interface that enables 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 executing third instructions for generating a plurality of scrollable virtual web pages based on the user's added data elements, their association with at least one of the plurality of groups, and their modification of at least one of the front-end code and the back-end code. The method may include: configuring a plurality of scrollable virtual web pages to be independently generated by at least one processor and independently edited by a user; and remotely providing fourth instructions to a browser for displaying a preview interface configured to display the plurality of scrollable virtual web pages prior to generation of corresponding final web pages, the preview interface enabling a user to selectively scroll through 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 at least one group of data elements will appear in a corresponding final web page before the corresponding final web page is run.

[0133] According to some embodiments, the method includes remotely providing additional instructions to the browser for displaying an online editor interface to enable a user to drag and drop a selection of the at least one website building element onto the web page template for associating the at least one website building element with one of the data elements for building a front end of the web page.

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

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

[0136] Certain embodiments of the present disclosure relate to a system for navigating among dynamic web pages, the system comprising an online database storing a plurality of data elements for display on a plurality of dynamic web pages. The database can also store first instructions for enabling the data elements to be organized into a plurality of groups, each of the plurality of groups including at least one data element and associated with at least one of the plurality of dynamic web pages, and each of the plurality of groups further usable by at least one of front-end code executable by a browser and back-end code executable by a back-end server remote from the browser to configure the plurality of dynamic web pages, each of the plurality of dynamic web pages configured to be independently generated and independently edited. The system can also include at least one processor configured to remotely provide to the browser second instructions for displaying a navigation interface as part of at least one of the plurality of dynamic web pages, the navigation interface being configured to display the plurality of dynamic web pages automatically generated based on each of the plurality of groups of at least one data element. The navigation interface is configured to allow a user to selectively navigate through each of the dynamic web pages, and the navigation interface is not a native element of the multiple dynamic web pages.

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

[0138] Still further, according to some embodiments, the dynamic web pages have an order determined based on a site map.

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

[0140] Certain embodiments of the present disclosure relate to a system for hosting websites implemented in a server environment, the system including at least one hosting server configured to co-host a plurality of websites created by a plurality of users, the hosting server including a hosted common editing tool accessible to the plurality of users to enable each of the plurality of users to selectively modify a particular website created by each of the plurality of users, the hosting server further configured to prevent at least some of the plurality of users from modifying a particular co-hosted website created by another of the plurality of users, and an interface for display by at least a subset of the plurality of users to enable at least a subset of the plurality of users to upload to the hosting server plug-in code associated with a plug-in for the particular co-hosted website created by the at least a subset of the plurality of users. the at least one processor configured to execute an isolation mechanism to isolate the at least one particular plug-in, wherein plug-in code for the at least one particular plug-in includes at least one of a front-end plug-in function code executable by a client or a back-end plug-in function code executable by a plug-in server; and a memory for storing user-uploaded plug-in code associated with the at least one particular plug-in such that the stored user-uploaded plug-in code is centrally hosted on a common domain together with the co-hosted particular websites created by a plurality of users, wherein a single instance of the at least one particular plug-in is shared by the plurality of co-hosted particular websites, wherein for each of the plurality of co-hosted particular websites sharing the at least one uploaded plug-in, the at least one processor uses the isolation mechanism to:The method is further configured to securely enable at least one of execution of front-end plugin function code at the client or execution of back-end plugin function code at the plugin server, and based on the isolation mechanism, prevent malicious code included in the at least one uploaded plugin from affecting other sites of a particular website co-hosted on the hosting server.

[0141] According to some embodiments, the system includes a plug-in server and a hosting server that is the same server.

[0142] Furthermore, according to some embodiments, the system may be configured to use a separate server from the hosting server. It may include a separation mechanism that allows for execution of backend plug-in functionality code in a plug-in server.

[0143] Still further, according to some embodiments, the system may include an isolation mechanism that enables execution of backend plug-in function code in a virtual machine.

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

[0145] Additionally, according to some embodiments, the system may include an isolation mechanism that includes running backend plug-in functionality code via a separate process in a plug-in server.

[0146] Additionally, according to some embodiments, the system may include an isolation mechanism that allows for execution of front-end plug-in functionality code in a secure sub-area of ​​a particular co-hosted website.

[0147] Still further, according to some embodiments, the system may establish a secure communication channel to control communications between a subarea of ​​a particular co-hosted website and other subareas of the particular co-hosted website.

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

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

[0150] Additionally, according to some embodiments, the system may include an isolation mechanism that enables execution of front-end plug-in functionality code through an iframe in a client's browser, the iframe configured to act as a secure sandbox for the execution of the front-end plug-in functionality code.

[0151] Still further, according to some embodiments, the system can associate client-executable front-end plug-in functionality code with distinct web page sub-areas of a particular co-hosted website.

[0152] Additionally, according to some embodiments, the system can associate more than one trusted plug-in with a particular co-hosted website.

[0153] Additionally, according to some embodiments, the system may enable at least one uploaded plugin to communicate with and control at least one component of a particular co-hosted web page on which the front-end plugin functionality code executes.

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

[0155] Still further, according to some embodiments, the system may include at least one uploaded plug-in that is separate from cookies associated with web pages of a particular co-hosted website.

[0156] Certain embodiments of the present disclosure relate to a computer-implemented method for hosting a website implemented in a server environment.The method includes the steps of co-hosting, on a hosting server, a plurality of websites created by a plurality of users; making a common editing tool available to the plurality of users to enable each of the plurality of users to selectively modify a particular website created by each of the plurality of users; preventing at least some of the plurality of users from modifying the particular co-hosted websites created by other of the plurality of users; and generating an interface for display by at least a subset of the plurality of users to enable at least a subset of the plurality of users to upload to the hosting server plug-in code associated with plug-ins for the particular co-hosted websites created by the at least a subset of the plurality of users, wherein the plug-in code for the at least one particular plug-in is either front-end plug-in function code executable by a client or back-end plug-in function code executable by a plug-in server. storing user-uploaded plug-in code associated with at least one particular plug-in such that the stored user-uploaded plug-in code is centrally hosted on a common domain together with co-hosted specific websites created by multiple users, wherein a single instance of the at least one particular plug-in is shared by the multiple co-hosted specific websites; and for each of the multiple co-hosted specific websites that share the at least one uploaded plug-in, using an isolation mechanism to safely enable at least one of execution of front-end plug-in function code on a client or execution of back-end plug-in function code on a plug-in server, wherein, based on the isolation mechanism, malicious code included in the at least one uploaded plug-in is prevented from affecting other sites of the multiple co-hosted specific websites on the hosting server.

[0157] According to some embodiments, the method may include separating at least one uploaded plug-in from cookies associated with web pages of a particular co-hosted website.

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

[0159] Still further, according to some embodiments, the method may include an isolation mechanism that allows for execution of backend plug-in functionality code in a plug-in server that is separate from the hosting server.

[0160] Additionally, according to some embodiments, the method may include an isolation mechanism that allows for execution of backend plug-in function code in a virtual machine.

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

[0162] Additionally, according to some embodiments, the method may include an isolation mechanism that allows execution of backend plug-in functionality code via an isolated process in the plug-in server.

[0163] Still further, according to some embodiments, the method can include front-end plug-in functionality code executable by the client, the front-end plug-in functionality code configured to generate a user interface in an iframe in the browser.

[0164] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed. [Brief explanation of the drawings]

[0165] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate several embodiments and, together with the description, serve to explain the principles of the present disclosure.

[0166] [Figure 1] FIG. 1 illustrates an exemplary online website building system that interacts with other systems and components in accordance with some embodiments of the present disclosure.

[0167] [Figure 2] FIG. 2 is a diagram illustrating an exemplary online website building system according to some embodiments of the present disclosure.

[0168] [Figure 3] FIG. 3 is a diagram illustrating a path to execution of backend code associated with a trigger, according to some embodiments of the present disclosure.

[0169] [Figure 4] FIG. 4 illustrates an example online editor interface for updating backend functionality, according to some embodiments of the present disclosure.

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

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

[0172] [Figure 7] FIG. 7 is a flowchart illustrating a method for triggering execution of backend code according to some embodiments of the present disclosure.

[0173] [Figure 8]FIG. 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] FIG. 9 is a schematic diagram of interactions between various on-demand web server execution instance system components, according to some embodiments of the present disclosure.

[0175] [Figure 10] FIG. 10 is a flowchart illustrating a method for responding to a web request sent for a website according to some embodiments of the present disclosure.

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

[0177] [Figure 12] FIG. 12 is a diagram illustrating the instantiation of a web server execution instance element at a website, according to some embodiments of the present disclosure.

[0178] [Figure 13] FIG. 13 illustrates load monitoring of hosted websites and management of in-use instances according to some embodiments of the present disclosure.

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

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

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

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

[0183] [Figure 17] FIG. 17 is an illustration of website access to live and test data in a test environment, according to some embodiments of the present disclosure.

[0184] [Figure 18] FIG. 18 is a diagram illustrating the generation of test data used in a test environment for testing websites, according to some embodiments of the present disclosure.

[0185] [Figure 19] FIG. 19 is a flowchart illustrating a method for accessing a website in a deployment environment according to some embodiments of the present disclosure.

[0186] [Figure 20] FIG. 20 is a flowchart illustrating a method for accessing a website in a test environment according to some embodiments of the present disclosure.

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

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

[0189] [Figure 23a] FIG. 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] FIG. 23b is a flowchart of a method for updating a data element in a deployment environment according to some embodiments of the present disclosure.

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

[0192] [Figure 24] FIG. 24 is a flowchart illustrating a method for deleting a data element from a test environment according to some embodiments of the present disclosure.

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

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

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

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

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

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

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

[0200] [Figure 32] FIG. 32 is a schematic diagram illustrating the relationship between data groups and websites, according to some embodiments of the present disclosure.

[0201] [Figure 33] FIG. 33 is a schematic diagram illustrating components involved in generating a virtual web page according to some embodiments of the present disclosure.

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

[0203] [Figure 35] FIG. 35 is a schematic diagram of a user's interaction with a website hosting system, according to some embodiments of the present disclosure.

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

[0205] [Figure 37]FIG. 37 is a diagram illustrating a group of co-hosted websites sharing plug-in code under a common root, according to some embodiments of the present disclosure.

[0206] [Figure 38] FIG. 38 is a diagram illustrating an isolated execution environment for backend plug-in code, according to some embodiments of the present disclosure.

[0207] [Figure 39] FIG. 39 is a diagram illustrating controlled access and execution of front-end plug-in code according to some embodiments of the present disclosure.

[0208] [Figure 40] FIG. 40 is a diagram illustrating client-side, separate execution of plug-in code according to some embodiments of the present disclosure.

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

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

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

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

[0213] [Figure 45] FIG. 45 illustrates 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] FIG. 46 illustrates an exemplary user interface for editing a web page and creating a repeater function, according to some embodiments of the present disclosure.

[0215] [Figure 47] FIG. 47 illustrates an exemplary user interface for editing a web page and showing the results of a repeater function, according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0216] In the following detailed description, numerous specific details are set forth to provide a thorough understanding of exemplary embodiments of the present disclosure. However, those skilled in the art will understand that the principles of the exemplary embodiments may be practiced without all of the specific details. Well-known methods, procedures, and components have not been described in detail so as not to obscure the principles of the exemplary embodiments. Unless explicitly stated, the exemplary methods and processes described herein are not constrained to a specific order or sequence, or to a specific system configuration. In addition, some of the described embodiments or elements thereof may occur or be performed simultaneously, at the same time, or in parallel. Embodiments of the present disclosure will now be described in detail, examples of which are illustrated in the accompanying drawings. Unless explicitly stated, transmitting and receiving, as used herein, should be understood to have a broad meaning, including transmitting or receiving in response to a specific request, or transmitting or receiving without such a specific request. Thus, these terms encompass both active and passive forms of transmitting and receiving.

[0217] Systems and methods consistent with the present disclosure are directed to a website building system that includes customized front-end and back-end functionality. In some embodiments, the website building system may include options for user configuration of back-end functionality development capabilities.

[0218] 1 illustrates an exemplary system that interacts with other components and users over a network, according to some embodiments of the present disclosure. As shown in FIG. 1, a 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 manages widgets and other tools used on websites, databases, or similar data storage structures, code or data representing the website being built or under development, and data created, updated, and viewed using the website being built or under development (e.g., inventory for an e-shop underlying an e-commerce website, etc.). ) and can be repositories of.

[0219] The WBS editor 110 may be an editor for building and editing websites. The editor allows users 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), which may be stored in the WBS CMS 120. The WBS editor 110 may define the visual layout and other attributes of the pages of the website being built. A template may 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 structure of the site by defining the navigation between various pages. The WBS editor 110 defines the layout of pages by allowing users to arrange components on the web pages as they would like them to appear on the actual web pages.

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

[0221] The construction tools 121 can include widgets, which are components laid out on a page being edited by the WBS editor. In some embodiments, widgets can 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 editing, video editing, visitor counting, social media integration, etc.).

[0222] WBS CMS 120 can store both the components for building websites and the built websites. In some embodiments, the components and websites are maintained in separate CMS systems. As shown in Figure 1, building tools 121 are stored in WBS CMS 120, including widgets and other tools that aid in the easy building of websites.

[0223] The building tools 121 are the building blocks of a website that facilitate the process of constructing a website and including content on the website. The building tools 121 can include both component tools or widgets, such as those described above, such as tabs, search bars, buttons, galleries, slide decks, etc., and manipulation tools, such as alignment tools. The building tools 121 can include both simple widgets (e.g., buttons, text fields, etc.) and complex widgets (e.g., galleries, calendar widgets, etc.), and are configured to perform advanced functions. The building tools 121 are the building blocks of a website that facilitate the process of constructing a website and including content on the website. The build tools 121 can be represented as an abstraction of code representing jets and other tools. Build tools 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. Build tools 121 may be shared among multiple websites built and owned by different user groups. Build tools 121 may also be customized by editing the code of existing build tools 121 (e.g., updating the style sheet for a button and creating a new style sheet for a new button). Custom build tools may be stored in the system area database 122 along with the original build tools 121.

[0224] The WBS editor 110 provides remote access to the construction tools 121 stored in the system area database 122 of the WBS CMS 120. An instance of a selected widget in the construction tools 121 may be created when a user places the widget on a page being edited with the WBS editor 110. An instance of a selected widget from the construction tools 121 may be created by a reference to the widget in the page. An instance of a selected widget from the construction tools 121 may also be created by copying code representing the selected widget into a web page of a website being built.

[0225] The WBS editor 110 is typically server-hosted software, and some or all of its elements may be loaded into a user's website viewing device 130 (or their web browser 131) for execution. In some embodiments, the WBS editor 110 may share the system area database 122 with the construction tool 121, or 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, a website 123 is a website built using the WBS editor 110 and stored in the site area database 124. The websites 123 stored in the site area database 124 may include text representing code and data that can be accessed, updated, and displayed using the website development device 140. The website 123 may include one or more web pages, including indexable web pages 125. In some embodiments, for example, the 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 / ). The indexable web pages 125 may include a front end 126 and a back end 127. An indexable web page 125 may include special files or code that include or reference a front end 126 and a back end 127, as indicated by the dashed lines, or may simply be a name for a collection of front ends 126 and back ends 127. A front end 126 may be composed of widgets and other UI elements, which may be instances of a build tool 121, including instance-specific information (such as position, size, attribute values, etc.); such instance-specific information may also include containment information (i.e., which components are contained within which containers). A front end 126 may also include code elements, such as code segments that execute in the front end 126 (which may affect widgets during runtime). A front end 126 may also store page metadata, such as a title, It may further comprise any other element.

[0227] The front end 126 includes instances of the construction tools 121 located on indexable web pages 125 of the website 123 built using the WBS editor 110, such as instances that are always visible to users, instances that are displayed by default, or instances that are displayed at least part of the time. The back end 127 represents functionality that may be activated when a user interacts with the front end 126 or through non-interaction events, such as a communication coming into the website 123, a time-based trigger, or a change to a database connected to the website 123. The back end 127 may be seen only occasionally or never by users of the website development device 140 and the WBS vendor staff device 150. The front end 126 and the back end 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 front end 126 and the back end 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 the FE 126 is converted into a different programming language before being stored in the site area database 124 .

[0228] In some embodiments, the code and data for the website 123 may share a database or may have separate databases. In some embodiments, the code representing the front end 126 and back end 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 file location may be stored in the site area database 124. In some embodiments, the code is stored in a single location in the site area database 124 or in a file column. In some embodiments, the code may be split into multiple files.

[0229] In some embodiments, indexable web page 125 may be a dynamic web page and front end 126 may be a template and not an actual web page. As described further below, a dynamic web page may be a web page configured to change appearance or content based on customized back-end functionality. Examples of customized back-end functionality, described further below, include updating data displayed on the web page, resizing or changing images on the web page, triggering the rendering of video content on the web page, etc. In some embodiments, the front end 126 of a dynamic web page may be a template bound directly to data from database tables to update the content and appearance of various dynamic web pages.

[0230] In some embodiments, WBS 100 may include more or fewer components than those shown in FIG. 1 . For example, databases 122 and 124 may be a single database or separate databases. The databases may also 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-premise 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-premise and cloud-based networks.

[0231] As shown in FIG. 1 , websites 123 stored in site area database 124 of WBS CMS 120 can be accessed by website viewing device 130 (e.g., desktop computer, tablet, laptop, smartphone, etc.) via web browser 131. A user (not shown) of website viewing device 130 can request access to website 123 via network 160 (e.g., the Internet, including intermediate networks between website viewing device 130 and WBS 100). Web browser 131 (e.g., APPLE SAFARI, GOOGLE CHROME, MOZILLA FIREFOX, MICROSOFT EXPLORER, etc.) of web viewing device 130 can be used to view website 123 and data created and edited using website 123. Website development device 140 can be used to build website 123 using WBS editor 110. Web browser 141 on website development device 140 can be used to make requests to access WBS editor 110 to build website 123. WBS vendor staff device 150 may be used to provide customer support for users (not shown) of website development device 140 in building and maintaining website 123. WBS vendor staff device 150 may also be used by third-party vendors to create and customize construction tools 121. WBS vendor staff device 150 may also be used to configure WBS 100 itself, for example, to manage site designer and user accounts, manage the site or page templates described above (creating new templates or editing existing templates), or manage various elements comprising WBS 100.

[0232] In some embodiments, website viewing device 130, website development device 140, and 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, 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] Website browsing devices 130, website development devices 140, and WBS vendor staff devices 150 can access website 123 via network 160. In some embodiments, website browsing devices 130, website development devices 140, and WBS vendor staff devices 150 may be mobile devices, laptops, desktop computers, tablets, etc.

[0234] As shown in FIG. 1 , search engines 170 (e.g., GOOGLE, YAHOO, BING, etc.) can access the indexable web pages 125 of websites 123 stored in site area database 124 via network 160, regardless of whether they interact with WBS 100. Search engine 170 indexes the indexable web pages 125 of websites 123 to facilitate discoverability, thereby increasing the number of users who use website viewing devices 130 to browse websites 123. In some embodiments, building tool 121 further enables users to optimize websites 123 for indexing and searching via search engine 170. For example, building tool 121 may enable users to search for text that appears in the header of a particular indexable web page 125, text that appears in a particular location on indexable web page 125, or text that is associated with indexable web page 125 (e.g., as metadata). Allow them to choose.

[0235] 2 illustrates an exemplary structure of WBS 100, according to some embodiments of the present disclosure. As shown in FIG. 2, WBS 100 includes site area database 124, which includes components for both building and hosting websites, as described above in connection with FIG. 1.

[0236] In some embodiments, indexable web page 125 may be a dynamic or virtual web page where components of front end 126 may be populated with data from data group 210. Data group 210 may be associated with multiple web pages. Data group 210 may be composed of data elements, including data element 211. Data element 211 may be associated with one or more components of build tool 121 used in front end 126 of indexable web page 125. As an example, data group 210 may be an employee database, where each data element 211 is an employee record including multiple data fields (e.g., name, age, department information, etc.). These multiple fields may be used to populate multiple displayed components (display fields) in front end 126 of indexable web page 125. In some embodiments, data group 210 is stored in site area database 124 as part of a table, and data element 211 is a row in that table. The web page associated with data group 210 may be, for example, a dynamic web page.

[0237] Data elements 210 may be associated with URL association DB 220. When a user accesses an indexable web page 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 lookup with URLs or URL segments stored in URL association DB 220. Data groups may be associated with URLs or URL segments in URL association DB 220. The URLs or URL segments in URL association DB 220 may help determine data groups to use in generating a virtual or dynamic web page using the associated indexable web page 125. In some embodiments, indexable web page 125 is a template for a dynamic or virtual web page, and the actual web page is generated using data from data groups 210 determined using the URLs in URL association DB 220.

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

[0239] The first instructions 240 may be a set of instructions accessed by the web browser 141 and configurable through the processor 260. The first instructions 240 help the web browser 141 remotely access a stored library of tools, including the construction 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 construction tool 121 and the associated front-end 126 and back-end 127 code of the indexable web page 125. Similar to the first instructions 240, additional instructions (e.g., second instructions 250 and third instructions 260, among other instructions) may also be accessible to the processor 260 and the web browser 141.

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

[0241] FIG. 3 illustrates a path to the execution of backend code associated with a trigger, according to some embodiments of the present disclosure. As shown in FIG. 3, a trigger 310 can result in the execution of code associated with the backend 127. The trigger 310 can occur, for example, when a user of the web browsing device 130 interacting with an indexable web page 125 of the website 123 performs a specific action (e.g., a mouse or touchpad click, a selection, a cursor hover, a reload request, a text entry, an upload of multimedia content, etc.). The trigger 310 can also occur during non-interaction events. For example, a periodic time-based action or a database update may trigger and execute code in the backend 127 and / or the frontend 127. The trigger 310 is customizable and can take many different forms. Additionally, interactions necessary to result in the execution of code associated with the backend 127 can occur via a programmable event 320. The 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 programmable event 320 and backend 127 may be configurable and may depend on the type of interaction or other type of event that caused trigger 310. Programmable event 320 utilizes one or more of data hooks 330, web hooks 340, or data binding router hooks 350, among other possible types of hooks, to pass control to backend 127 for executing code in backend 127.

[0242] When a data update is entered by a user of web browsing device 130 on indexable web page 125 of website 123 shown in web browser 131, data hook 330 can be used to pass control from programmable event 320 to backend 127. For example, a form submission can be considered a data update, and data hook 330 can be used to pass control to backend 127, allowing the backend to update the data. The backend 127 creates or updates database entries in some embodiments. 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 can result in entries in the database older than a period of time being deleted or marked as inactive.

[0243] Webhooks 340 may be used to pass control from programmable events 320 to backend 127 when web module functions are imported and called in code that is part of frontend 126. In some embodiments, for example, code that is part of frontend 126 is called a frontend script and executes when a user of a web browsing device interacts with a frontend 126 component of an indexable web page 125 of a website 123 displayed in a web browser 123. For example, webhooks 340 may be based on a user of indexable web page 125 using an app, making a purchase, subscribing to content on indexable web page 125, etc.

[0244] The data binding router hook 350 may be used to pass control from the programmable event 320 to the backend 127 when a particular dynamic web page is requested by a user of the web browsing device 130 by navigating to a particular URL in the web browser 131. For example, navigation may occur by entering the URL in the address bar of the web browser 131, by clicking a hyperlink on an indexable web page 125 of the 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 web page template defined by the backend 127 code function.

[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 web page 125 enters the URL of the indexable web page 125, the software-based router can determine the data to display on the indexable web page 125, or even the specific web page to display. The router can be associated with a prefix, which is the first part of the URL (or another segment of the URL). For example, in the URL http: / / www.wix.com / label, "label" can be the prefix. Furthermore, in the URL http: / / www.wix.com / label / sub-label, "sub-label" can be the suffix. Based on the specific segment of the provided URL (e.g., the prefix, suffix, or parameter value), the router can determine that content associated with or a specific web page associated with should be displayed. For example, the prefix can be associated with a router, and the suffix can be passed to a selected router to determine the page to access or the data to use in the page. The router can also be used to generate complete virtual or dynamic pages based on selected data and templates. In this manner, the indexable web pages 125 of the 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 allows the website browsing device 130 The data hook 330 may function to pass control based on internal events following a user's interaction with the website 123. For example, a data binding router hook 350 may be registered to execute a function before determining whether the user has permission to access the page to which they are routed, as described above. The data hook 330 may execute before or after the data binding router hook 350, depending on the trigger 310. For example, after executing a query against a database connected to the website 123, the data hook 330 may execute to filter out entries that are no longer active (e.g., a merchant website may filter out products that are no longer for sale from database query search results). Thus, the system can support various combinations of hooks operating and chaining hooks together.

[0247] 4 is a block diagram illustrating an example 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 FIG. 4, the online editor interface 243 is composed of an integrated interface 410 and a preview interface 420.

[0248] The unified interface 410 may be used to develop or build indexable web pages 125 for the website 123. As described above, the unified interface 410 may provide access to the construction tools 121. The construction tools 121 may include editing tools 411 to aid in editing the indexable web pages 125 for the website 123. In some embodiments, the unified interface 410 may be a separate section displayed on the web browser 141 during development. In other embodiments, the unified interface 410 may be a collective term for various tools and user interface sections. In some embodiments, the unified interface 410 may be a separate section of a displayed web page or a floating window or frame. In some embodiments, components of the unified 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 in edit mode or in separate windows. In some embodiments, they may be displayed 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 between websites and developers of different websites. When a developer saves the website 123, the front end may be saved in the form of the front end 126.

[0250] The preview interface 420 helps the user visualize the website 123 being constructed by displaying the web page 125 as it would appear in the real world, i.e., as it would appear in a web browser 131 of a web viewing device 130 displaying a 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 possible.

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

[0252] As shown in FIG. 5, the unified interface 410 is a 4. In this exemplary illustration, front end 126 displays indexable web page 125. In this exemplary illustration, front end 126 is shown using a WYSIWYG editor to visually edit the page's content (e.g., text, graphics, widgets, etc.). In some embodiments, front end 126 may be edited directly as code. In some embodiments, building tools 121 are user interface sections within unified interface 410. In further embodiments, building tools 121 may be accessed by menu items in online editor interface 243. In some embodiments, specific website building tools selected from building tools 121 may be dragged and dropped in the front end 126 section of unified interface 410. Front end 126 of indexable web page 125 shows the visual configuration of building tools 121.

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

[0254] WBS 100 may be configured to automatically generate skeleton code upon selecting elements from build tool 121 and placing the elements in front end 126. The generated skeleton code shown in back end 127 may include, for example, shell function 521 and shell code 522. Shell function 521 and shell code 522 together represent programmable events 320 in code executed by trigger 310. In some embodiments, as shown, shell function 521, called buttonClick, is code that represents the event of clicking a button. The button click trigger results in the programmable event buttonClick.

[0255] 6 is a flowchart illustrating a method 600 for developing backend functionality 127 according to some embodiments of the present disclosure. In some embodiments, method 600 may be performed by components of WBS 100, as described above.

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

[0257] In step 620, the WBS 100 sends the first instructions 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 over the network 160. The request is forwarded to the website CMS 120. The website CMS 120 provides access to the first instructions 240 upon request by the processor 260, and the first instructions 240 are sent to the website browser 141. The first instructions 230 provide access to the construction tools 121 stored in the site area database 124, which enable the front end 126 and back end 127 of the web page 125 to be constructed.

[0258] In step 630, upon receiving a request from a website development device 140 via network 160 to use a tool in the building tool 121, the WBS 100 , automatically generating skeleton code for a selected tool in the build tool 121 based on the selected tool. For example, as described above in connection with FIG. 5, the skeleton code may be associated with events such as mouse clicks, hovers, content selections, etc.

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

[0260] In step 650, WBS 100 may provide access to customized backend functionality 127 associated with the web page 123 for which frontend 126 is being edited or created. As noted above, backend functionality 127 may take a variety of different forms and may be configured to occur based on a variety of defined events.

[0261] In step 660, the WBS100 may receive specifications from a user of the website development device 140 via the web browser 141 to configure programmable events 320 for activating customized backend functions 127.

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

[0263] In step 680, the WBS 100 may store the edited user-editable code received from the website development device 140 over the network 160 in the site area database 124. The edited user-editable code may then be ready to be deployed to provide customized backend 127 functionality for the indexable web page 125.

[0264] 7 is a flowchart illustrating a method 700 for triggering execution of backend code 127 according to some embodiments of the present disclosure. As mentioned above, method 700 may be performed in conjunction with method 600. Consistent with the above discussion, method 700 may be performed in a system of WBS 100.

[0265] 7 , a user of a website viewing device 130 can trigger 310 a programmable event 320 associated with the backend 127 by either transitioning through an indexable web page 125, as shown in step 711, interacting with the indexable web page 125, as shown in step 712, or entering an update to the indexable web page 125, causing the trigger 310, as shown in step 713. For example, step 711 may include the user clicking a nested hyperlink in the indexable web page 125 associated with another web page portion of the same website 123. Similarly, step 711 may include the user clicking a “next” or “continue” hyperlink in the indexable web page 125 to view a subsequent related page. Step 712 may include, for example, the user hovering a cursor over a graphic or text on the indexable web page 125, pausing for a predetermined period of time, clicking an image or text on the indexable web page 125, etc. Step 713 allows the user to update text content on the indexable web page 125, upload image or video files to the indexable web page 125, fill in forms on the indexable web page 125, and perform other actions. This may include a period timer, a database update, etc. that results in an action.

[0266] In step 720, upon receiving notification of a programmable event 320, the WBS 100 responsively accesses 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 hooks associated with the programmable event 320 may include accessing internal data (e.g., Wix data) of the website 123 stored in the site area database 124.

[0267] In step 730, WBS100 may optionally obtain data external to online site area database 124 and 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 programmable event 320.

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

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

[0270] Generally, when a user interacts with a website, they may make various HTTP requests. For example, an initial HTTP request may be made to load a web page (which may, in some circumstances, trigger additional HTTP requests to load additional page elements, such as images or scripts). In addition, a user may also make HTTP requests during a session (e.g., selecting a value in a field, clicking a hyperlinked image, etc.). Furthermore, a user may make data-related HTTP requests, such as through form submission. In addition, a user may make backend HTTP requests, which may activate backend functionality (e.g., via backend code described herein).

[0271] To speed up the process of loading pages and handling HTTP requests, the system (e.g., WBS100) can be configured to take advantage of fast startup of Docker containers or serverless code configured for a particular website or page. In some embodiments, 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 user- 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 from 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 be, for example, the actual browser-ready page material (e.g., a collection of HTML, CSS, and JavaScript® code), underlying site definition data (e.g., using an XML file or JSON representation) that is converted into browser-ready 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 that is invoked by the page to execute on the client, the server, or both).

[0272] 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 FIG. 8, the on-demand system 800 comprises a processor 260, a memory 820 for storing currently or recently served websites, and a persistent storage 830 for storing all websites available for serving. In some embodiments, the on-demand system 800 may also comprise or be associated with a proxy server 840 to help determine whether a new web server execution instance is needed to process a website request.

[0273] The WBS system 100 and the on-demand system 800 store code for editing the website and access the code for processing web requests. The WBS editor 110 is used to present the website's web pages in response to edit requests received from the web development device 140. A web server execution instance is instantiated with code and page definitions created and edited using the WBS editor 110 and stored in the site area database 124 for viewing indexable web pages 125 during editing and at runtime 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 830 may be a database similar to the site area database 124 of the WBS 100. While the WBS100 may store the front end 126 in a structured data format, the on-demand system 800 may convert the front end 126 into a code format understood by the web browser 131 of the web viewing device 130. Unlike the WBS800, the on-demand system 800 typically has read-only access to the stored front end 126 and back end 127 of the indexable web page 125 (when used for runtime servicing of the website). However, when used in conjunction with the WBS editor 110, the on-demand system 800 can modify the front end 126 and / or back end 127 of the website 125, as well as other components of the website 125. The WBS100 editor may also use the on-demand system 800 to modify the front end 126 and / or back end 127 of the website 125 (with the editor code being part of the generic website server code 824). It should be clear that while the editor may work in conjunction with the on-demand system 800, the editor itself may act as a layer above the on-demand system 800 and not directly influence its functions and decisions (e.g., allocation of execution instances to handle incoming requests).

[0274] Processor 260 may be associated with one or more servers hosting elements of on-demand system 800. For example, processor 260 may be associated with a single server or a group of cooperative servers (e.g., a server farm). Additionally, 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 processor 260, each of the elements shown in on-demand system 800 can function both independently and in a cooperative manner.

[0275] Memory 820 may have one or more web server running instances for serving websites or pages to clients. In-use instances 821 may be web server running instances that are currently or actively serving websites. Available instances 822, on the other hand, may be a set of web server instances available in memory 820 that are not currently hosting a particular website but could. In some embodiments, the number of web server running instances in available instances 822 may be a fixed number. In some other embodiments, the number of web server running instances in available instances 822 may vary and depend on the number of web server running instances in in-use instances 821. For example, if there are 10,000 total running instances, an increase in in-use instances 821 may mean a decrease in available instances 822, and vice versa. The number of web server running instances in available instances 822 may also be a percentage of the number of web server running instances in in-use instances 821. In some embodiments, in-use instances 821 may be represented by a data structure that includes unique identifiers identifying web server running instance 823 and other instances currently serving websites. In some embodiments, a similar data structure may be maintained for each website hosted by the on-demand system 800, with all such data structures collectively representing the instances 821 in use.

[0276] Web server execution instance 823 may be one of the active instances 821 that processes requests to a website with the help of a web server. 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. For example, such common code may include underlying web server execution instance system elements (such as an operating system, a web server (e.g., Apache), a database server, etc.). In some embodiments, such common code may also include the WBS100 editor or runtime environment, along with common external services and plug-ins. Additionally, in some embodiments, the common code may include common website application-level server-side elements, such as libraries, and code related to key common items, such as WBS100 vertical applications. 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, the generic code may include actual server-side elements (which may be stored and executed on a server) and client-side elements (which are stored on a server and loaded into a WBS100 runtime client that executes 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 commonly owned group of websites may share a common generic website server code 824. A single website may have its own general website server code 824. This may also apply, for example, to multiple sites based on the same vertical market application framework (e.g., restaurants and hotels). Alternatively, different websites may have their own general website server code 824, which may be associated with all web pages within each website.

[0277] The website N-specific code 834 may include code specific to the website or page served by the web server execution instance 823 (e.g., front-end 126 or back-end 127 code created by the website 126 developer / designer 1540 for a particular site). The web server execution instance 823 may use a web server (e.g., Apache, Tomcat, Nginx, etc.) or a WBS-specific server to serve the website or page containing the website N-specific code 834. The 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, embedding or execution of apps, software-based router functionality, etc. The discussion above and herein refers to website-specific code 834 associated with a given website or page and, correspondingly, a web server execution instance 823 capable of processing incoming requests from clients using the given website or page. However, the on-demand system 800 may be implemented with different levels of specific code granularity. A typical level of granularity may be the site level, i.e., the level at which website-specific code 834 covers an entire site, which is typically the optimal level for reusing web server execution instances 823. However, the system may be implemented using site group (a group of similar sites), entire site, site section (i.e., a set of pages), and single page levels of granularity. In the case of site group, as noted above, the common parts of many sites may also be included in the generic website server code 824.

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

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

[0280] The generic website server code 824 in the first location 831 of the persistent storage 830 is synchronized with the web server running instance 823 after spinning up the instance. In this manner, the generic website server code 824 and any website-specific code 833-834 can be combined to provide a website or page that includes common systems, web frameworks, libraries, components and plug-ins, as well as personalized elements.

[0281] In various embodiments, each of the memory 820, persistent storage 830, and proxy server 840 components may be implemented via an on-premise 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, etc., as well as proprietary cloud networks maintained by website hosting companies.

[0282] Proxy server 840 helps determine whether the set of in-use instances 821 includes a web server execution instance available to process a request for a website generated from web browser 131 of web browsing device 130. 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 in-use instances 821, may poll web server execution instances 823 and 826 to determine their current status, or may receive other report information regarding the availability of web server execution instances. In some embodiments, proxy server 840 may process an HTTP request (e.g., from a client) to access a particular website or page and determine whether the particular website or page is already hosted by web server execution instance 823. Furthermore, in some embodiments, proxy server 840 may maintain a status table 941 for use in determining the status of available instances 822 and in-use instances 821. Such a status table may identify such resources and the websites or pages they already host.

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

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

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

[0286] In step 1020, the on-demand system 800 may store website N-specific code 834 in a second memory location 832 of persistent storage 830. As described above, website N-specific code 834 may be specific to a particular website or web page. Website N-specific code 834 may include, for example, a widget, an app, or custom back-end or front-end functionality. Additionally, website N-specific code 833 may function as a router or the like for a particular website or page, as described above, where one or more segments from a URL entered or otherwise provided by a user determine how that content is 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 received from a web browser 131 on a web browsing device 130. The on-demand system 800 processes requests by checking whether the requested website or page is currently being handled by one or more running web server instances of the in-use instance 821. As mentioned above, this may involve querying the in-use instance 821 itself, querying a proxy server 840, or obtaining a report from another service that monitors the in-use instance 821. The current operation (or lack thereof) of the in-use instance 821 may also be verified by consulting a lookup 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 is tracked and taken into account when determining which server to use to respond to additional requests.

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

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

[0290] In step 1060, a request may be sent to look up website-specific code 833 in secondary storage location 832 that matches the requested website. For example, as shown, if a request for website 1 is received, website 123-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 web server running instance 826. Web server running instance 826 is added to the list of in-use instances 821 and removed from the list of available instances 822 (e.g., in the state table or proxy server 840). The request is responded to (e.g., to the client) by web server running instance 826. Process 1000 may then repeat (e.g., repeat through steps 1010, 1020, or 1030). Further, in step 1060, website-specific code 833 may be injected into web server running instance 826 for incorporation into the construction of the particular website or page requested by the user, as described above.

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

[0292] 11 , in step 1110, on-demand system 800 can receive a request for website 123 over network 160. As described above, the request can come from a client computer or application. The request can be an HTTP request, an HTTPS request, or another type of network request.

[0293] In step 1120, the on-demand system 800 determines how to optimally serve the requested website 123. As described above, the determination may include identifying whether the request can be handled by the current set of in-use instances 821 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 passed a usage threshold (e.g., a threshold number of instances, an amount of bandwidth used, a percentage of bandwidth used, a usage level of server resources such as memory or processor power, etc.). In that case, it may be determined 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 may be made, for example, based on previous load levels. Based on the predicted load levels 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 website group, website, set of pages, or page. The on-demand system 800 may also direct such incoming requests to one of the instances 821 in use (to optimize response time) and, in parallel, decide to spin up one or more available instances 822 so that one or more available instances 822 can be utilized 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 the request (e.g., a copy of the request or information about the request) for the website 123. The request may be a request to access an indexable web page of the website 123, a form submission, or various other types of requests.

[0295] In step 1122, the web server execution instance manager 950 may delegate a decision to the proxy server 840 to help determine how to handle the request to serve the website 123. This may include the types of decision-making described above, including determining the current load status associated with the website 123, predicting the future load of the website, etc.

[0296] In step 1123, the proxy server 840 may consult its status table 941 for an instance of the instance 821 in use that can provide the requested website. In some embodiments, the lookup in the status table 941 may include examining a column in the table called "Website" 1143 for a matching website URL. Other identifiers (e.g., URL, account name, arbitrary name, etc.) are possible. In some embodiments, step 1122 occurs periodically even if the on-demand system 800 has not received a request to provide a website because the on-demand system 800 can periodically monitor load levels based on historical website traffic trends and can automatically spin up or shut down web server running instances unless current traffic trends suggest otherwise. In some embodiments, the on-demand system 800 can periodically monitor load levels based on historical website traffic trends and can automatically spin up or shut down web server running instances unless current traffic trends suggest otherwise. After failing to process the request, manager 950 forwards the request for website 123 indicating that no web server execution instances are available to process the request for website 123.

[0297] In step 1123, proxy server 840 may send the request to the web server execution instances of available instances 822 to select the 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 differences between the web server execution instances 826 that make them more suitable or optimal for processing the request (e.g., geographic location, running applications, available memory, processing power, disk / memory fragmentation level, etc.).

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

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

[0300] In other embodiments, the selection may be based on the geographic proximity of the website 123 to the request location, 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 populated with website 123 specific code 833 and added to the set of in-use instances 821.

[0301] The decision 1120 to process 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 instances that are part of the available instances 822 help reduce the time to spin up an instance when a new website request is made. Thus, the cold start problem of prior conventional website building systems is mitigated.

[0302] In step 1130, the web server execution instance 826 may process the request for the website 123 using the website 123-specific code 833. As described above, serving a website or page generated using the website 123-specific code 833 may tailor the website content to the user or the manner in which the user arrived at the site (e.g., using a software-based router). In some embodiments, the injection step itself may modify the injected material, for example, tailoring the injected material to the particular user / platform / device making the request or other "environmental" conditions (e.g., country, language, database accessed, user access history, etc.). Network The client code initiating the request adds additional parameters or information to the network request to enable the injection module to perform such adaptations. The additional information may be added directly (e.g., as an added URL or other request parameter) or indirectly (e.g., available via an additional request, pre-stored in a database, or other method).

[0303] 12 illustrates an instantiation of server infrastructure elements at a website in accordance with some embodiments of the present disclosure. The techniques of FIG. 12 may be implemented in the systems disclosed above and described throughout this disclosure.

[0304] 12 , a website 123 may be served through a web server execution instance by copying website 123-specific code 833 into 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 front end 126, a back end 127, and plug-in reference code 1226, as described above in connection with customized back-end functionality that may be provided in a website. In some embodiments, the front end 126, the back end 127, and the plug-in reference code 1226 may be individually copied into the container 1221, the virtual machine 1222, or the process 1223. In some embodiments, the generic website server code 824 may be copied into the container 1221 or the virtual machine 1222 (which subsequently includes the website 123-specific code 833) as part of the instantiation of the web server execution instance 826.

[0305] In some embodiments, use of the on-demand system 800, such as through the implementation of serverless code, can improve processing time and server utilization while reducing user wait times. In serverless code embodiments, there are no dedicated servers to manage. Instead, code (e.g., the front end 126, back end 126, and plug-in reference code 1226) can be provided as code in the cloud and executed on demand. To the extent that users are charged for code execution, they can be charged proportionally to the actual execution of the code (rather than 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 allowing them to provide better service to users. In some embodiments, the on-demand system 800 can define a set of programming languages ​​or web frameworks that it supports for processing serverless code. The on-demand system 800 may also support WebSockets, streaming or chunked communication, additional protocols (e.g., TCP and UDP), memory-as-a-service functionality (e.g., for stateless, side-effect-free code functions), and native serverless options (e.g., Go, Rust, C, etc.). The ability to process serverless code on-demand alleviates issues with traditional website hosting systems (e.g., undergoing a "cold start" to load a machine or website instance). Startup times for websites or pages (including running code) can be less than 100 milliseconds, thereby reducing latency and improving the user experience. In contrast, some traditional systems experience website or page start times of approximately 600 milliseconds to 2 seconds, including scheduling overhead, instance startup, process launch (e.g., code execution), and request handler functionality.

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

[0307] 13 illustrates techniques for load monitoring of hosted websites and management of in-use instances 821 according to some embodiments of the present disclosure. These techniques may be performed in the system as described above.

[0308] As shown in FIG. 13, the web server execution instance manager 950 (as described above in connection with FIG. 11) monitors or communicates with the load monitor 1310 to determine whether the load on any of the websites served by the on-demand system 800 is greater than the desired or planned load. As described above, this may be determined based on current, previous, or future load characteristics. In some embodiments, future load may be predicted based on prior knowledge based on historical collected periodic load of the web server hosting the website / websites. Historical load may include monthly, weekly, daily, and hourly loads to account for seasonal trends and other periods when site usage is most active, allowing for the automatic addition of more web server execution instances serving a particular website or group of websites served by the web server.

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

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

[0311] The load monitor 1310 load table may be updated directly by the web server execution instance manager 950 or may request an update from the proxy server 840. In some embodiments, the load monitor 1310 load table may be updated by the on-demand system 8 The load table of the load monitor 1310 is periodically updated by the proxy server 840 based on the number of access requests for the website 1311 hosted by the proxy server 840. The load table of the load monitor 1310 may be updated based on usage statistics of other websites. For example, for a multimedia-heavy website, usage statistics may include the amount of memory and processor cycles used to process website requests, including converting video and audio to different formats based on the environment of the device used by the user. Web server execution instances in the in-use instances 821 are moved to available instances 822 when the load of the website they are hosting becomes lighter. Similarly, when the load of a website becomes heavy, the web server execution instances in the available instances 822 are marked as in-use instances 821, and website-specific code for the website with the heavier load is injected into these web server execution instances.

[0312] In some embodiments, based on proxy server 840 observing that website 123 is lightly loaded, on-demand system 800 may move web server execution instance 826 from the set of website 123 assigned instances 1320 to the set of available instances 822. In some embodiments, web server execution instance 1323 is moved to available instances 822. In some embodiments, multiple web server execution instances are simultaneously moved to available instances 822. If proxy server 840 observes via load monitor 1310 that website 2 is heavily loaded, it may move web server execution instance 1127 from the set of available instances 822 to the set of website 2 assigned instances 1330. As part of step 1342, website 2 may have site-specific or page-specific code injected into web server execution instance M 1127 before moving it to website 2 assigned instances 1330. Of course, steps 1341 and 1342 are independent and need not occur together or in any particular order.

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

[0314] In some embodiments, the web server execution instance manager 950 may wait a 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 a period of time before shutting down an available instance to ensure that website-specific code does not need to be injected into the instance to handle new website requests. Shutting down and spinning up instances can be a time-consuming process, and the website execution instance manager 150 avoids doing it too often 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 when the current number of instances in the set of available instances 822 differs from the threshold by a specified number or percentage. This allows a range of values ​​for the number of available instances 822 to exist at any time. In other embodiments, the web server execution instance manager 850 can spin up and shut down instances in immediate response to deviations from the threshold.

[0316] 15 illustrates an exemplary website real-time testing system according to some embodiments of the present disclosure. As shown in FIG. 15, website real-time testing system 1500 includes processor 260, memory 820, site area database 124 for storing data used by the website, and deployment environment 1510 for providing access to data related to the website being accessed. In some embodiments, website real-time testing system 1500 may also include test environment 1520 for providing access to data related to the website being accessed for testing purposes. Alternative terms such as development / runtime, staging / production, and test / live may be used for the terms test / deploy.

[0317] In some embodiments, on-demand system 800 may be a subsystem that is included entirely within website real-time testing system 1500. In some embodiments, website real-time testing system 1500 may be partially composed of or include on-demand system 800.

[0318] The deployment environment 1510 may be a set of software components running on a web server execution instance of the on-demand system 800 .

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

[0320] End users 1530 can access websites and their data in deployment environment 1510 via network 160. In some embodiments, end users 1530 may access websites 123 via web browsers 131 on website viewing devices 130, consistent with the embodiments described above.

[0321] The developer / designer 1540 can access the test environment 1520 via the network 160. The website and its data can be accessed by a developer / designer 1540 via a web browser 141 on a 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 can 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 deployment environment 1510 or test environment 1520 based on whether the user is an end user 1530 or a developer / designer 1540, respectively. Also, the website may be accessed using deployment environment 1510 or test environment 1520 based on whether the request is from website browsing device 130 or website development device 140. In some embodiments, the website may be accessed using deployment environment 1510 or test environment 1520 based on a combination of user and device type.

[0323] FIG. 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 FIG. 16a, the deployment environment 1510 may request the processor 260 to assist in accessing live data 1610. The deployment environment 1510 does not have access to test data 1620, which is shown in dashed lines. FIG. 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 FIG. 16b, the test environment 1520 can request the processor 260 to assist in accessing the live data 1610 and the test data 1620. A developer / designer 1540 accessing a website 123 using the test environment 1520 can request data elements associated with indexable web pages 125 of the website 123. The test environment 1520 can be configured to receive requests for data elements from users and forward the requests to the test data 1620. In some embodiments, test data 1620 may determine whether the requested data element is present in test data 1620 or may forward the request to live data 1610. In some embodiments, test environment 1520 itself may determine whether to request live data 1610 or test data 1620 for a particular data element. In some embodiments, test environment 1520 can access live data 1610 and test data 1620 after copying live data 1610 and test data 1620 to memory 820.

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

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

[0326] 18 illustrates the generation of test data used in test environment 1520 for testing websites, according to some embodiments of the present disclosure. As shown in FIG. 18, live data 1610 forms part of test data 1620. In some embodiments, the order of adding data marked as inserted 1730 and data marked as deleted 1740 may be different. Data marked as inserted 1730 and data marked as deleted 1740 may be traversed in parallel to avoid adding data to test data 1620 and then deleting that data in data marked as deleted 1740.

[0327] The data marked as inserted 1730 and the data marked as deleted 1740 may be retained in the site area database 124. In some embodiments, the data marked as inserted 1730 and the data marked as deleted 1740 may be placed in memory 920 until a session accessing the website 123 in the test environment 1520 becomes active. Once the session becomes inactive, the data marked as inserted 1730 and the data marked as deleted 1740 may be retained in the site area database 124. For example, the developer / designer 1540 can explicitly request that the data marked as inserted 1730 and the data marked as deleted 1740 be retained in the site area database 124. In some embodiments, the data marked as inserted 1730 and the data marked as deleted 1740 may share the same location in the site area database 124. The data marked as inserted 1730 and the data marked as deleted 1740 may be retained based on the number of read requests. Data elements in data 1730 marked as inserted may be selectively retained in 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, or the length of time a data element has not been changed, or the number of sessions the data has been accessed.

[0328] FIG. 19 is a flow chart illustrating a method 1900 for accessing 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 accessing the website in the deployment environment 1510 are stored in the live data 1610 of the site area database 124 .

[0330] In step 1920, live data 1610 stored in site area database 124 associated with indexable web pages of a website accessed in deployment environment 1510 is accessed by 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 the associated indexable web page to render the web page in the web browser 131 of the web browsing device 130 used by the end user 1530 .

[0332] FIG. 20 illustrates a sample of a user accessing a website in a test environment, according to some embodiments of the present disclosure. 2 is a flowchart illustrating a method 2000.

[0333] In step 2010, the website real-time testing system 1500 may receive a request to run 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 a data request made as part of the process of testing a website using the test environment 1520. For example, the website 123 may be tested by a developer / designer 1540 by accessing the website 123 using a web browser 141 of a website development device 140. For example, the developer / designer 1540 may enter a URL to request an indexable web page 125 of the website 123. Further, in some embodiments, the URL may be specified by an application. The request includes both a request to the front end 126 and a request for a data element of the data group 210 associated with the indexable web page 125 of the website 123. A request to read data may be made as part of the process of accessing the web page.

[0334] As shown in FIG. 20 , in step 2030, the website real-time testing system 1500 checks whether the test is complete. In some embodiments, testing of a website is considered complete if the website is accessed via 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 the developer / designer 1540 accessing 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 may apply the changes made to the data elements and saved in test data 1620 to the corresponding data elements in live data 1610. Step 2040 may be optional because developer / designer 1540 may, for example, request that data changes incorporated into test data 1620 be dropped.

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

[0336] 21 is a flowchart illustrating a method 2100 for processing a data request in a test environment 1520 according to some embodiments of the present disclosure. The method 2100 of FIG. 21 identifies one of five example paths for processing an incoming request for a data element associated with a website being accessed by a developer / designer 1540.

[0337] 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 a website for testing in the test environment 1520. For example, a developer / designer 1540 accessing a website 123 via a website development device 140 may provide a request for a data element 211 of a data group 210 associated with the website 123.

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

[0339] In step 2121, the data request is determined in step 2120 by the website real-time testing system 1500 to be to search for a data element associated with the website being tested by the developer / designer 1540 or to view the results of such a search operation.

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

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

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

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

[0344] 22 is a flowchart illustrating a method 2200 for processing a read request in a test environment in accordance with some embodiments of the present disclosure. The method 2200 of FIG. 22 identifies three paths to determine whether a data request needs to be responded to, and if so, which data element from the test data 1620 or the live data 1610 to use.

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

[0346] In step 2210, website real-time testing system 1500 looks up the requested data element in test data 1620 and, if a match is found, checks whether it has been 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 2200, a "data element not found" message is not returned. For example, if indexable web page 122 of website 123 A developer / designer 1540 accessing 5 can send a request for a data element 1741 in data 1740 marked as deleted in test data 1620 and receive a "data element not found" message.

[0347] If the answer to step 2210 is no, then the method 2100 may proceed to step 2130. As shown in FIG. 22 , in step 2230, the website real-time testing system 1500 looks up the requested data element in the data marked as inserted 1730 of the test data 1620.

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

[0349] If the answer at step 2230 is no, then the method 2200 may proceed to step 2250. At step 2250, the requested data element is returned from Live Data 1610.

[0350] 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 of FIG. 23a defines where to store updated data elements requested during testing of a website.

[0351] As shown in FIG. 23 a, in step 2124, the method 2100 determines that the received data request is a request to update a data element present in the live data 1610 or the data marked as inserted 1730 of the test data 1620 during testing of the website.

[0352] In step 2310, the website real-time testing system 1500 determines the location of the data element for which an update is requested by first checking in the data 1730 marked as inserted in the test data 1620.

[0353] If the answer to step 2310 is yes, then the method 2200 proceeds to step 2320. In step 2320, the data elements corresponding to those for which an update is requested are updated.

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

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

[0356] 23b is a flow chart illustrating another method 2300 for updating data elements in a deployment environment 1510 according to some embodiments of the present disclosure. The method ensures that live data 1610 is available in real time to developers / designers 1540 who test websites using a test environment 1520.

[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 live data 1610 are updated according to the request.

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

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

[0361] If the answer at step 2370 is yes, method 2300 proceeds to step 2390. At step 2390, the data elements requested to be updated via deployment environment 1510 are updated in data marked as deleted 1740. This prevents the data elements updated in live data 1610 from being included in query results, as described in process 2500 below.

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

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

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

[0365] FIG. 24 illustrates deleting a data element from a test environment in accordance with some embodiments of the present disclosure. 24 is a flowchart illustrating a method 2400 for deleting a data element that has been requested to be deleted. As shown in FIG. 24, the data element that has been requested to be deleted may be present in the live data 1610 or may have been previously added via a test environment and is present in the data marked as inserted 1730.

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

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

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

[0369] If the answer to step 2420 is yes, then method 2400 has found the data element requested for deletion in the data marked as inserted 1730. In step 2440, the data element in test data 1620 is removed from the data marked as inserted 1730.

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

[0371] 25, in step 1, data elements matching the query are accessed from live data 1610, data marked as inserted 1730, and data marked as deleted 1740. In some embodiments, the data elements are accessed by running a query in site area database 124 against live data 1610 and data marked as inserted 1730 and data marked as deleted 1740 of test data 1620. In some embodiments, the results of the query may be organized into 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, If so, a random column is selected and sorted in ascending or descending order. In some embodiments, the primary key is added to the columns used for sorting.

[0373] In step 2, the system simultaneously traverses data elements in live data 1610, data marked as inserted 1730, and data marked as deleted 1740 to select 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 at the youngest data element based on column "B." The youngest current records in live data 1610, data marked as inserted 1730, and data marked as deleted 1740 are compared to identify the youngest data element. The youngest that can be found may exist in multiple places. For example, data elements 2520 and 2530 are the youngest data elements in 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 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 inclusion 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 deletion of the data element was previously requested in test environment 1520 during testing of the website. It may also have been updated, with data element 2560 being the resulting updated element.

[0376] If a data element exists only in live data 1610, 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 is only present in data marked as inserted 1730, it is included in test data 1620. For example, data element 2540 is only present in data marked as deleted 1740, indicating that it was inserted as a new data element or as part of an update to data element 2520 during testing of the website.

[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 for live data 1610 and data marked as deleted 1740 are moved to the next record after the first iteration of the traversal.

[0379] Once the last data element for all three sources of data elements has been reached, method 2500 ends and test data 1620 is obtained. Fusion table 2560 shows the youngest data elements identified in each iteration of step 2 described above. Only the source with the youngest data element is filled in and displayed, while 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, i.e., live data 1610 and data marked as deleted 1740, and data marked as deleted 1740 is empty, indicating that it did not have a youngest data element. Similarly, in the final iteration, only data marked as inserted 1730 is shown in the last row of fusion table 2560. The youngest data element is 2550.

[0380] 26 shows a flowchart illustrating steps of a method 2600 for editing a database during a website preview, according to some embodiments of the present disclosure. The method 2600 may be implemented in a system environment described throughout this disclosure, such as in FIGS. 1, 2, and 15.

[0381] As shown in FIG. 26 , step 2602 may include receiving one or more groups of data elements (e.g., from a user of the website building system). The data elements may include various different types of content or records of content that can be incorporated into a website, such as text, images, video, advertisements, database output displays, etc., as described above. In some embodiments, the data elements 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 a related set of one or more elements. 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 piece of 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 to be displayed on or associated with individual web pages of a website or a given virtual page template via the website editing interface.

[0382] Data groups, in some embodiments, can be site-level entities that can be used and reused across multiple pages of a website, or owner-level entities that can be used and reused by a particular website owner. Additionally, data groups can also be system-level entities (e.g., databases of zip codes, geographic area descriptions, etc.) or page-level entities.

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

[0384] Additionally, method 2600 may include a step 2606 of generating one or more virtual web pages. Each virtual web page may represent data elements (composed of one or more objects) that may be displayed in a preview mode (during development) before the actual website or updated portions thereof go live (i.e., become viewable to other users over the Internet). To then publish the virtual web page collection in live mode, a user may select an option titled "Publish," "Post," or the like, which makes the website viewable over the Internet (as publishing typically occurs at the site level rather than a single page). Once published, the virtual pages (i.e., instances derived from web page template 2704) may behave similarly to ordinary (real) pages, despite being dynamically generated. Some In embodiments, each of the actual web pages is not designed with the ability to update a database, but the virtual web pages may be designed with that ability. As an example, a hotel booking site may maintain five different virtual page templates for five different types of rooms (single bed, double bed, etc.) available at a particular hotel. Each of the virtual page templates may be associated with its own data element group (i.e., records for a given type of room), and thus each room may have a virtual web page that may be viewable and editable as a virtual web page during preview mode.

[0385] Further, method 2600 may include step 2608 of displaying each group of at least one data element on a separate one of the set of virtual web pages. For example, in the hypothetical hotel website above, during preview mode, five virtual web page templates corresponding to different types of rooms in the hotel may each have an associated group of data elements (e.g., different text describing the room, an image of the room, a video of the room, etc.). The generated set of virtual web pages (i.e., instances) may be displayed to a user via a browser or other client, as described above in connection with other techniques.

[0386] Method 2600 may also include step 2610, which includes displaying editing tools that allow a user to edit one or more of the virtual web page templates and instances. Templates may be edited as if they were normal pages. Instances may be editable only in preview mode, as they may not be displayed as part of the normal editor page viewing and editing process. In an alternative embodiment, the system allows instances to be edited as part of the normal site editing process. Various editing tools may be used, including 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, incorporating 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), software-based routers (e.g., for creating different versions of a web page based on elements of the URL used to access it), and the like. The system can display (and operate) different subsets of the editing tools available for templates and instances, and can customize the displayed editing tool subset depending on the user, the virtual page template, the particular instance, the underlying connected data groups or elements, etc. As described further below, users can edit virtual web page templates and instances via the editing tools, and the edits can be translated into edits to a database that maintains component information and / or content for the web pages.

[0387] Method 2600 may also include step 2612 of associating a unique URL with each virtual web page. 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.). Additionally, in some cases, the URLs associated with the virtual web pages may have different path (referencing files or directories) or parameter values. In some embodiments, a software-based router may be configured for the website or individual web pages. The software-based router may, for example, be configured to associate a particular URL prefix, path, segment, or parameter with a particular web page. Configurable. Each web page 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 web page can be associated with an object that contains information about the request (e.g., the URL, where it came from, who it came from, etc.). A software-based router can process this information and determine which web page (or possibly a virtual web page) to display and which data elements to include.

[0388] Additionally, method 2600 may include step 2614 of displaying user-selectable features (e.g., buttons, scroll bars, links, etc.) that allow the user to navigate through the virtual web pages to individually and dynamically display each of the virtual web pages. Thus, in the above example, the user-selectable features would allow the user to view each of a set of five web pages corresponding to different room types in the hotel, with each page dynamically selected and viewed as a virtual web page.

[0389] Method 2600 may further include step 2616 of receiving edits to one or more virtual web page attributes from a user. For example, using the editing tools described above, a user may change the background of the page, the layout or template of the page, apps or widgets incorporated into 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 web page template 2704 may be written directly to the template page definition in the site area database 124. Changes made to the virtual page instance may be stored in a separate database, which includes adaptations to the virtual page instance. In such a scheme, the adaptations are indexed by a unique index for the particular virtual page instance (e.g., "Single Bedroom #1234" in the hotel example above). Each time this virtual page instance is generated for display (e.g., during preview or live display), the adaptations are retrieved and reapplied.

[0390] In some embodiments, a user is 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, a user may be prohibited from editing other elements (i.e., non-content) of the virtual page instance, including layout, attributes, etc.

[0391] Method 2600 may also include step 2618 of receiving edits to the data elements themselves. 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 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 displayed virtual page instance (in preview mode) (such as a "select another image" button added to each displayed image derived from the data group). As described above, the data elements may be stored in a database. Edits may include editing text, replacing or modifying images, replacing or modifying video, changing the functionality of hovering a cursor over an element, and various other types of edits.

[0392] Additionally, method 2600 may include receiving 2620 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 connection with FIGS. 1-7. For example, the code may be , collecting and storing data and content in databases, creating dynamic pages, implementing user-facing widgets and apps, repeating layouts of data elements, configuring software-based routers, etc. In some embodiments, in step 2622, skeleton code segments may be generated to facilitate user edits to the code associated with the web page. For example, the skeleton code may be a high-level abstraction of functionality associated with finer-grained source code, which may implement the various types of front-end and back-end functionality described above for the web page. The skeleton code may be displayed to the user via an editing interface, allowing the user to edit it. User edits to the skeleton code may then be translated into edits to 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 edits to the web page template 2704 (which may be stored in the site area database 124 and subject to sandboxing for development changes before publication) or virtual page instances (which may be stored in the virtual page instance adaptation database). This is described in more detail below in the discussion of steps 2630 and 2634.

[0393] In method 2600, step 2624 allows the user to select a particular virtual web page, and step 2626 allows the user to navigate through the virtual web pages. For example, the user can select pages individually by clicking hyperlinks or other links associated with images or visual representations of the pages, or can visually navigate through the pages (e.g., left / right or up / down toggle buttons or other selection visualizations).

[0394] According to method 2600, any edits to the virtual web page (e.g., edits of an instance via step 2616 or 2618) may be converted in step 2828 into updates to a database that maintains data elements for the web page. For example, if a user replaces an image on the virtual web page with another image (e.g., an image uploaded by the user), the new image may be stored in the database. Additionally, if a user replaces text on the virtual web page (e.g., a description of a particular hotel room), the updated text may also be stored in the database. In some embodiments, updates to the database may be performed automatically based on the user's edits to the virtual web page. Because the database is used to construct the virtual web page and is associated with the content of the virtual web page, edits to the virtual web page may be associated back to the database used to construct them. In some embodiments, multiple versions of the database are at least temporarily stored so that a user can perform an undo or undo operation if they want to reverse changes to the virtual web page and revert to a previous version. For example, the user may select an undo or undo option, or may provide a timestamp or version identifier associated with a previous version of the virtual web page to which they can revert or resume edits. Such version control systems may also support changes to versions of the development database that are not part of the published version until a publish operation is performed, also known as "sandboxing" the development database.

[0395] Method 2600 may also include step 2630, in which edits made by a user to the skeleton code are received. Further, 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 may edit the actual code or skeleton code associated with various back-end or front-end functions of the virtual web page. Such edits to the code may be stored in the same database that hosts the data elements of the virtual web page or in a separate code database.

[0396] Additionally, in step 2632, method 2600 may include enabling 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 a 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 both template and instance preview modes. Such edits are translated into corresponding updates to the page definition or data element changes, which may be stored in site area database 124 and / or a separate database (e.g., a data element database, an instance adaptation 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., the site area database 124 and other databases such as data element databases, instance adaptation databases, or separate front-end / back-end code databases) may be implemented as a single database, a set of databases, or a combination of databases (each of which may support a subset of the required functionality).

[0397] FIG. 27 illustrates a system 2700 for developing and previewing web pages, according to some embodiments of the present disclosure. As mentioned above, the system 2700 may be similar to or operate within the systems described in connection with FIGS. 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, multiple web pages 2704 may be maintained, each of which may have its own corresponding data elements. As mentioned above, the data elements may be organized into one or more data groups 210 of data elements. As mentioned 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 FIG. 27 , the site area database 124 can communicate with a web browser 131 or other client application over a network, which can be operated by a user. The web browser 131 can use the data elements in the data group 210 to display a virtual web page 2712 corresponding to each web page template 2704 in the site area database 124. Furthermore, each virtual web page 2712 can be associated with a data element 211. Furthermore, a user can have a separate display of the data elements (e.g., data element 1 211 and data element 2 2718) as part of the data element group 2714. As described above, a user can interact with the displayed virtual web page 2712, including its elements 2710, 2714, 211, 2718, to edit various features of the virtual web page 2712. Edits can include specific data elements, page structure features, front-end code, back-end code, etc. As described above, such edits can be received by the site area database 124 and / or other databases.

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

[0400] 29 is a timeline display 2900 of dynamic refreshing of a web page, according to some embodiments of the present disclosure. In particular, as a user edits virtual web page 2712, the edits may be refreshed in site area database 124 and therefore in the user's browser. As shown in FIG. 29, data group 2710 may include, among other data elements, data element 1 211 and data element 2 2718. Within data element 1 211, tab 1 2902 may be displayed, and within data element 2 2718, test tab 2 2904 may be displayed. Tab 1 2902 and test tab 2 2904 may be displayed on virtual web page 2712 along with other elements (e.g., a search bar, a drop-down menu, etc.) as shown.

[0401] As time progresses in the timeline display 2900, a user can edit the virtual web page 2712. For example, as shown, the user can edit test tab 2 2904 to create edited tab 2. Additionally, a new data element 3 2906 can be added to the virtual web page 2712 as part of the data group 2710. As edits are made to the virtual web page 2712, corresponding edits can be made in the live environment 2908. For example, when the user selects a "Publish" or "Render" function, the live environment 2908 can be updated to show updates to the data group 2710 and other aspects of the virtual web page 2712. For example, an initial version of the actual web page 2910 may not include edited tab 2 or tab 3, but subsequent versions of the actual web page 2912 may include these updates. In various embodiments, updates to the virtual web page 2712 can occur automatically or when a user selects a refresh or update function. Additionally, 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 (eg, by selecting a "Publish" or "Render" link).

[0402] 30 shows a block diagram of a dynamic preview system 3000 according to some embodiments of the present disclosure. As shown in FIG. 30, the dynamic preview system 3000 serves to display a web page as it appears in, for example, the 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 the web browser being used to display the online editor interface 243.

[0403] The preview interface 3010 can be used to preview static web pages and virtual web pages (i.e. The preview interface 3010 may be used to display both the virtual web page template 2704 and the virtual web page template 2706 (i.e., an instance of a given web page template 2704). The virtual web pages generated for viewing in the preview interface 3010 may be accompanied by a navigation interface 242. The preview interface 3010 may enable the navigation interface 242 to include a scrollable feature, allowing a user to scroll through multiple virtual web pages generated for viewing in the preview interface 3010. The navigation interface 242 may enable both sequential navigation and direct access to a specific virtual web page, as well as navigation between virtual pages by search (e.g., by using the value of a key data item used to identify a particular virtual page). The navigation interface 242 may provide direct access to a specific virtual web page and may support bookmarked virtual web pages for selective viewing. For example, a virtual web page displayed in the preview interface 3010 may be accompanied by links to the first, last, previous, or next virtual web page. The WBS 100 may also support other organizations of virtual pages beyond just a linear organization. For example, WBS100 may support a hierarchical organization of virtual pages that may be navigated using additional options such as "go up a level in the tree" or "expand a level below the current page."

[0404] FIG. 31 illustrates a preview of a virtual web page 3110 being edited, according to some embodiments of the present disclosure. As shown in FIG. 31 , a front end 126 is associated with a data group 210. The construction tools 121 included in the front end 126 may be associated with particular data elements of the data group 210. The virtual web page 3110 may display an indexable web page 125 that includes the front end 126 and may be previewed in a preview interface 3010. In some embodiments, the preview interface 3010 may be a frame or other graphical representation within the online editor interface 243. The preview interface 3010 may allow previewing the virtual web page 3110 as it would appear on a variety of mobile and desktop devices, using different languages, adapted to accessibility requirements, or modified in some way for a particular audience.

[0405] FIG. 32 is a schematic diagram illustrating the relationship between data groups and websites, according to some embodiments of the present disclosure. As shown in FIG. 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 that share a set of data groups 3230 may have the same owner or operator, or may otherwise be granted appropriate permissions (via access control mechanisms) to access a particular data group 210. In some embodiments, a group of websites 3240 that share a set of data groups 3230 may be built by the same developer / designer 1540, as described above.

[0406] 32, the repeater 3213 is a building tool that appears on the front end of a web page, displaying different content items or groups in different sections of a repeating design or layout. In some embodiments, the repeater 3213 may be part of a virtual web page 3111 generated using a software-based router, as described further herein, or may be 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 the data group 210. Repeaters can be directly associated with data group subsets 3213 of data groups 210. For example, repeaters can be used to create five different groups of text and images. Each group can automatically arrange the text and images with the same proportions and layout. Nevertheless, in some embodiments, the actual content of the text and images can be different in each group.

[0407] FIG. 33 is a schematic diagram illustrating components involved in generating a virtual web page according to some embodiments of the present disclosure. As shown in FIG. 33, a web page template 2704 can be associated with data group 210 and other data groups, similar to indexable web pages. As described above, a software-based router 3310 can be used to bind data elements within data group 210 and applied to web page template 2704 to generate virtual web pages 3111, 3313, and 3312. The software-based router 3310 can select / filter / sort data elements within data group 210 to apply to web page template 2704 and virtual web page groups based on the URL submitted by the user. The software-based router 3310 identifies the web page template 2704 based on a URL prefix. The software-based router 3310 may identify data elements from data group 210 to apply to web page template 2704 to generate a virtual web page based on the 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 to the web page template 2704. The software-based router 3310 can generate virtual web pages 3111 and 3312 based on the suffix values ​​"label1" and "label2," respectively. The software-based router 3310 can generate a site map prefix1 site map 3313 that lists the possible URLs of all virtual web pages that can be generated using the web page template 2704 and associated data groups 210, as well as other data groups. The prefix1 site map 3313 can help index the virtual web pages 3111 and 3312 by the search engine 170.

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

[0409] 34, in step 3410, the dynamic preview system 3000 can store the data elements in the site area database 124. As mentioned above, the data elements can take a variety of different forms, such as text, images, videos, backgrounds, and records comprised of any combination of these object types.

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

[0411] In step 3430, the dynamic preview system 3000 performs the following steps to add additional data elements to the 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 manner, an existing group can be supplemented or edited to include different or additional elements. The user can repeat step 3420, returning at any time to add more data elements. Similarly, this step can include instructions for performing additional operations on the data elements, such as deleting or updating. For example, the user can cycle between steps 3410, 3420, and 3430, or can proceed to step 3430.

[0412] In step 3440, the dynamic preview system 3000 may execute instructions that assist in associating 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, returning at any time to create further associations between web pages of the website being constructed and 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 assist in associating the data element groups with web pages of the website. This may include linking form fields to each other, as described above, to both activate / deactivate and filter the potential values ​​allowed in the fields (e.g., a form for entering an address may list "city" field values ​​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 constructed 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 includes a hosting server 3510 that includes one or more systems for building and displaying websites, a plug-in server 3520 that executes plug-in code, a processor 260, a memory 820 that stores plug-in components and code, and an interface 3570 for developing and uploading plug-in code and other components.

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

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

[0419] Plugin server 3520 may be one or more servers that execute plug-in code in isolation environment 3521. In some embodiments, plug-in server 3520 uses the same infrastructure as hosting server 3510 (which may be a physical server or a web server running instance as described above). Plugins 3530 reside in memory 820 and may be displayed or accessed via user interface 3531, front-end plug-in code 3532, and back-end plug-in code 3533.

[0420] Users 3540-3560 can access editing tool 411 from hosting server 3510 to edit websites 3511-3513, respectively. In some embodiments, for example, website 3511 being edited by user 3540 can include plug-in 3530. For example, website 3511 can play videos via video player plug-in 3530 when website 3511 is accessed using web browser 131 of web browsing device 130. User 3540's modifications to website 3511 can include editing and uploading plug-in code via interface 3570. In some embodiments, interface 3570 can be part of editing tool 411.

[0421] Users 3540-3560 interact with websites 3511-13 on hosting server 3510 through shared platform 3580. Shared platform 3580 allows groups of users to edit groups of websites. Shared platform 3580 may be software configured to determine which groups of users 3540-3560 have access to edit which websites 3511-13. In some embodiments, hosting server 3510, which hosts multiple websites 3511-13, may itself function as shared platform 3580.

[0422] An end user's 1530 browsing of a website 3511 using a web browser 131 on a web browsing device 130 may include a user interface 3531 of a plug-in 3530. For example, the plug-in 3530 may be a video player, and the user interface 3531 may include playback control buttons stylized for the video player plug-in 3530. Front-end plug-in code 3532 may also be passed through the user interface 3531 when the end user 3540 accesses the website. The end user's 1530 interaction with the user interface 3531 of the plug-in 3530 may result in the front-end plug-in code 3532 of the plug-in 3530 being executed in the web browser 131. In some embodiments, the end user's 1530 interaction with the website 3511 may also cause back-end plug-in code 3533 to be executed in the plug-in server 3520. For example, when an end user 3540 clicks the playback control of a video player plug-in, the front-end plug-in code 3532 executes to request streaming of the video, and the back-end plug-in code 3533 may further compress the video based on network bandwidth availability.

[0423] Figure 36 illustrates a technique for controlled access to co-hosted websites according to some embodiments of the present disclosure. As shown in Figure 36, users 3540, 3550 are grouped together and allowed access to co-host 1 websites 3511 and 3512. Users 3621 and 3622 may have access to co-host 2 websites 3611 and 3612. The users may have access to one or more co-hosted websites. Users may have access to websites that are not part of an authorized group, but are not permitted to access those websites. Users may have access rights defined based on, for example, whether they are the owner of a particular website, whether they are a registered user, whether they are authenticated, etc.

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

[0425] FIG. 39 illustrates controlled access and execution of front-end plug-in code 3532 according to some embodiments of the present disclosure. As shown in FIG. 39, access to website 3511 provides access to front-end plug-in 1 code 3532 of plug-in 3530 and front-end plug-in 2 code 3931 of another plug-in. Website 3511 may ensure execution of each of the plug-ins in their respective separate sub-areas 3910 and 3930. Website hosting system 3500 may also create a secure communication channel (e.g., SSL, secure tunnel, etc.) to allow access only to specific other sub-areas of the website. The secure communication channel may restrict a front-end plug-in's access to other sub-areas of the website. For example, front-end plug-in 1 code 3532 executing in sub-area 3910 may be able to communicate with another sub-area 3920 but may be denied access to sub-area 3940. A plug-in's accessible sub-areas may be listed in a tabular format, trusted registry, configuration file, or secure database. For example, in a cloud computing-based configuration, a cloud orchestrator platform may maintain a list or mapping of virtual computing resources (e.g., subarea 3910, subarea 3920, subarea 3940, etc.) and define their connection permissions. Such a list or mapping may allow certain connections or actions by subarea 3910, subarea 3920, and subarea 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). By enabling a hub to communicate with a system client, a system server, or both, a secure communication channel is provided. Such a hub may reside, for example, on a system client, a system server, or both. Secure communication may also be established by checking the unique identifier of the sub-region initiating the communication. For example, a getId() method call may be used to identify the originating sub-region ID of a communication message and determine whether it is included in an allowed list or mapping.

[0426] FIG. 40 illustrates client-side, isolated execution of plug-in code according to some embodiments of the present disclosure. As shown in FIG. 40, a website 3511 accessed by an end user 1530 using a web browser 131 may provide access to front-end plug-in code 3532 of a plug-in 3530. The end user 1530 access may result in the creation of an iframe for the front-end plug-in code 3532 to run independently. In some embodiments, the front-end plug-in code 3532 may be copied to different subareas 3712-3713 of the website 3511 for independent execution. For example, the website 3511 may display multiple video players, each streaming a different video stream but using the same plug-in code. In some embodiments, the plug-in code 3532-3533 executing 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 website and plug-in code according to some embodiments of the present disclosure. As shown in Figure 41, in step 4110, the website hosting system 3500 hosts websites that share one or more common data elements, templates, portions of code, routes, or other functionality within a common host server or set of servers. Servers may also be co-hosted based on the ownership or administrative and editing privileges of multiple users. For example, the website hosting system 3500 may host websites created and managed by multiple independent, unaffiliated entities or individuals.

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

[0429] In step 4130, a user's attempt to access a website for editing purposes causes the web hosting system 3500 to evaluate whether the requesting user has access or privileges to edit the website. The evaluation may depend on the ownership of the particular website. In some embodiments, a website owner or administrator can provide administrative and / or editing access to other users using the editing tools 411. Furthermore, in some embodiments, editing rights may depend on whether the user is a registered user or is authenticated to access the web hosting system 3500.

[0430] If the answer to step 4130 is "no," the requested access to the website may be denied and the user may need to request editing privileges from the website's administrator. Process 4100 is considered complete if access to edit the website cannot be 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 a plugin is presented to the user requesting access to edit the website. The interface may be similar to the interface described above for a user editing front-end or back-end code.

[0432] In step 4160, the website hosting system 3500 receives and stores the plugin changes. User-uploaded plugins may include, for example, edits to the backend plugin code 3533 of the plugin 3530. In some embodiments, the user edits may include edits to the frontend plugin code 3532 of the plugin 3530. Alternatively, the user may also edit the user interface 3531 of the 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] A user editing plug-in code (eg, front-end plug-in code 3532 or back-end plug-in code 3533) may edit the plug-in code over multiple sessions, allowing for repetition of steps 4120-4160, as well as fewer or more steps.

[0434] In step 4170, the web hosting system 3500 executes the plug-in 3530 when the website 3511 is accessed by a user (e.g., end user 1530, 3540, 3550, 3560). Execution of the plug-in code includes creation of an isolation environment 3521 for executing the code. The isolation environment 3521 may include separation of the client and server sides of a web browser for executing the front-end 3532 and back-end 3533 plug-in code 3530, respectively.

[0435] 42 is an exemplary user interface 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 offered by WIX.COM. As shown, 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 configuring the website, such as listings of various pages (e.g., Home, Colleges, Events, Scholarships, Student Area, Courses by Degree, and News), as well as options for public, back-end, and database functions. Additionally, the toolbar 4204 may include various options for adding and editing content on the web page.

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

[0438] 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 example above, a user creating a "course" database may configure various different permissions for the database and corresponding dynamic pages that may be based on it. 310 options. Permissions 4310 may address the content of the web page, data entry into forms, user-generated content of the page, content that is restricted to registered members, forms that can only be completed by registered members, and certain private data that is only accessible to certain users (e.g., administrators).

[0439] FIG. 44 is an exemplary user interface for editing entries in web pages and database collections according to some embodiments of the present disclosure. For example, a “Course” database may be composed of fields 4412 (title), 4414 (description), 4416 (image), 4418 (lecturer), etc. These fields may contain information about the 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 4416). As shown, field 4416 contains an image corresponding to a course titled “TING.” In some embodiments, a user can further define the type or layout of each dynamic web page and specify a URL for each dynamic page. For example, a suffix in the URL may correspond to a column (e.g., title) in the database.

[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 include content from a database. As shown, content 4520 includes course descriptions from the database. The content 4520 is automatically extracted from the database without requiring a user to manually copy it into the web page. This technique can be used to create numerous dynamic pages, each linking to a different portion of the database and having a unique configuration of content based on the link to the database.

[0441] 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 an element that are similar in structure or layout (e.g., a combination of text and images). Repeaters can be used to create two or more instances of an element that differ in at least one respect (e.g., have different text, images, etc.).

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

[0443] 47 is an exemplary user interface for editing a web page and showing the results of a repeater function, according to some embodiments of the present disclosure. As shown, a user has created 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 edit mode, a user can, for example, edit the text element The layout and appearance of these instances can be further edited by changing the position of images relative to the elements, modifying hyperlinks, resizing fields, etc. Additionally, as noted above, each element of an instance can be connected to a different portion of a database. For example, three combinations of elements 4724 can each be linked to a different column in the database corresponding to the content to be extracted from the database. In this way, the three combinations of elements 4724 have a common layout, but each has different text or graphic content.

[0444] Various operations or functions are described herein that may be implemented or defined as software code or instructions. Such content may be directly executable ("object" or "executable" format), source code, or differential code ("delta" or "patch" code). Software implementations of the embodiments described herein may be provided via a product having the code or instructions stored thereon or via a method of operating a communications interface that transmits data through the communications interface. A machine- or computer-readable storage medium causes a machine to perform the described functions or operations and includes any mechanism for storing information in a form accessible by a machine (e.g., a computing device, an electronic system, etc.), such as recordable / non-recordable media (e.g., read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, etc.). A communications interface includes any mechanism that interfaces with any wired, wireless, optical, etc. medium for communicating with another device, such as a memory bus interface, a processor bus interface, an Internet connection, a disk controller, etc. A communications interface may be configured by providing configuration parameters and / or sending a signal to prepare the communications interface to provide a data signal describing the contents of the software. The communication interface may be accessed via one or more commands or signals sent to the communication interface.

[0445] The present disclosure also relates to systems for performing the operations herein. The systems may be specially constructed for the required purposes, or may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such computer programs may be stored on any type of computer-readable storage medium, such as, but not limited to, floppy disks, optical disks, CD-ROMs, and magneto-optical disks, read-only memory (ROM), random-access memory (RAM), EPROMs, EEPROMs, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each connected to a computer system bus.

[0446] Embodiments of the present disclosure may be implemented with computer-executable instructions. The computer-executable instructions may be organized into one or more computer-executable components or modules. Aspects of the present disclosure may be implemented with any number and organization of such components or modules. For example, aspects of the present disclosure are not limited to the specific computer-executable instructions or the specific components or modules illustrated and described herein. Other embodiments may include different computer-executable instructions or components having more or less functionality than illustrated and described herein.

[0447] Computer programs based on the written descriptions and methods herein are within the skill of a software developer. Various programming techniques can be used to create various programs or program modules. For example, program sections or program modules can be written in JavaScript, Scala, Python, Java ( The software sections or modules may be designed using XML, C, C++, assembly language, or any such programming language, as well as data encoding languages ​​(such as XML, JSON, etc.), query languages ​​(such as SQL), presentation-related languages ​​(such as HTML, CSS, etc.), and data transformation languages ​​(such as XSL). One or more of such software sections or modules may be incorporated into a computer system, a non-transitory computer-readable medium, or existing communications software.

[0448] Words such as "comprising," "having," "containing," "including," and other similar forms are intended to be interpreted as equivalent in meaning and open-ended, in that the item or items following any one of these words are not intended to imply an exclusive enumeration of such item or items, or to be limited solely to the item or items listed. Additionally, the singular forms "a," "an," and "the" are intended to include plural referents unless the context clearly dictates otherwise.

[0449] While aspects of the embodiments have been described in detail, it will be apparent that modifications and variations are possible without departing from the scope of the present invention as defined in the appended claims. Because various changes can be made in the structures, products, and methods described above without departing from the scope of the present invention, it is intended that all matter contained in the above description and shown in the accompanying drawings be interpreted in an illustrative sense and not in a limiting sense.

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

[0451] Websites and Stateless Serving Architectures 1. When a user interacts with a website, they typically spend most of their time interacting with client-side pages, web applications, and FE code running on the client machine / browser, rather than with BE code or a web server. However, this client-side website / application still makes multiple HTTP (or other) server requests. These may include, for example: 1.1. The initial HTTP request made to load a page, which may trigger further HTTP requests to load further page elements (such as included images or 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 the given field. 1.3. Data-related HTTP requests, such as submitting a form filled out by a user. 1.4. BE-related HTTP requests that activate BE functionality. This can be performed using the system that serves the website or an external (third-party) web service. 2. "Server" in this context can refer to an actual physical server, It may also refer to other running instances of website servers, such as VMs or containers (also known as dockers). 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 they make a request until they receive the first response. Response time is often measured as the server-side time from receiving the request to sending the first response byte (usually expected to be under 100 milliseconds). The reason for using a server-side time measurement is that it excludes variable network transmission times. 4. It may take significant additional time to actually complete the response. For example, when loading a new page, a user expects the page to begin displaying immediately in the browser, but the page may take significant additional time to load, and the user may begin interacting with the page before it has fully loaded. 5. A server system (usually consisting of multiple servers or a server farm) may respond using a stateless or stateful system / protocol. Note that while the HTTP protocol is inherently stateless, the use of a stateful server may be implemented using techniques outside the protocol (such as URL rewriting or hidden form fields). 6. Stateful systems are typically used when clients interact with pre-assigned servers. Such servers can provide continuous session context, but this configuration is very difficult to scale up, as the server must be continuously associated with one or more users and may be idle or partially idle 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 are transparent to the user, and these different servers have transparent access to external resources (such as database servers) needed to respond. 8. Stateless systems, i.e. systems that use stateless servers, have many advantages: in particular, they are highly scalable and do not require special handling for broken connections, since incoming requests can be directed to any (stateless) server in the system. 9. The stateless server(s) in existing systems must be completely interchangeable and cannot be adapted to a specific website or related pages. Therefore, such a configuration is suitable for simple, static websites. It does not work well when serving complex websites that require site-specific BE code (possibly including user-provided code), site-specific components, or site-specific plugins.

[0452] 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 running instance) that runs a web server instance configured for a specific site (including specific plugins and server-side user-provided code for the site) and does so fast enough to respond to HTTP requests without timeouts and within a total time frame acceptable to the user. 11. Starting a new virtual machine typically takes several minutes. Starting a new docker container still takes 2-3 seconds. Both of these times are unacceptable. 12. In the system of the present disclosure, a pool of standby containers may be provided that contains all relevant non-site specific code but no user / site specific code. 13. The system may listen on a live port for requests to connect to a server for a particular website. If there is a live container associated with a particular website, If so, the system may connect to it. Otherwise, it may use a standby container from the pool and populate the pool with the requested site-specific content or command such content to be loaded. Once the site-specific content for a given site has been loaded, the container joins the pool of containers associated with the given site. 14. Note that such a stateless container instance can handle a particular HTTP request (e.g., including data validation) without being the instance that handled the original page loading the HTTP request. 15. The site-level content populated may or may not include the actual site page. Such site page information may be, for example: 15.1. The actual browser-ready page material (e.g., a collection of HTML, CSS, and JS code). 15.2. The underlying site-defined data (e.g., XML files or JSON representations) that is transformed into browser-ready material by client-side or server-side code (e.g., a WBS Viewer module). 15.3. Front-end / back-end code, e.g., JavaScript code called by the page to run on the client, the server, or both. 16. If a site is inactive for a given period of time (such as 15 minutes), the system may drop the standby container. 17. To preserve the user's state and maintain the user's sense of working within a single session (with continuous context), persistent context is maintained using a combination of client-side storage (e.g., browser local storage, cookies, etc.) and server-side storage (e.g., saving to a server DB).

[0453] Use scenarios of conventional systems and the system of the present invention 18. Assume the following typical use scenario: 18.1. A user enters a URL page into a browser, requesting that the page be loaded. The loaded page contains a data entry form and has a significant amount of associated (site-level specific) FE and BE code. An HTTP request is made to the server to retrieve the page and its associated FE code at the site level, 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. A user fills out a form for 10 minutes and typically: <form>Working locally in a browser running a local page with HTML tags. This can also be done using Ajax calls or Fetch calls, or JavaScript or HTML setup that can initiate HTTP requests. 18.3. A form may make several requests during it that are sent to the server (e.g., get a list of allowed values ​​from a DB for a given field). Each of these requests activates a server-side BE script that does the actual DB access and information gathering (e.g., to avoid sending DB access credentials in 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 validated by an FE script, which then sends the form to the server, activating a server process that runs the associated BE code so that the form can (for example) be saved to a database. 19. In the above scenario, user activity is transmitted via HTTP requests or other mechanisms. Using this mechanism, a user might generate (for example) 20 requests over a 10 minute period, many of which activate site-specific BE scripts or component-specific BE scripts (for components used at the site). 20. Traditional stateless / stateful technologies handle this scenario as follows: 20.1. When using stateful servers, the server that originally served the page containing the form must continue running until the completed form is submitted, which could be 10 minutes later, even if it is doing nothing except possibly processing intermediate requests (such as "get a list of values ​​for field X" above). 20.2. Traditional stateless server technologies cannot timely cold-start a server, or even a VM or container, for each specific HTTP request (containing code specific to a given site), and therefore must either support sites without specific BE functionality, or keep a specific server instance running for the entire form-filling session (and therefore not really stateless). 21. Using the techniques of the present invention, a stateless server instance (e.g., container) is allocated to handle each specific HTTP request (load a page, get a list of values ​​for field X, save the completed form to DB). This results in server time usage of (for example) 20 request processing times (e.g., 20 x 200 ms = 4 seconds) instead of the entire 10 minute form filling session. The allocated server can be a new container (populated with site-specific elements) or an existing, available site-adaptive container. 22. Thus, for the same use scenario, the system of the present invention uses significantly fewer server resources than the conventional system, requiring the server for only 4 seconds instead of 10 minutes (most of which the server instance is idle, but still waiting for requests from a particular user). 23. This allows website hosting providers to provide the same level of service using a much smaller number of resources (servers, containers, etc.). 24. Incidentally, because users work locally on forms, if a user closes and reopens a browser window, they typically see an empty form (rather than a partially filled-in form). The system of the present invention may provide an API that allows the form contents to be persisted to the browser's local storage. Thus, if a user closes and reopens a partially filled-in form window, the reopened form will contain the previously entered values. This also works if the browser is completely closed. 25. Similarly, BE tasks can still provide context information to each other, for example by storing the context information in a (server-side) server DB, or by providing information that is maintained by the client and passed to subsequent BE invocations. Such information may be for the duration of the session only, or may persist as needed (e.g., using browser local storage). 26. Also note that injection of specific component code and associated FE / BE scripts is typically done site-wide (i.e., all special components and scripts used by all pages in the site) rather than at a specific page level granularity. This way, the injected containers can be reused for every page in the site whenever a new HTTP request arrives for this site (from the same user or another user). 27. However, the system may implement different levels of granularity depending on the amount of "material" being injected, on the one hand, and its usage pattern, on the other. Thus, the system may implement (for example) a page, page group (i.e., site section), site, or site group injection granularity level. For example, the case of a site group may be relevant when a number of sites are very similar and use common related components and scripts. In this way, content specific to a site group may be injected. The container can be reused to handle requests to any site in the group, not just one site.

[0454] Use of the system of the present invention in a WBS context 28. Online WBS is characterized by having two modes of use. 28.1. Site Editing - Site definitions (e.g., XML / JSON data, or DB records, or actual HTML page material) are typically edited by a visual editor application running in a browser with server support. Such sites may include FE code and BE code (which may also be editable in the editor), as well as specific components required for the site (e.g., third-party applications). The editor can also invoke the site in preview mode. The editor may also support a publish operation, which publishes a version of the site for use by external users. 28.2. RT (Runtime) Mode - The system provides the published site to the user, activating FE or BE code as needed. 29. The system of the present invention described above can be used in both the edit mode and the RT mode of the system. 30. When working in edit mode. 30.1. Edited site context includes: 30.1.1. The complete site definition (pages, components, and associated data) is typically persisted by the editor client as an in-memory structure on the client side (e.g., as a JSON representation). 30.1.2. Site FE code. 30.1.3. Site BE Code. 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 general code of the system (in the "general section" preloaded in 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. Temporary storage of FE / BE code is limited, allowing users to continue editing the same code via a "moved" container. This is necessary because the site's FE / BE code is not part of the site's JSON code. 31. Note that the site code is kept in the DB so that it can be used when running a preview and so that the editor does not have to load the entire site code (which can be large), but only the relevant section that is relevant to the page being edited or current. 32. When operating in runtime mode, the system operates as described above for serving regular websites. A WBS may have a viewer module (required for all sites edited with the WBS), and such module is part of the system's general code preloaded on the launched server / container instance. 33. Thus, the system of the present invention can be used by WBS for both editing and RT.

[0455] Acronyms used BE: Backend FE: Front end VM: Virtual Machine WBS:Website Building 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 of the files that make up your site, including pages, lightboxes, files, database collections, etc. This sidebar allows you to perform various actions that affect your site, as detailed below. [Table 1] To hide the sidebar, click the hide icon in the bottom left of the editor. To show the sidebar, click the view icon in the bottom left of the editor.

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

[0458] Regular page Regular pages on your site will appear just below the title of the Pages section. To change the settings for a page, hover over the page name and click the settings icon that appears. You can set any page on your site as a dynamic page except for the home page.

[0459] Dynamic Pages To add a new dynamic page to a group, hover over the section name and click Click the settings icon that appears. To change the page settings, such as the URL or SEO data, click the settings icon that appears when you hover over the dynamic page name, then remove the dynamic connection to make the dynamic page a regular page, or delete the dynamic page.

[0460] Router Page If you have created a router, all pages associated with that router prefix will be grouped together in the same section. For example, if you created a router with the prefix myrouter, the section will be named Myrouter Pages(Router). Each router page is given a default name used in the router code. You can change the name if you want. The page name is not visible to page visitors. To change the router prefix and the names of the associated functions implemented in the routers.js file, or to add new pages 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 make it a regular page, click the settings icon that appears when you hover over the router page name. To add a new router, click the plus icon that appears when you hover over a page section header.

[0461] Lightbox If you have added a lightbox to a page on your site, it will appear in the Lightboxes section of your sidebar. This section only appears if you have added at least one lightbox to your site. To add a new lightbox, use the Add menu in the editor. When you select an existing lightbox in the sidebar, the editor enters lightbox mode. The Public section of 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. Your page and site code are also publicly accessible, but do not appear in the Public section. To edit your page and site code, use the Code panel. 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 a new file, a new folder, or delete a folder, click the settings icon that appears when you hover over the folder name. To rename or delete a file, hover over the file name and click the settings icon that appears.

[0462] Backend The Backend section of the sidebar lists files that are not publicly accessible from your site. This is where you place code that runs server-side. You can create JavaScript files, web modules, and text files for use in the backend, and organize these files into folders. In the backend section of your site, you may have two special JavaScript files: a data.js file that contains code for data hooks, and a routers.js file that contains the router and data binding router hooks. Contains 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 a new file, a new folder, or delete a folder, click the settings icon that appears when you hover over the folder name. To rename or delete a file, hover over the file name and click the settings icon that appears.

[0463] Database To add a new collection, click the plus icon that appears when you hover over the section name. To add a new dynamic page 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 Lightbox About Database Collections About the Router About Data Binding Router Hooks

[0465] Home>Wix Code>Wix Code Basics Using 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 that contain 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 want to use the code. Tip: To open the Code Panel, simply drag it up from the bottom of the page. Elements in the editor can appear on a specific page or on all pages of your site. You can add code that is relevant only to a specific page, or you can add code that is relevant to all site pages. The code panel has two tabs on the left: Page and Site. Page: The Page tab contains code for elements that appear on specific pages. When you add an event to an element using the Properties panel, the code for that event is automatically placed on the Page tab. If you have code that only relates to specific pages, add it here. Site: If an element appears on all site pages and you want to add functionality to that element that is consistent across the 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 on 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 all pages, and you want to add code for it that is specific to one page, add the code to the page tab for that page.

[0466] Wix Code Syntax and Autocomplete Selecting a specific element Wix Code allows you to code using standard JavaScript, and it has a specific syntax or set of rules for selecting elements on a page, which are:

number

number

[0467] Selecting multiple elements To select multiple elements by name, use the same syntax as above to reference the elements, like this: Separate each element with a comma.

number

[0468] Select all elements of a certain type To select all elements of a particular type, use the element type name without the hashtag, like this: The element type name is the element name that appears in the Wix Code API.

[0469] JavaScript Templates In addition to autocompletion related directly to Wix code, the code panel also includes autocompletion for standard JavaScript templates and keywords. For example, if you type the word "for," the autocompletion list includes templates for "for statements" and the keyword "for." Each template includes a link to the standard JavaScript API for more information.

number

number

[0470] Ensure elements are loaded before referencing them Advanced information about onReady When a page loads in a browser, the code on the page may execute before the page finishes loading, which can cause errors if the code tries to reference elements in the page before the page has loaded.

number

[0471] Using elements Every element in the editor has properties, methods, and event handlers that you can use to use the element and add functionality to your site. Select an element and then type a period to see a complete list of these items.

number

number

[0472] Properties Properties contain information about an element; some of them are read-only, while others can have values ​​set. For example, text elements have an isVisible property that returns whether the element is actually visible on the screen. This property is read-only. Text elements also have a text property that contains the current text of the text element. This is a property that can be both read and set.

[0473] Methods Methods perform actions on elements. For example, the button element has a hide method that prevents the button from appearing 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 Handlers Event handlers allow elements to respond to user actions (events). When you add an event handler to an element, you also need to specify what to do when the event occurs. For example, say you have a button that says "Take a Tour." You want to add functionality so that when a visitor hovers over the button, the text changes to "Let's go." You would add code to your site that looks like this (we've added comments to explain each part of the code):

number

[0475] Warnings and Errors As you write code in the Code panel, you may encounter warnings and errors. Warnings appear in yellow and errors in red. These appear as colored wavy lines under the relevant code and as icons to the left of the line numbers. To view the warning or error message, hover over the icon.

[0476] caveat Warnings in code are informational messages that draw your attention to code that you might want to change. Warnings do not stop your code from running and can often be safely ignored. Warnings are displayed with a yellow triangle and a wavy yellow underline.

number

number

number

[0477] error Errors in your code mean that your code will not function properly. Depending on the type of error, your code may not function as expected or may not run at all. Make sure you fix all errors in your code before publishing your site for use by your site visitors.

number

number

number

[0478] Embedded Media Manager In Wix Code, you can use images stored in Wix Media Manager in your code. When you use an element that contains an image property, such as src, a popup window will open with

number

[0479] Test your code Your code will run on your published site, but it's a good idea to test your code before publishing it to make sure it works as expected. To test your code before publishing it, you can preview your site. The code in your site runs exactly the same in preview mode as it does in the published version. You can also debug your code on your published site.

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

[0481] Related content Using JavaScript in Wix Code 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. Your site's database is made up of collections. You can think of each collection as a table of data, like a spreadsheet. Each row in the table represents an item in the collection. Each column in the table represents a field. Therefore, each item contains the fields defined by the collection's columns. For example, the following collection contains four fields and five items: [Table 2]

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

[0484] Edit a collection Within each collection in the database, there is a sandbox version and a live version of the data. You edit the sandbox version in the editor's Content Manager, and 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 a 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, use the field name in the Text Connection panel. [Table 4] When you add a new field in the Content Manager, you specify the field name. If you change the field name after creating the field, all connections to that field are 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, use the field key: When you add a new field in the Content Manager, a field key is automatically created based on the field name, or you can specify your own field key if you want. important: You cannot change the field key after the field is created.

[0488] Field Type A field type defines the kind of data a field contains. When adding a new field in the Content Manager, you choose one of the following field types. Read more about field type support and limitations here. ·reference ·text ·image ·Boolean Numbers Date and time Rich text URL ·document Field types are also used when connecting page elements to fields in your collection. Certain input elements can only be connected to fields of the associated field type. For example, you can connect a text element to a text or URL field, but not to an image field. The Content Manager will not allow you to add a new value for the wrong field type, but it will not validate data imported from a CSV file or added via code. For example, you can import a text value into a numeric field. The Content Manager will display an error in this case. Use the Reference field type to select an item from the primary field of a reference collection. For more information, see To create a reference field. Note:

[0489] Primary Field Every database collection has a primary field, indicated in the Content Manager by a lock icon next to the field name. By default, the title field is the primary field, but you can set any other text field in the collection to be the primary field, except for identity system fields. When you enter information in a reference field, you select from the values ​​in the referenced collection's primary field. If you change the referenced collection's primary field, the value displayed in the reference field changes to match the new primary field value. It is recommended that each item have a unique value in the primary field. For more information, see About reference fields.

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

[0491] Calculated fields When you create a dynamic page, a new field is added to the collection that the dynamic page pulls data from. This field contains a calculated URL that includes the prefix of the dynamic page and the value of the field that determines the data that is bound to the page. For example, say you have a dynamic item page that displays items from a dishes collection based on the title field. The collection has a field called dishes (title) with URLs such as / Dishes / pizza and / Dishes / checken. When a visitor goes to a dynamic page, all items from 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 the case of a page, multiple items share a URL. You cannot edit the contents of a calculated field. However, if you change the URL of a dynamic page, the URL in the collection will change accordingly. If you create multiple dynamic pages based on a collection, the collection will have one calculated field per dynamic page. For more information, see About calculated fields. The permissions model lets you control which visitors are allowed to interact with the data in your collections and what they are allowed to do. Permissions are set per collection. You assign permissions that determine which user roles can perform which actions. For example, you can give site members create permissions for a comments collection, but prevent them from creating items in another collection. 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 into a collection. Please refer to the article below. About Sandbox and Live Data

[0493] Related content Making the database structure available Change the field type About reference fields About Collection Permissions To import collection data into Content Manager About Sandbox Data and Live Data Remove a field from a collection About calculated fields About dynamic pages To export collection data in Content Manager

[0494] Home > Wix Code > Advanced About the Router Visit the Wix Code Resource Center to learn more. Using Wix Code, you can create a router that gives you complete control over how requests coming into your site are handled. You do this by configuring the router to accept all incoming requests with a specified prefix, and then defining the logic to execute when a request with that prefix is ​​received. This determines the action to take, the response to return, where to route the request, and what data to pass to the page. You can use the router to: Display dynamic pages using content from any data source. · Customize your URLs to make them more meaningful and improve SEO results. Authenticate users and display content exclusive to them. Return custom HTTP response codes. The router API reference can be found here.

[0495] URL prefix When you create a router, you decide which requests to route based on the URL prefix you specify. All incoming requests with that URL prefix will be sent to the router for processing. The URL prefix will also be used as the router name. The prefix is ​​the 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, which can be found in the Backend section of the Site Structure sidebar. It has two main functions, which are the entry points to the router: They are named according to the following convention: ·<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, which contains information about the incoming request. The function then decides how to handle the request and returns an appropriate WixRouterResponse. Typically, the router() function decides 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() functions.

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

[0498] Router Data The router() function can choose to send data to the page it routes to. To access that data in your front-end page code, use the getRouterData() function in the wix-window module.

[0499] Related content Create a router

[0500] Home > Wix Code > Advanced Create a router Creating a router gives you complete control over how requests coming into your site are handled. This article explains the code you need to write to make a router work. For more information about 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 over a page section header in the Site Structure sidebar and select Add Router. 2. Enter the URL prefix for the router and click Add and Edit Code. All incoming requests with the specified URL prefix will be sent to the router for processing. To add a router: The router() and sitemap() functions are added to the routers.js file, along with example code for a simple routing scenario. The routers.js file can be found in the Backend section of the Site Structure sidebar. A new section under Pages will also be created for your router. The section will be named using the prefix you chose earlier and will contain one page to get you started. For example, if you named your router "myRouter", a MyRouter Pages(Router) section will be added with a page named myRouter-page.

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

[0503] import statement The functionality used to create a router is contained in the Router API, which you must import to use it. By default, the ok() and notFound() functions and the WixRouterSitemapEntry object are imported.

number

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

number

[0505] Router Functions Note that all incoming requests with the URL prefix you specified when creating the router will be sent to the router for processing. The router() function handles these requests. The router() function is named according to the following convention:

number

number

number

number

number

number

number

number

number

number

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

number

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

number

number

number

[0508] Related content About the Router

[0509] Home > Wix Code > Advanced SEO and Routing The SEO settings for router pages are slightly different from those for regular pages. Learn more about SEO for Wix pages here. You can define the page title, description, and social network images for your Router Pages just like you would for regular Pages, the difference is that Router Pages do not contain static data and you must set the SEO information dynamically so that it reflects the actual content you hold when displayed. There are two parts to setting up SEO on your router page: · Create meta tags to help Google learn about your page. Create a sitemap for Google to use to find your pages.

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

number

[0511] Sitemap Your site's sitemap is what Google uses to find all of your site's pages. Any pages on your site that don't belong on the router are added to your site's sitemap. However, because you have full control over the pages available on your router, including all dynamically different versions, you need to create a sitemap that includes all possible URLs connected to your router's prefixes so that Google can find them. To add router pages to your site's sitemap, create a sitemap() function for your router. Within that function, create a WixRouterSitemapEntry object for each URL that 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 its content changes, when it was last modified, and its relative priority within your site. Google uses sitemap entries to discover all the pages in your site. For example, in the sample code provided when adding a router, the following code Using the data obtained by the router, construct a HeadOptions object and pass it to the page named myRouter-page.

number

[0512] Home > Wix Code > Advanced Accessing third-party services You can use Wix Code to write code that accesses third-party web services. You can call third-party services directly from your client-side code. However, if you have security concerns, such as exposing your API key, you can call the service from a backend web module. Note: If your site is an HTTPS site, you cannot request HTTP content from the service. The invalid request will cause an error, which you can verify 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 for the site and retrieve the HTTP resource. Advanced: Modules available for invoking services

[0513] Client-side service invocation For example, say you want to call a third-party service to look up currency exchange rates. For this example, we've created a simple form with the following elements: [Table 6] Once you have your form set up, you can set the button's properties so that its onClick handler calls the following function:

number

[0514] Calling backend services Calling a service from the backend happens in two parts: First, you write the code that makes the service call in a backend web module, which avoids security concerns like exposing your API key, and For example, consider calling a third-party weather service to find the current weather for a user-selected city. First, create a function in your backend web module that will call the weather service and retrieve the data.

number

number

[0515] Related content Calling server-side code from the front end with web modules

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

[0517] Home > Wix Code > Dynamic Pages About dynamic pages Visit the Wix Code Resource Center to learn more. When you create a dynamic page, you design one page layout that can be used repeatedly, displaying different items from a database collection each time. A dynamic page is different from a regular page because it displays different items each time it is displayed. It stores content on the page itself, but content for dynamic pages is stored in a database collection. Dynamic pages are useful when: You're duplicating pages and manually changing the content or design of each page. Dynamic pages let you create a single page that displays one item at a time or multiple items in a group. Editing the content of your site without changing anything in the editor or changing the design of your site. There are two types of dynamic pages: Dynamic Item Page: A page designed to display a single item in a collection. Dynamic Category Page: A page designed to display multiple items in all your collections that match the same criteria. These items are displayed in a repeater, gallery, or table.

[0518] example Imagine you're creating a recipe site. When you create a new database collection, a Title field is automatically added to the collection. You want to use this field to store the name of the recipe. You add a Meal field to the collection to indicate whether the recipe is for breakfast, lunch, or dinner. You also add a Course field to indicate whether the recipe is for an appetizer, main course, or dessert. Next, design your site so that each recipe can appear on its own page. In this example, the page that displays an individual recipe is a dynamic item page, and the page that displays all recipes based on diet is a dynamic category page. Let's take a look at some content from the collection to see how this works. [Table 8] Now let's see how this content looks on a dynamic item page. Note: This example demonstrates what you can do with the power of dynamic pages. To set them up, see To add a dynamic item page and To add a dynamic category page.

[0519] Dynamic Item Pages To display each item from your collection, create a dynamic item page, which looks like this: [Table 9] Notice that in this layout, the only elements that contain actual content are the headings "Recipes," "Meals," and "Courses." The content that appears next to these headings (the text enclosed in "<>") has not yet been placed on the page. For example, "<Recipe Title>" is just placeholder text for the text box where the actual recipe name will appear. Also, the image in between is just a placeholder image (it is not an image from your collection). The actual content that these elements display will come from your collection. Now let's preview this dynamic item page for a cupcake recipe. [Table 10] See how each placeholder has been replaced with specific information about the cupcake recipe, and how the image shows a cupcake image from the collection. Please pay attention to: On the same page, you can preview the Eggs Benedict recipe and see the changes to the placeholder content. [Table 11] Now let's see how this content looks on a dynamic category page.

[0520] Dynamic Category Page You can create a dynamic category page that displays different groups of recipes based on criteria you select. Imagine you want to create a page that can display recipes based on the meal they serve, and you can use a table to display those recipes. [Table 12] Like the item page, this dynamic category page doesn't have any actual content. Let's see what it looks like when we preview Lunch Recipes. [Table 13] [Table 14]

[0521] Linking to a dynamic page Because dynamic pages display content dynamically, you cannot link to a dynamic page the same way you link to a regular page. For more information, see Linking to a dynamic page. Tip: 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 Making multiple dynamic page URLs unique About Database Collections About dynamic pages and the items they display Linking to a dynamic page

[0523] Home > Wix Code > Advanced About Data Hooks Data hooks run code before and after specific interactions with your site's collections. Data hooks allow you to intercept interactions just before or just after they occur. The code in a hook can also be used to influence the interaction itself. For example, you might want to intercept an item before it's added to a collection to perform some final validation or tweak the data that actually goes into the collection. Generally, hooks run regardless of whether an 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 pass an optional WixDataOptions object that you can use to prevent hooks from being called for that particular interaction.

[0524] Hook type There are several different points in the lifecycle of a data interaction that you can hook into. Different hooks accept different arguments and return different values. See the Data API Reference for more information. item: The current item. For example, in beforeInsert, this is the item that is about to be inserted. If there are many items, as can happen in afterQuery for example, 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: The error object. [Table 15]

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

[0526] Home > Wix Code > Advanced About Data Binding Router Hooks When a request comes in for one of your dynamic pages, the router uses the request's URL to determine which page to display and what data to bind to the page's dataset. You can add data binding router hooks to intercept this process at specific points and insert additional logic. Several hooks are also available in router pages.

[0527] hook The data binding router hooks are defined in the routers.js file, which can be found in the Backend section of the Site Structure sidebar. Hook functions are named according to the following convention:

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 could check who is requesting a page and based on the user's role, decide whether to let the router continue with 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 the data that is bound to the page's dataset. For example, you could filter the query to only return items that have the Status field 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 change the router's response based on the data you retrieve. For example, you could have two versions of a page: one for portrait images and one for landscape images. After pulling the images from the database, you could display the page that corresponds to the image's 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 search page information to the sitemap.

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

[0533] Add a data binding router hook To add a data binding router hook: 1. Click the settings icon that appears when you hover over one of your dynamic pages in the Site Structure sidebar, then click Settings to view the page's page information settings. 2. Under More Features, click Add Hook to display the Add Hook dialog. 3. In the Add Hook dialog, 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, which can be found in the Backend section of the Site Structure sidebar. Data binding router hook functions are named according to the following convention:

number

number

[0534] beforeRouter() This hook is triggered before the router navigates to the requested dynamic page. You can use this hook to route the request to a different page or return an error response. If you need data bound to the page to determine the correct response, use the afterRouter() hook instead. The beforeRouter() hook receives a WixRouterRequest object that contains information about the incoming request: t...

Claims

1. 1. A website hosting system implemented in a server environment, comprising: at least one hosting server configured to co-host a plurality of websites generated by a plurality of users, said hosting server including a hosted common editing tool accessible to said plurality of users to enable each of said plurality of users to selectively modify a particular website generated by each of said plurality of users, said hosting server further configured to prevent at least some of said plurality of users from modifying a particular co-hosted website generated by another of said plurality of users; at least one processor configured to generate an interface for display by at least a subset of the plurality of users to enable the at least a subset of the plurality of users to upload to the hosting server plug-in code associated with a plug-in for the particular co-hosted website created by the at least a subset of the plurality of users, the plug-in code for the at least one particular plug-in comprising: front-end plugin functionality code executable by the client, or Backend plugin function code that can be executed by the plugin server at least one processor including at least one of: a memory for storing the user-uploaded plug-in code associated with the at least one particular plug-in such that the stored user-uploaded plug-in code is centrally hosted on a common domain together with the co-hosted particular websites created by the plurality of users, wherein a single instance of the at least one particular plug-in is shared by a plurality of the co-hosted particular websites; Equipped with For each of the plurality of co-hosted particular websites that share the at least one uploaded plugin, the at least one processor uses an isolation mechanism to: Execution of the front-end plug-in functionality code at the client; or Execution of the backend plug-in function code in the plug-in server and further configured to securely enable at least one of: A website hosting system that, based on the isolation mechanism, prevents malicious code included in the at least one uploaded plugin from affecting other sites of the plurality of co-hosted specific websites on the hosting server.

2. The system of claim 1 , wherein the plug-in server and the hosting server are the same server.

3. The system of claim 1 , wherein the isolation mechanism includes enabling execution of the backend plug-in functionality code on the plug-in server separate from the hosting server.

4. The system of claim 1 , wherein the isolation mechanism includes enabling execution of the backend plug-in function code in a virtual machine.

5. The system of claim 1 , wherein the isolation mechanism comprises enabling execution of the backend plugin function code in a Docker container.

6. The system of claim 1 , wherein the isolation mechanism includes enabling execution of the backend plug-in function code via an isolated process in the plug-in server.

7. The system of claim 1 , wherein the isolation mechanism includes enabling execution of the front-end plug-in functionality code in a secure sub-area of ​​a particular co-hosted website.

8. 8. The system of claim 7, wherein the at least one processor is configured to establish a secure communication channel to control communications between the sub-area of ​​the particular co-hosted website and other sub-areas of the particular co-hosted website.

9. 10. The system of claim 8, wherein the secure communication channel is configured to limit access of the at least one uploaded plug-in to other aspects of the particular co-hosted website.

10. 10. The system of claim 8, wherein the secure communication channel is created using an application programming interface configurable to restrict interaction between the at least one uploaded plugin and the particular co-hosted website.

11. 2. The system of claim 1, wherein the isolation mechanism includes enabling execution of the front-end plug-in functionality code through an iframe in the client's browser, the iframe configured to serve as a secure sandbox for the execution of the front-end plug-in functionality code.

12. 2. The system of claim 1, wherein the at least one processor is configured to associate the client-executable front-end plug-in functionality code with a distinct web page sub-region of a particular co-hosted website.

13. The system of claim 1 , wherein the at least one processor is further configured to associate two or more trusted plug-ins with a particular co-hosted website.

14. 10. The system of claim 1, wherein the processor is further configured to enable the at least one uploaded plugin to communicate with and control at least one component of the particular co-hosted web page on which its front-end plugin functional code executes.

15. The system of claim 1 , wherein the website hosting system is configured to co-host the plurality of co-hosted specific websites on a shared platform accessible to the plurality of users.

16. The system of claim 1 , wherein the at least one uploaded plug-in is separate from cookies associated with web pages of a particular co-hosted website.

17. 1. A website hosting method implemented in a server environment, comprising: a hosting server co-hosting a plurality of websites generated by a plurality of users; said hosting server making available to said plurality of users a common editing tool to enable each of said plurality of users to selectively modify a particular website created by each of said plurality of users; the hosting server preventing at least some of the plurality of users from modifying particular co-hosted websites created by other users of the plurality of users; at least one processor generating an interface for display by at least a subset of the plurality of users to enable the at least a subset of the plurality of users to upload to the hosting server plug-in code associated with a plug-in for the particular co-hosted website created by the at least a subset of the plurality of users, the plug-in code for the at least one particular plug-in comprising: front-end plugin functionality code executable by the client, or Backend plugin function code that can be executed by the plugin server and a memory storing the user-uploaded plug-in code associated with the at least one particular plug-in such that the stored user-uploaded plug-in code is centrally hosted on a common domain along with the co-hosted particular websites created by the plurality of users, wherein a single instance of the at least one particular plug-in is shared by a plurality of the co-hosted particular websites; For each of the plurality of co-hosted particular websites that share the at least one uploaded plugin, the at least one processor uses an isolation mechanism to: Execution of the front-end plug-in functionality code at the client; or Execution of the backend plug-in function code in the plug-in server securely enabling at least one of: Based on the isolation mechanism, malicious code contained in the at least one uploaded plugin is detected by the plurality of co-hosted plugins on the hosting server. Steps to prevent the specific website from affecting other websites, Website hosting methods, including:

18. 20. The method of claim 17, wherein the at least one uploaded plug-in is separate from cookies associated with web pages of a particular co-hosted website.

19. The method of claim 17 , wherein the plug-in server and the hosting server are the same server.

20. The method of claim 17 , wherein the isolation mechanism includes enabling execution of the backend plug-in functionality code on the plug-in server separate from the hosting server.

21. The method of claim 17 , wherein the isolation mechanism includes enabling execution of the backend plug-in function code in a virtual machine.

22. The method of claim 17 , wherein the isolation mechanism includes enabling execution of the backend plugin function code in a Docker container.

23. The method of claim 17 , wherein the isolation mechanism includes enabling execution of the backend plug-in function code via an isolated process in the plug-in server.

24. 20. The method of claim 17, wherein the front-end plug-in functionality code executable by the client is configured to generate a user interface in a browser iframe.

25. 20. The method of claim 17, wherein the front-end plug-in functionality code executable by the client is configured to generate a user interface using a web worker associated with the client.

Images