Edit of database while previewing virtual web page

Abstract

To provide a website building system, a computer-implemented method, and a non-transitory computer-readable medium that allow edit of a database while previewing a virtual web page.SOLUTION: A method comprises receiving a plurality of data elements via a user interface and storing a group of at least one data element in a database. Each virtual web page is a preview of a corresponding actual web page before the corresponding actual web page is run. The method also comprises displaying each group of at least one data element on an individual page of a plurality of virtual web pages, displaying an editing tool to enable a user to edit a virtual web page from the plurality of virtual web pages, converting the edit to the virtual web page into updates for the database, storing the updates in the database, and displaying the corresponding actual web page 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 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 / 18, 2017 No. 15 / 706,789, U.S. Patent Application No. 14 / 207,930, filed March 13, 2014, U.S. Patent Application No. 15 / 657,156, filed July 23, 2017, U.S. Patent Application No. 14 / 699,828, 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 / 2014, filed September 19, 2017, / 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, 2017,No. 586, U.S. Patent Application No. 15 / 661,342, filed July 27, 2017, U.S. Patent Application No. 15 / 850,151, filed December 21, 2017, U.S. Patent Application No. 16 / 002,356, 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 back-end functionality running on a system that is fully managed by a third party. For example, embodiments may be implemented in a stateless server environment (container, serverless code, or other) that runs on a system that is fully managed by a third party and that runs when programmable events associated with front-end components or system activity are triggered, without the user of the system needing 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 be spun up as virtual machines, containers, or serverless code elements in some embodiments. More specifically, the present disclosure relates to systems and methods for monitoring the load and activity of a hosted website in order to automatically add and remove instances serving the website hosted on the system without significant delay in responding to requests to serve the website. Additionally, the hosted website may include a combination of generic code and website-specific code.

[0005] Still further, the present disclosure relates to web site visualization and testing with real-time access to data generated in a production environment for and by end users of the web site and data linked to the web site. More specifically, the present disclosure relates to providing access to data typically seen by end users of the web site for a web site developer or designer to test the functionality and experience of the web site.

[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. During the display of the virtual web page, the user may edit the virtual web page, and the user's edits may be converted into updates for the database. Additionally, 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, whereas traditional website development systems provide a templated front-end UI with no or limited back-end control via calls to external services or embedded code snippets that invoke server-side code, limiting the system to web pages with no or minimal options for data manipulation or other custom functionality, whereas other systems require maximum 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. Additionally, traditional systems lack the ability to incorporate software-based routers for web pages that allow web pages to contain different content and functionality differently depending on how a user accesses or interacts with the web page. Traditional systems also lack the ability to monitor website user interactions and show resulting output based on previously registered functionality associated with those interactions.

[0009] Traditional managed website hosting systems either use dedicated servers that require significant costs 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 in responding 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] Conventional website development systems are also limited in their ability to allow users to dynamically edit the preview of a page. Such systems also cannot receive edits to the previewed page or convert those edits into updates to a database on which all or part of the page is based. As a result, using such conventional 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 of an end user using a website without disrupting the end user's experience. However, conventional website testing systems provide a limited preview interface to review the site as an end user would experience the website, but do not provide real-time access to the data generated by the website being tested. Conventional systems also lack the ability to add new data or remove data generated for the site without impacting the end user experience.

[0012] Traditional website hosting systems are also vulnerable to plugins (e.g., software that may be embedded 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, such code can spread through the website hosting system and affect websites of other owners or users. Traditional website hosting systems do not have the ability to isolate uploaded plugins and prevent them from infecting other websites commonly hosted by the systems. 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] Furthermore, there is a need for technical solutions for new on-demand systems that process requests to websites without significant delay. Such technical solutions should utilize virtual computing resources such as virtual machines, containers, serverless code, etc. Furthermore, such solutions should enable highly customized websites that contain both functionality common to many pages or sites and functionality unique to a particular page or site.

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

[0016] In addition, there is a need for technical solutions to isolate uploaded plugins and prevent them from spreading 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 utilize 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 editing and dynamic preview of pages to use a common online database, which may be accessed by designers and users simultaneously. 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 viewable 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 to configure a programmable event via the integrated interface viewable by the remote web browser 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 execution of 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 send the skeleton code to a remote web browser for activation of the skeleton code.

[0021] Additionally, in some embodiments, the system includes a function associated with a website building element selected by a 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 back-end 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] Moreover, in some embodiments, the at least one processor is further configured to execute the edited user-editable code to implement a plurality of customized back-end 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 a website with customized back-end functionality, the method including the steps of maintaining an online database configured to store a library of website building elements for constructing a front-end of an indexable web page, transmitting first instructions to a remote web browser of a user, the first instructions enabling the user to remotely access the stored library and to utilize a selection of the building elements for constructing a front-end of an 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 the 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 the online database and outside the remote web browser for use in executing edited user-editable code to implement 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 a selectable segment of 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 enabling the skeleton code.

[0037] Furthermore, 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 viewable by a remote web browser, the remote web browser including a front-end website editing window and a customized back-end editing window.

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

[0040] Additionally, in some embodiments, the method includes a trigger 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 comprise at least a first memory location storing generic website server code for hosting a plurality of websites, and at least a second memory location storing website-specific code unique to each of the plurality of websites in a manner separate from the first memory 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 specific to none of the websites. The system may further comprise at least one processor configured to perform operations including: executing generic website server code lacking unique code; receiving a request to access a specific website, the specific website being built on a platform including 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 executing the generic website server code; populating the first of the plurality of web server running instances executing the generic website server code with additional website-specific code 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 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] Moreover, in some embodiments, the request is an HTTP request and the system includes an operation 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 the HTTP request, including the acts of receiving and determining.

[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] Further, in some embodiments, the act of determining 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 multiple 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 multiple 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 web sites already hosted by one of the multiple web server running 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 web sites unique to the requested web site 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 plug-ins 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 yet 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.

[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 the generic website server code that is not unique 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; and controlling a plurality of web server execution instances to access the particular website, the plurality of web server execution instances. the at least one second memory 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] Moreover, 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 the plurality of websites and at least other of which execute generic website server code that is free of 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 instance of the plurality of web server executing instances that executes the generic website server code, the request prompting the first instance 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 the at least one memory device; and responding to the request via the first instance of the plurality of web server executing instances with a combination of both the generic website server code and the injected website-specific code 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 comprise 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 perform 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 not accessible in the website deployment environment, and testing the website in parallel in the private website testing environment such that both sets of test data and live data are used simultaneously by the website in the private website testing environment while the website is running in the website deployment environment.

[0063] According to some embodiments, the 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] Moreover, according to some embodiments, the system is a website hosting environment for hosting multiple websites generated by multiple users.

[0067] Further, according to some embodiments, the at least one common database is a centralized online database configured to store live data associated with a plurality of websites generated by a plurality of 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 the 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 to 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 executing live website data in a website deployment environment while executing 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, the test data being stored in a The method may include: associating with the 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 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 not accessible in the website deployment environment; and testing the website in parallel in the private website testing environment such that both sets of test data and live data are used simultaneously by the website in the private website testing environment while the website is running in the website deployment environment.

[0077] According to some embodiments, the method may include associating test data with the 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 a plurality of websites generated by a plurality of 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 testing environment while executing live data of a visual application system in a deployment environment, the computer-based system comprising: at least one common database storing 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 perform testing 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 includes 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 testing environment such that both sets of test data and the live data are used simultaneously by the visual application system in the private testing environment while the visual application system is running in the deployment environment.

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

[0084] Certain embodiments of the present disclosure include a computer-readable medium including instructions that, when executed by at least one processor, cause the at least one processor to execute certain instructions for updating a backend database including a data set to be populated into a plurality of web pages of a website, the instructions may perform operations for receiving a plurality of data elements via a user interface, organizing 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, 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 goes live, each of the corresponding actual web pages 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 edits to the virtual web pages 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, 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 actions include displaying user-selectable features that allow a user to navigate across the multiple virtual web pages to individually and dynamically display each of the multiple 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 the 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 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.

[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] Further, additional embodiments include a live view of a corresponding actual web page that includes 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 a plurality of web pages of a website. The method may include receiving a plurality of data elements via a user interface, where the data elements are 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, where each virtual web page is a preview of a corresponding actual web page before the corresponding actual web page is run, where each corresponding actual web page is 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, to display the corresponding actual web page 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 user-selectable features that enable 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, an 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 back-end database that includes a data set to be populated into 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 being 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. The operations may include 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 display of 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 acts 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 for remotely providing second instructions to the browser for displaying an interface for enabling a user associated with the browser to add data elements to the database, to associate each added data element with at least one of the plurality of groups, and to modify at least one of the front end code and the back end code, and for controlling the added data elements by the user, the association of the added data elements with at least one of the plurality of groups, and the front end code and 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 the browser fourth instructions for displaying a preview interface configured to display the plurality of scrollable virtual web pages prior to generation of a corresponding final web page, the preview interface enabling a user to selectively scroll across the plurality of scrollable virtual web pages based on each of a plurality of groups of the 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 for displaying an online editor interface to enable a user to drag and drop a selection of 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 corresponding final web page front end.

[0115] Further, 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 multiple 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 a number of scrollable virtual web pages displayable within a frame 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 a particular virtual web page for display based on an identifier for the respective virtual web page.

[0120] Still further, according to some embodiments, the system may include an identifier for each virtual web page based on data elements stored in the 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 may 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] Furthermore, 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 a dynamic web page 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, 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 respective 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. and a back-end code executable by a back-end server remotely from the browser; 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, the association of the added data elements with at least one of the plurality of groups, and the modification of at least one of the front-end code and the back-end code. The method may include the steps of: a plurality of scrollable virtual web pages configured to be independently generated by at least one processor and independently edited by a user; and remotely providing to a browser fourth instructions for displaying a preview interface configured to display the plurality of scrollable virtual web pages prior to generation of a corresponding final web page, the preview interface enabling a user to selectively scroll across the plurality of scrollable virtual web pages based on each of a plurality of groups of at least one data element and to visualize how the 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 to the browser additional instructions 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 may 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 available to 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 may also comprise 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 a navigation interface based on each of the plurality of groups of at least one data element. The dynamic web page is configured to allow a user to selectively navigate across each of the multiple 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; scrolling sequentially through multiple web pages; and moving directly to a next, previous, first, last, bookmarked, or other particular 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 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 generated by a plurality of users, the hosting server including a hosted common editing tool accessible to the plurality of users to allow each of the plurality of users to selectively modify a particular website generated 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 generated by another of the plurality of users, and generating an interface for viewing 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 plugin code associated with plugins for the particular co-hosted website generated by the at least a subset of the plurality of users. the at least one processor configured to generate a plug-in code for the at least one particular plug-in, the plug-in code including 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 plug-in code uploaded by the user is centrally hosted at a common domain together with the co-hosted particular websites generated by the multiple users, the memory being such that a single instance of the at least one particular plug-in is shared by the multiple co-hosted particular websites, wherein for each of the multiple co-hosted particular websites sharing the at least one uploaded plug-in, the at least one processor performs, using the isolation mechanism:and 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 the plurality of co-hosted particular websites on the hosting server.

[0141] In 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 operate on a separate server from the hosting server. It may include an isolation mechanism that allows 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 a particular co-hosted website.

[0148] Additionally, according to some embodiments, the system may include a secure communication channel configured to restrict 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 can 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 webpage on which the front-end plugin functionality code is executed.

[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 the cookies associated with the 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 generated by a plurality of users; making available to the plurality of users a common editing tool to enable each of the plurality of users to selectively modify a particular website generated by each of the plurality of users; preventing at least some of the plurality of users from modifying the particular co-hosted websites generated 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 plugin code associated with plugins for the particular co-hosted websites generated by the at least a subset of the plurality of users, the plugin code for the at least one particular plugin comprising a front-end plugin function code executable by a client or a back-end plugin function code executable by a plugin server. 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 generated by the multiple users, wherein a single instance of the at least one particular plug-in is shared by the multiple co-hosted particular websites; and for each of the multiple co-hosted particular websites sharing 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 at a client or execution of back-end plug-in function code at 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 particular 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 a web page 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 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 of 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 description 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] [Diagram 2] FIG. 2 illustrates an exemplary online website building system according to some embodiments of the present disclosure.

[0168] [Diagram 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 back-end functionality, according to some embodiments of the present disclosure.

[0170] [Diagram 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 flow chart illustrating a method for developing back-end 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 components of various on-demand web server execution instance systems in accordance with some embodiments of the present disclosure.

[0175] [Figure 10] FIG. 10 is a flow chart 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 web sites 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 example 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 generation of test data for use in a test environment for testing websites, according to some embodiments of the present disclosure.

[0185] [Figure 19] FIG. 19 is a flow chart 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 flow chart 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 flow chart 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 flow chart illustrating a method for processing a read request 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 a data element 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 flow chart illustrating a method for deleting a data element from a test environment according to some embodiments of the present disclosure.

[0193] [Diagram 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 flow chart 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 an illustration of a timeline display of a dynamic refresh of a web page, according to some embodiments of the disclosure.

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

[0199] [Diagram 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] [Diagram 32] FIG. 32 is a schematic diagram illustrating relationships between data groups and websites according to some embodiments of the present disclosure.

[0201] [Diagram 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] [Diagram 34] FIG. 34 is a flow chart illustrating the steps involved in previewing a virtual web page according to some embodiments of the present disclosure.

[0203] [Diagram 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] [Diagram 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] [Diagram 40] FIG. 40 is a diagram illustrating client-side separate execution of plug-in code according to some embodiments of the present disclosure.

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

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

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

[0212] [Diagram 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] [Diagram 45] FIG. 45 illustrates an example user interface for editing web pages and displaying output from a database collection, according to some embodiments of the present disclosure.

[0214] [Diagram 46] FIG. 46 illustrates an example 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 example 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 PREFERRED EMBODIMENTS

[0216] In the following detailed description, many specific details are described to provide a thorough understanding of the exemplary embodiments of the present disclosure. However, it will be understood by those skilled in the art that the principles of the exemplary embodiments can 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 expressly stated, the exemplary methods and processes described herein are not constrained to a specific order or sequence, nor 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. Now, the embodiments of the present disclosure will be described in detail, examples of which are illustrated in the accompanying drawings. Unless expressly stated, transmission and reception as used herein should be understood to have a broad meaning, including transmission or reception in response to a specific request, or transmission or reception without such a specific request. Thus, these terms encompass both active and passive forms of transmission and reception.

[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] FIG. 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 in the website, databases, or similar data storage structures, code or data representing the website being built or under development, and data that is 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 repositories of.

[0219] The WBS editor 110 may be an editor for building and editing websites. The editor allows building websites and website pages starting from a blank canvas or based on pre-developed sites, site sections, or pages (collectively referred to as templates) that 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. Templates may define the web pages that belong to the website being built and their initial content. The WBS editor 110 may also include a UI section for determining the configuration of the site by defining the navigation between the various pages. The WBS editor 110 defines the layout of the pages by allowing the user to place components on the web page as they would like to appear on the actual web page.

[0220] In some embodiments, as described further below, the WBS100 can host websites and individual pages via virtual machines, container instances, or serverless code. These techniques can reduce 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 when the stateless server execution instance is first 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 further browser requests involving the same site. Additionally, it provides the advantage that the WBS100 can 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 WIX APP MARKET. Examples of widgets include simple widgets (text fields, shapes, etc.) or complex widgets (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 as 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 building tools 121 can include both component tools or widgets as described above, such as tabs, search bars, buttons, galleries, slide decks, etc., and manipulation tools, such as alignment tools. The building tools 121 may be represented as an abstraction of code representing jets and other tools. The building tools 121 may include public default tools provided to all users of the system and private tools provided only to a particular website or user. Private tools may include public tools or new tools customized for a user or website. Private tools may be created by a user of the system or a third party vendor building a website. The building tools 121 may be shared among multiple websites built and owned by different user groups. The building tools 121 may also be customized by editing the code of an existing building tool 121 (e.g., updating the style sheet of a button and creating a new style sheet for a new button). Custom building tools may be stored in the system area database 122 along with the original building tools 121.

[0224] The WBS editor 110 provides remote access to construction tools 121 stored in a system area database 122 of the WBS CMS 120. An instance of a selected widget in 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 construction tools 121 may be created with a reference to the widget in a page. An instance of a selected widget from 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 its 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, websites 123 are websites 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 may be accessed, updated, and displayed using the website development device 140. The websites 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 includes or references 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 (position, size, attribute values, etc.), which 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 store page metadata, titles, etc. 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 the user, instances that are displayed by default, or instances that are displayed at least some 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-interactional events, such as communications coming into the website 123, time-based triggers, or changes 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 devices 140 and the WBS vendor staff devices 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 are 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 location of the file 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 pages 125 are dynamic web pages and front ends 126 may be templates and not actual web pages. As described further below, dynamic web pages may be web pages configured to change appearance or content based on customized back-end functionality. Examples of customized back-end functionality, as described further below, include updating data displayed on a web page, resizing or changing images on a web page, triggering the rendering of video content on a web page, etc. In some embodiments, the front ends 126 of dynamic web pages may be templates 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 less of the components shown in FIG. 1. For example, databases 122 and 124 may be a single database or separate databases. The databases may be a distributed set of databases. Both databases 122 and 124 may be relational databases, object-oriented databases, data language file repositories (for languages ​​such as XML or JSON) or NoSQL databases. Additionally, databases 122 and 124 may be maintained in an on-premise network (e.g., a local area network with access to the internet), 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 , the websites 123 stored in the site area database 124 of the WBS CMS 120 may be accessed by a website viewing device 130 (e.g., a desktop computer, a tablet, a laptop, a smartphone, etc.) via a web browser 131. A user (not shown) of the website viewing device 130 may request access to the website 123 via a network 160 (e.g., the Internet, including intermediate networks between the website viewing device 130 and the WBS 100). The web browser 131 (e.g., APPLE'S SAFARI, GOOGLE'S CHROME, MOZILLA'S FIREFOX, MICROSOFT'S EXPLORER, etc.) of the web viewing device 130 may be used to view the websites 123 and data created and edited using the websites 123. The website development device 140 may be used to build the websites 123 using the WBS editor 110. The web browser 141 on the website development device 140 may be used to make a request to access the WBS editor 110 to build the website 123. WBS vendor staff devices 150 may be used to provide customer support for users (not shown) of website development devices 140 in building and maintaining website 123. WBS vendor staff devices 150 may also be used by third party vendors to create and customize building tools 121. WBS vendor staff devices 150 may also be used to configure WBS 100 itself, such as to manage accounts of site designers and users, manage site or page templates (such as creating new templates or editing existing templates) described above, or to manage various elements that comprise 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 may 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, and the like.

[0234] As shown in FIG. 1 , search engines 170 (e.g., GOOGLE, YAHOO, BING, etc.) can access indexable web pages 125 of websites 123 stored in site area database 124 via network 160, whether or not they interact with WBS 100. Search engine 170 indexes indexable web pages 125 of websites 123 for easy discovery, thereby increasing the number of users who use website viewing devices 130 to browse websites 123. In some embodiments, construction tool 121 further enables users to optimize websites 123 for indexing and searching via search engine 170. For example, construction 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 of indexable web page 125, or text that is associated (e.g., as metadata) with indexable web page 125. Allow them to choose.

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

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

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

[0238] The data elements 210 may be determined using a software-based router that analyzes a URL (or URL segment) entered by a user using a web browsing device 130 or otherwise provided to access a web page 125 of a website 123. Analysis of the URL by the software-based router may generate a key for accessing a data element 211 in a 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, the 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 directly entered by a user (e.g., URLs that are automatically generated by another page of the website or page-related code). The system also supports multiple concurrently defined software routers, and the website building system 100 performs initial sorting of received URLs. 2. The software router 200 performs an analysis to determine which of the defined software routers to use. Such analysis may be based on the received URL, on definitions contained in the URL association DB 220, or based on additional information or conditions (such as system environment 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 tools 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 tools 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., the second instructions 250 and the 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 construct 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 execution of backend code associated with a trigger, according to some embodiments of the present disclosure. As illustrated in FIG. 3, a trigger 310 may result in the execution of code associated with the backend 127. The trigger 310 may 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 particular action (e.g., mouse or touchpad click, selection, cursor hover, reload request, input of text, upload of multimedia content, etc.). The trigger 310 may also occur during non-interaction events. For example, periodic time-based actions or database updates may cause the triggering and execution of code in the backend 127 and / or frontend 127. The trigger 310 is customizable and may take many different forms. Additionally, interactions that need to result in the execution of code related to the backend 127 may occur via a programmable event 320. The programmable event 320 passes control to the backend 127 for execution via a hook that links the frontend 126 and the backend 127. The type of hook used to pass control between the programmable event 320 and the backend 127 may be configurable and may depend on the type of interaction or other type of event that caused the trigger 310. The programmable event 320 utilizes one or more of a data hook 330, a web hook 340, or a data binding router hook 350, among other possible types of hooks, to pass control to the backend 127 for executing code in the backend 127.

[0242] When data updates are entered by a user of the web browsing device 130 on an indexable web page 125 of a website 123 presented in a web browser 131, a data hook 330 can be used to pass control from a programmable event 320 to the backend 127. For example, a form submission can be considered a data update, and a data hook 330 can be used to pass control to the backend 127, where the backend 127 can receive and 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 pass control to the backend 127 programmatically 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 a programmable event 320 to the backend 127 when a web module function is imported and called in code that is part of the frontend 126. In some embodiments, for example, code that is part of the frontend 126 is referred to as a frontend script and is executed when a user of a web browsing device interacts with a frontend 126 component of an indexable webpage 125 of a website 123 displayed in a web browser 123. For example, webhooks 340 may be based on a user of the indexable webpage 125 utilizing an app, making a purchase, subscribing to content on the indexable webpage 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, the navigation may be by entering the URL in the address bar of the web browser 131, by clicking on a hyperlink in an indexable web page 125 of the website 123 displayed in the web browser 131, or by performing an action to automatically navigate 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 particular 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. And, in the URL http: / / www.wix.com / label / sub-label, "sub-label" can be the suffix. Based on the particular segment of the URL provided (e.g., the prefix, suffix, or parameter values), the router can determine that content associated with either or a particular web page associated with either 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 on the page. The router can also be used to generate complete virtual or dynamic pages based on the 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 The data hook 330 may function to pass control based on internal events following a user interaction with the website 123 at the time of the request. For example, a data binding router hook 350 may be registered to execute a function before determining routing to a page as described above to see if the user has permission to access the page to which the user is routed. The data hook 330 may possibly execute before or after the data binding router hook 350 for the same 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 the operation of various combinations of hooks, and the chaining of 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 of 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 of 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 the back end 127 may be displayed or represented together in an edit mode or in separate windows. In some embodiments, they may be displayed only one at a time. Also, the back end 127 may not be specific to the web page 125 or website 123 being displayed, and some or all of it may be shared between websites and developers of different websites. When the 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 pages 125 as they would appear in the real world, i.e., in the web browser 131 of the web viewing device 130 displaying the virtual web pages 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 a 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 includes a construction tool 121 and an index 4. In this exemplary diagram, the front end 126 displays a customizable web page 125. In this exemplary diagram, the 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, the front end 126 may be edited directly as code. In some embodiments, the building tools 121 are user interface sections within the unified interface 410. In further embodiments, the building tools 121 may be accessed by menu items in the online editor interface 243. In some embodiments, a particular website building tool selected from the building tools 121 may be dragged and dropped in the front end 126 section of the unified interface 410. The front end 126 of the indexable web page 125 shows the visual configuration of the 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 displayed at all times, 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 flow chart illustrating a method 600 for developing back-end 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 discussed above, examples of construction tools 121 include widgets, graphics, and other content.

[0257] In step 620, the WBS 100 transmits 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 via 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 transmitted 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 construction of the front end 126 and back end 127 of the web page 125.

[0258] In step 630, when the WBS 100 receives a request from the website development device 140 via the network 160 to use a tool in the building tool 121, the WBS 100 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, the WBS 100 may provide access to customized backend functionality 127 associated with the web page 123 for which the front end 126 is being edited or created. As mentioned above, the 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 WBS 100 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 the web browser 141. The user may edit the code, such as 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 back-end 127 functionality for the indexable web pages 125.

[0264] 7 is a flow chart illustrating a method 700 for triggering execution of backend code 127 in accordance with 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] As shown in FIG. 7, a user of the website viewing device 130 can trigger 310 a programmable event 320 associated with the backend 127 by either transitioning in the indexable web page 125 as shown in step 711, by the user of the website viewing device 130 interacting with the indexable web page 125 as shown in step 712, or by the user inputting 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 that is 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, This may include a period timer that results in an action, a database update, etc.

[0266] In step 720, upon receiving notification of the 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, data binding router hooks 350, etc. 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, WBS 100 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 may 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 the creation and editing of the code for each of these attributes of the customized backend function (e.g., the user is not required to code the entire function from scratch, but instead is 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. Additionally, as described below, 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] In general, 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 webpage (which may trigger additional HTTP requests to load additional page elements such as images or scripts, in some circumstances). 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 submitting a form. In addition, a user may make back-end HTTP requests, which may activate back-end functionality (e.g., via back-end 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 no user- or site-specific code. The system may then listen on a live port for requests to the server for a particular website. If there is a live container or other virtual computing resource associated with the 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 the 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-defined data (e.g., using an XML file or JSON representation) that is converted into browser-ready material by client-side or server-side code (such as a WBS Viewer module), or front-end or back-end code (e.g., JavaScript code called by the page to execute on the client, the server, or both).

[0272] Figure 8 illustrates a block diagram of an on-demand web server execution instance system 800 according to some embodiments of the present disclosure. As shown in Figure 8, the on-demand system 800 comprises a processor 260, a memory 820 for storing currently or recently served web sites, and a persistent storage 830 for storing all web sites 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 required to process a web site 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 web pages of the website on edit requests received from the web development device 140. A web server running instance is instantiated with the code and page definitions created and edited using the WBS editor 110 and stored in the site area database 124 for viewing the indexable web pages 125 during editing and at run time 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 pages 125 (when used for run-time services 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 convert the on-demand It should be made clear that the editor itself may function as a layer above the on-demand system 800 and does not directly affect its functionality and decisions (e.g., allocation of execution instances to handle incoming requests), although the editor may work in conjunction with the on-demand system 800.

[0274] Processor 260 may be associated with one or more servers hosting the 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.) can 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] The memory 820 may have one or more web server running instances for serving websites or pages to clients. The in-use instances 821 may be web server running instances that are currently or actively serving websites. The available instances 822, on the other hand, may be a set of web server instances available in the memory 820 that are not currently hosting a particular website but could. In some embodiments, the number of web server running instances in the available instances 822 may be a fixed number. In some other embodiments, the number of web server running instances in the available instances 822 may vary and depend on the number of web server running instances in the in-use instances 821. For example, if there are 10,000 total running instances, an increase in the in-use instances 821 may mean a decrease in the available instances 822 and vice versa. The number of web server running instances in the available instances 822 may also be a percentage of the number of web server running instances in the in-use instances 821. The in-use instances 821 may be represented in some embodiments by a data structure that includes a unique identifier that identifies the web server running instance 823 and other instances that are 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] The web server execution instance 823 may be one of the in-use instances 821 that processes requests to a website with the help of the web server. The web server execution instance 823 may include generic website server code 824 and website N specific code 833. For example, the generic website server code 824 may be common code included in all the web server execution instances. For example, such common code may include underlying web server execution instance system elements (operating system, web server (e.g., Apache), database server, etc.). In some embodiments, such common code may also include the WBS100 editor or runtime environment, along with common external services and plugins. 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 the WBS100 vertical applications. The common code may also include elements of common components of co-hosted websites (e.g., galleries), among others, 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 web sites may include different generic web site server code 824. Thus, for example, a commonly owned group of web sites may share a common generic web site 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 relate to all web pages within each website.

[0277] The website N specific code 834 may include code specific to a website or page served by the web server execution instance 823 (such as front-end 126 or back-end 127 code created by a 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 that includes 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, for example, shopping cart functionality, payment processing, database access, embedding or running 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 that can process 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 the 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, the common parts of multiple sites may also be included in the generic website server code 824, as described above.

[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 manner, 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] The persistent storage 830 may include code that is generic and specific to all websites hosted by the on-demand system 800 at a first storage location 831 and a second storage location 832, respectively. The generic website server code 824 may be stored in the persistent storage 830, for example, at the first storage location 831. The website-specific code 833 and 834 may be stored at the second storage location 832 and may be code specific to websites 1 and N, respectively. The 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), in various embodiments. The first storage location 831 and the second storage location 832 may be in different locations of the same storage system, or in different storage systems that together form the persistent storage 830. In some embodiments, the 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 memory 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 as well as any website specific code 833-834 may be incorporated to serve websites or pages that include common systems, web frameworks, libraries, components and plugins, 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 through an on-premise computer network, a cloud computer network, or a hybrid network including both architectures. Examples of cloud hosting environments may include AMAZON WEB SERVICES, MICROSOFT AZURE, IBM CLOUD, etc., as well as proprietary cloud networks maintained by website hosting companies.

[0282] The 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 the web browser 131 of the web browsing device 130. The proxy server 840 determines the availability of the web server execution instances, for example, by interacting with the memory 820. For example, the memory 820 may maintain a list of available instances 822 and in-use instances 821, may poll the web server execution instances 823 and 826 to determine their current status, and may receive other report information regarding the availability of the web server execution instances. In some embodiments, the 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 the web server execution instance 823. Additionally, in some embodiments, the proxy server 840 may maintain a status table 941 for use in determining the status of the 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 an on-demand system 800, according to some embodiments of the present disclosure. As shown in FIG. 2, a web server execution instance manager 950 of the on-demand system 800 manages the web server execution instances by communicating with the web server execution instances 823 and 826 and the proxy server 840. In some embodiments, the web server execution instance manager 950 may determine whether a new web server execution instance needs to be added to the available instances 822. This may occur, for example, when there is an increase in traffic associated with a particular hosted website or page. 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. The historical traffic information may include monthly, weekly, daily, and hourly traffic data collected to understand seasonal trends and other times when site usage is most active and to automatically add more web server execution instances serving a particular website. In some other embodiments, the web server execution instance manager 950 may determine whether an instance of the 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 is no request from a client to respond with a website or page. Thus, as described further 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, predictions such as those described above 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 a decision to add more instances to the set of available instances 822 and / or to mark instances of 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 further information (e.g., the time that the in-use instances 821 and available instances 822 have been hosting websites or pages, the time that the in-use instances 821 and available instances 822 have been inactive, etc.).

[0284] Figure 10 is a flow chart illustrating a method 1000 for responding to a web request sent for a website according to some embodiments of the present disclosure. The method 1000 of Figure 10 identifies two paths for processing a web request received by the on-demand system 800 coming from the web browser 131 of the web browsing device 130. The 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 the persistent storage device 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 code common 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 that specifies the common parts of different software layers, including operating systems, web frameworks, software libraries, and website components and plug-ins, and 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 the persistent storage 830. As described above, the website N specific code 834 may be specific to a particular website or web page. The website N specific code 834 may include, for example, a widget, an app, or custom back-end or front-end functionality. Additionally, the 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 a request by checking whether the requested website or page is currently being processed by one or more of the web server running instances of the in-use instance 821. As described above, this may include querying the in-use instance 821 itself, querying the 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, the on-demand system 800 checks whether the web server execution instance 823 or another web server execution instance within the in-use instance 821 serves the requested website. If yes, the process 1000 may, in some embodiments, jump to step 1070, described below.

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

[0290] In step 1060, the 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 the web server running instance 826. The 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 the web server running instance 826. Process 1000 may then repeat (e.g., repeat to steps 1010, 1020, or 1030). Additionally, in step 1060, the website specific code 833 may be injected into the 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 generate 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, the on-demand system 800 can receive a request for a website 123 over the 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 best serve the requested website 123. As discussed above, the determination may include identifying whether the request can be handled by a 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 of 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. Additionally, as discussed 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 based on, for example, 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 in-use instances 821 (to optimize response times) and, in parallel, decide to spin up one or more available instances 822 so that the 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 assist in determining how to handle the request to serve the website 123. This may include the types of decisions 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 instances of in-use instances 821 that may 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 the website because the on-demand system 800 may periodically monitor load levels based on historical website traffic trends and may automatically spin up or shut down web server running instances unless current traffic trends suggest otherwise. In some embodiments, the on-demand system 800 may periodically monitor load levels based on historical website traffic trends and may automatically spin up or shut down web server running instances unless current traffic trends suggest otherwise. The manager 950 redirects the request for the website 123 after failing to process the request, indicating that a web server execution instance is not available to process the request for the website 123.

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

[0298] In step 1124, the on-demand system 800 selects a web server running instance 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 rows with identifiers of 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 geographic proximity to the request location of the website 123, or the number of potential web requests that may originate from a particular geographic location. In some embodiments, multiple web server running instances may be 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 to the manner in which the user arrived at the site (e.g., using a software based router, etc.). In some embodiments, the injection step itself may modify the injected material, for example tailoring it to the particular user / platform / device making the request or other "environmental" conditions (country, language, database accessed, user access history, etc.). Network The client code initiating the request may add additional parameters or information to the network request to enable the injection module to perform such adaptation. 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] As shown in FIG. 12, the website 123 may be served through a web server execution instance by copying the website 123 specific code 833 into the 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 the front end 126, the back end 127, and the plug-in reference code 1226, as described above in connection with customized back-end functionality that may be provided at the 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, the 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, the code (e.g., 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 the execution of code, they can be charged in proportion to the actual execution of the code (not based on dedicated infrastructure costs or on the servers that must remain assigned to a given site while waiting for incoming requests). Alternatively, this can significantly reduce the costs of 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, etc.), memory-as-a-service capabilities (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 can alleviate issues with traditional website hosting systems (e.g., going through a "cold start" to load a machine or website instance). Start times for a website or page (including the running code) can be less than 100 milliseconds, which reduces latency and improves user experience. In contrast, some traditional systems have website or page start times of around 600 milliseconds to 2 seconds, including the functionality of scheduling overhead, instance startup, process startup (e.g., executing code), and request handler functions.

[0306] A website execution 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 it or available to it. Multiple containers 1221, virtual machines 1222, and processes 1223 can serve multiple websites. In some embodiments, a version of a website execution instance 826 that serves 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, and process 1223 that serves multiple websites must copy the site-specific code of the multiple websites to handle the various website requests.

[0307] 13 illustrates techniques for load monitoring of hosted web sites 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 of any of the web sites provided 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 loads may be predicted based on prior knowledge based on historical web site / collected periodic loads of the web servers hosting the web sites. Historical loads may include monthly, weekly, daily, and hourly so that seasonal trends and other times when site usage is most active can be understood and more web server execution instances serving a particular web site or group of web sites provided by the web server can be automatically added.

[0309] When a website is relatively lightly loaded, some instances are removed from the set of used instances 821 of a 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 in the proxy server 840. In other embodiments, the load monitor 1310 may be in the memory 820 of the on-demand system 800.

[0310] In some embodiments, the instances in use 821 may be a collection of a set of separate instances that host some or all of the websites of the on-demand system 800. In some embodiments, as shown, websites 123 and 2 are websites hosted by the on-demand system 800. In various embodiments, 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 to the website 1311 hosted by the proxy server 840. The load table of the load monitor 1310 may be updated based on the usage statistics of other websites. For example, for a multimedia heavy website, the usage statistics may include the usage of memory and processor cycles to process the website requests including converting video and audio to different formats based on the environment of the device used by the user. The web server execution instances of the busy instances 821 are moved to the available instances 822 when the load of the website they are hosting becomes lighter. Similarly, when the load of the website becomes heavy, the web server execution instances of the available instances 822 are marked as busy instances 821 and the website specific code of the website with heavy load is injected into these web server execution instances.

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

[0313] FIG. 14 illustrates monitoring of web server running instances available for hosting, according to some embodiments of the present disclosure. As shown in FIG. 14, a web server running instance manager 950 monitors the number of available instances 822. The web server running instance manager 950 may spin up new instances and add them to the pool of available instances 822 if the number of web server running instances in the set of available instances 822 is less than a threshold, as described above. The web server running instance manager 950 may conversely shut down instances in the set of available instances 822 if the number of web server running instances is greater than a threshold. These techniques for spinning up and shutting down running 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 an instance 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 deviates 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 ​​to exist for the number of available instances 822 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] FIG. 15 illustrates an exemplary website real-time testing system according to some embodiments of the present disclosure. As shown in FIG. 15, the website real-time testing system 1500 includes a processor 260, a memory 820, a site area database 124 for storing data used by the website, and a deployment environment 1510 that provides access to data related to the website being accessed. In some embodiments, the website real-time testing system 1500 may also include a test environment 1520 that provides 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 included entirely in website real-time testing system 1500. In some embodiments, website real-time testing system 1500 may consist in part 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] The test environment 1520 is a set of software components that run on a web server execution instance of the on-demand system 800. In some embodiments, the test environment 1520 is generated based on the type of device used to access the website. For example, a website 123 accessed via a web browser 141 on a web browsing device 140 may create a test environment 1520 that may have a different appearance and layout if the web browsing device 140 is a desktop computer or a mobile phone. In some other embodiments, the test environment 1520 may be generated based on which user is accessing the website. For example, a developer / designer 1540 requesting access to the website 123 may end up creating the test environment 1520. In some embodiments, the test environment 1520 may be shared between users. The test environment 1520 may be different for each user. In some embodiments, the test environment 1520 may be shared across multiple websites stored in the site area database 124. In some embodiments, an instance of the test environment 1520 is always available, and the developer / designer 1540 can choose whether to access a given website through the test environment 1520 or through the deployment environment 1510.

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

[0321] A developer / designer 1540 communicates with the test environment 1520 via a network 160. The developer / designer 1540 can access the website 123 through a web browser 141 on the website development device 140. In some embodiments, the developer / designer 1540 can access the website 123 in the deployment environment 1510 by using a web browser 131 on the web browsing device 130. It should be noted that the web browsing device 130 and the development device 140 may be the same device.

[0322] End user 1530 and developer / designer 1540 may be different roles of the same user accessing website 123. In some embodiments, a user may change roles by accessing website 123 using different devices. For example, a user accessing website 123 using WBS vendor staff device 150 or website development device 140 may be considered a developer / designer 1540. A user accessing website 123 using website browsing device 130 may be considered an end user 1530. A 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, a 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, a website may be accessed using deployment environment 1510 or test environment 1520 based on a combination of user and device type.

[0323] FIG. 16a illustrates 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 illustrates 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 live data 1610 and test data 1620. A developer / designer 1540 accessing a website 123 using the test environment 1520 can request a data element associated with an indexable web page 125 of the website 123. The test environment 1520 can be configured to receive a request for a data element from a user and can forward the request to the test data 1620. In some embodiments, test data 1620 may determine whether the requested data element is present in test data 1620 and 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 may access live data 1610 and test data 1620 after copying live data 1610 and test data 1620 to memory 820.

[0324] Figure 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 Figure 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 a data element associated with an indexable web page 125. In some embodiments, accessing a data element can include 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 a test environment 1520 for testing a website, 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 deleting data marked as deleted in data marked as deleted 1740 after adding data in test data 1620.

[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. When 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 may 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 the data 1730 marked as inserted may be selectively retained in the site area database 124. The 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 amount of time one of the data elements 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 disclosure.

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

[0330] In step 1920, live data 1610 stored in the site area database 124 associated with indexable web pages of the website accessed in the deployment environment 1510 is accessed by the website real-time testing system 1500 as part of serving 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 viewing 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 flow chart 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 the 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. Additionally, 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 a 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, the testing of the website is considered complete if the website is accessed through the test environment 1520 for a certain period of time. The test may be considered complete after a certain number of data requests. The test may also be considered complete when the developer / designer 1540 accessing the website through 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," the method 2000 may return to step 2010 and prepare to receive the next data request. If the answer to step 2030 is "yes," the 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 the developer / designer 1540 may, for example, request that the data changes incorporated in 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 removed.

[0336] 21 is a flow chart 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 at 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 may include a data group identifier (ID) that identifies a data element associated with a website being tested by the developer / designer 1540. The data group identifier (ID) may include a data element that is associated with the ...

[0339] In step 2121, the data request has been 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 was 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 has been 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 was 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 flow chart 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 the data request needs to be responded to and, if so, which data element of 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 the site area database 124 and memory 820 .

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

[0347] If the answer at step 2210 is no, the method 2100 may proceed to step 2130. As shown in FIG. 22, at 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 in test data 1620 and returned. 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 a data element for Contact 2 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 the live data 1610.

[0350] 23a is a flow chart 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. 23a, in step 2124, the received data request is determined in method 2100 to be a request to update a data element present in live data 1610 or data marked as inserted 1730 of test data 1620 during testing of a website.

[0352] In step 2310, the website real-time testing system 1500 determines the location of the data element for which an update is being 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, 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 includes adding a database entry and updating the data element through the test environment. This includes marking additional columns as having been 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 are testing 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 the 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 at 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 the query results, as described in process 2500 below.

[0362] 23c is a flow chart 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 that is not present in the live data 1610 to the test data 1620 during testing of a website in method 2100.

[0364] In step 2392, the website real-time testing system 1500 inserts the data element into the 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 the data marked as inserted 1730 of the test data 1620 from the test environment 1620 are not accessible to requests in the deployment environment 1610. For example, when the developer / designer 1540 requests to add a data element 1731 via the website 123, the data element 1731 may be inserted into the data marked as inserted 1730 of the test data 1620.

[0365] FIG. 24 illustrates a method for deleting a data element from a test environment in accordance with some embodiments of the present disclosure. 24 is a flow chart illustrating a method 2400 for deleting a data element that is requested to be deleted. As shown in FIG. 24, the data element 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 the site area database 124 or memory 820 .

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

[0368] In step 2420, a lookup of the data element requested to be deleted 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 a website 123 in a web browser 141 makes a request to delete a data element 1741, which causes the data element 1741 to be inserted in the data marked as deleted 1740. The absence of the 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 has not found the data element requested to be deleted 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 at step 2420 is yes, then the method 2400 has found the data element requested for deletion in the data marked as inserted 1730. At step 2440, the data element in the 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 the live data 1610, the data marked as inserted 1730, and the data marked as deleted 1740. In some embodiments, the data elements are accessed by running a query in the site area database 124 against the live data 1610 and the data marked as inserted 1730 and the data marked as deleted 1740 of the 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 of the live data 1610, the data marked as inserted 1730, and the data marked as deleted 1740 to select data elements to include in the test data 1620.

[0374] To determine which data elements to include in the test 1720, a pointer is set to the first element of the live data 1610, the data marked as inserted 1730, and the data marked as deleted 1740. In some embodiments, the pointer is placed to the youngest data element based on column "B". The youngest current records of the live data 1610, the data marked as inserted 1730, and the 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 of the live data 1610 and the data marked as deleted 1740 and have the same content.

[0375] Once the youngest data element is identified, it is determined whether the data element should be included in the test data 1620 based on the following rules: If the data element is present in both the live data 1610 and the data marked as deleted 1740, the data element is skipped from being included in the test data 1620. For example, data elements 2520 and 2530 have the same content and are present in both the live data 1610 and the data marked as deleted 1740, indicating that the data element was previously requested to be deleted in the test environment 1520 during testing of the website. It may also have been updated, with data element 2560 being the resulting updated element.

[0376] A data element is included in test data 1620 if the data element is only present in live data 1610. For example, data element 2540 is only present 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 the data marked as inserted 1730, it is included in the test data 1620. For example, data element 2540 is only present in the 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 of 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 of 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 above. Only the source with the youngest data element is filled in and displayed, while the rest are left 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 to indicate that it did not have a youngest data element. Similarly, in the last iteration, only data marked as inserted 1730 is shown in the last row of fusion table 2560. The youngest data element that can be used 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 FIG. 1, FIG. 2, FIG. 15, etc.

[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 a variety of different types of content or records of content that may be incorporated into the website, such as text, images, videos, 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 may define a set of one or more elements that are related. For example, a first website or page (e.g., a web page identifier) ​​may be associated with a group that includes only text, a second website or page may be associated with a group that includes data elements (each including one text and three images), and a third website or page may be associated with a group that includes data elements such as text and video. As described above, a user may identify groups of data elements to be displayed or associated with individual web pages of the website or a given virtual page template via the website editing interface.

[0382] Data groups, in some embodiments, may be site-level entities that may be used and reused across multiple pages of a website, or may be owner-level entities that may be used and reused by a particular website owner. Additionally, data groups may 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 storing 2604 the group of one or more data elements in a 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, if a user edits a virtual web page during preview mode, such edits are converted into edits to the database in real time, so that an up-to-date database of each web page is maintained.

[0384] In addition, the method 2600 may include a step 2606 of generating one or more virtual web pages. Each of the virtual web pages 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., are viewable by other users over the Internet). To then publish the virtual web page collection in a live mode, the user may select an option titled "Publish," "Post," or the like, which makes the website viewable over the Internet (as publishing is typically done at the site level, not on a single page). Once published, the virtual pages (i.e., instances derived from the web page template 2704) may behave similarly to ordinary (real) pages, despite being dynamically generated. Some In an embodiment, 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 a 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, each of five virtual web page templates corresponding to different types of rooms in the hotel may 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] The 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 only be editable in preview mode, as they may not be displayed as part of the normal editor page browsing and editing process. In an alternative embodiment, the system allows instances to be edited as part of the normal site editing process. A variety of 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, embedding widgets or apps (e.g., from an app store), inserting and editing buttons, creating and editing text, inserting and editing images, inserting and editing videos, creating and editing slideshows, cursor hover functionality, background styles, repeaters (e.g., for creating multiple versions of a particular data element or group), 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 the virtual web page templates and instances via the editing tools, which 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 a 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 (referring to 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 be configured to, for example, 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 (possibly a virtual web page) to display and what data elements to include on it.

[0388] In addition, method 2600 may include a 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. Each page is dynamically selected and viewed as a virtual web page.

[0389] The method 2600 may further include a 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 embedded in the page, URL prefixes or suffixes associated with the page, repeater functionality within the page, or software-based router functionality of 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 shall include adaptations to the virtual page instance. In such a scheme, the adaptations shall be indexed with 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., other than the content) of the virtual page instance, including layout, attributes, etc.

[0391] The method 2600 may also include a 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 allow viewing and editing of the underlying data groups and elements). Alternatively, such edits may be performed through editing of 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 videos, changing the functionality of hovering the cursor over an element, and various other types of edits.

[0392] Additionally, the method 2600 may include receiving 2620 edits to code associated with one or more virtual web pages. Examples of the 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 a database, creating dynamic pages, implementing user-facing widgets and apps, repeating layouts of data elements, configuring software-based routers, and the like. In some embodiments, in step 2622, a skeleton code segment 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 that may implement the various types of front-end and back-end functionality described above in a web page. The skeleton code may be displayed to the user via an editing interface and may be edited by the user. 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 the above page attribute and page data / field content edits, 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 of development changes prior to publication) or virtual page instances (which may be stored in a virtual page instance adaptation database). This is explained in more detail in the discussion of steps 2630 and 2634 below.

[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 may individually select pages by clicking on hyperlinks or other links associated with images or visual representations of the pages, or may 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 by steps 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, etc.), 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 pages and is associated with the content of the virtual web pages, edits to the virtual web pages may be associated back to the database used to construct them. In some embodiments, multiple versions of the database are stored, at least temporarily, so that a user can perform an undo or undo operation if they wish to void 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 be presented with a timestamp or version identifier associated with a previous version of the virtual web page to which edits can be reverted or resumed. Such version control systems may also support changes to a version of the development database that is 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, the 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 webpage along with updates made to the virtual webpage during the preview mode, including both the normal webpage and the instance of the virtual webpage, during a live view of the actual webpage associated with the virtual webpage. As discussed above, for example, a user may be able to edit numerous features of the virtual webpage during both template and instance preview modes (e.g., page structure, data elements, front-end code, back-end code, etc.). 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 fit database, and / or a separate code database on which the virtual webpage 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 webpage. In various embodiments, the virtual webpage and the actual webpage may be based on the same database(s) or on 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 is 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 FIG. 1, FIG. 2, FIG. 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 manipulated 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. Additionally, each virtual web page 2712 can be associated with a data element 211. Additionally, 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 a 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 can 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 can further include data elements 2714 and front-end code 2812, as described above. Additionally, the virtual web page 2712 can 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 can be received in one or more components of the website building system, such as the site area database 124. The display of the virtual web page 2712 allows a user to visualize the edits the user is making before the corresponding web page goes live. To publish the virtual web page 2712 in live mode, the 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 the virtual web page 2712, the edits may be refreshed in the site area database 124 and thus 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 the 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 may edit the virtual web page 2712. For example, as shown, the user may edit test tab 2 2904 to create edited tab 2. Additionally, a new data element 3 2906 may 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 may be made in the live environment 2908. For example, when a user selects a "Publish" or "Render" function, the live environment 2908 may 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 the edited tab 2 or tab 3, but a subsequent version of the actual web page 2912 may include these updates. In various embodiments, updates to the virtual web page 2712 may 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 once 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 supports static web pages and virtual web pages (i.e. 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 allows the navigation interface 242 to include scrollable functionality to allow a user to scroll through multiple virtual web pages generated for viewing in the preview interface 3010. The navigation interface 242 may allow both sequential navigation and direct access to a particular 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 particular 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 configurations of virtual pages beyond just a linear configuration. 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. A construction tool 121 included in the front end 126 may be associated with a particular data element 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. In the preview interface 3010, the virtual web page 3110 may be previewed as it appears on a variety of mobile and desktop devices, using different languages, adapted for 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] As shown in Figure 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 where the design or layout is repeated. In some embodiments, the repeater 3213 may be part of a virtual web page 3111 generated using a software-based router, as 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 may be directly associated with a data group subset 3213 of a data group 210. For example, repeaters may be used to create five different groups of text and images. Each group may automatically arrange the text and images in the same proportions and layout. Nevertheless, in some embodiments, the actual content of the text and images may differ 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 may be associated with data group 210 and other data groups, as well as indexable web pages. As described above, a software-based router 3310 may be used to bind data elements in data group 210 and applied to web page template 2704 to generate virtual web pages 3111, 3313, and 3312. The software-based router 3310 may select / filter / sort data elements in data group 210 to apply to web page template 2704 and virtual web page group based on a URL submitted by a 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 of data group 210 to be applied to web page template 2704 to generate a virtual web page based on a URL element (e.g., a suffix component, a text segment, or a parameter value) 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. Further, 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 embodiment, data groups can be defined before visual elements, fields, or particular 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 may be provided to a web browser displaying the online editor interface 243. In this manner, existing groups may be supplemented or edited to include different or additional elements. The user may repeat step 3420, returning at any time to add more data elements. Similarly, this step may include instructions for performing additional operations on the data elements, such as deleting or updating. For example, the user may cycle between steps 3410, 3420, and 3430, or may 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 the data groups stored in the site area database 124 with the website being edited in the online editor interface 243. The user may repeat step 3420, returning at any time to create further associations between web pages of the website under construction 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 together to both activate / deactivate and filter the potential values ​​allowed in the fields, as described above (e.g., a form for entering an address may have "city" field values ​​listed depending on the selection in the state field).

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

[0415] The user may repeat steps 3430, 3440, 3450, and 3460 any number of times and 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 hosting 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 web servers in on-demand system 800. Hosting server 3510 may also be WBS 100, storing websites edited and accessed by developers / designers 1540 and end users 1530, as described above.

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

[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 viewed 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 plugin 3530. For example, website 3511 can play videos via video player plugin 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 plugin 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 the hosting server 3510 through a shared platform 3580. The shared platform 3580 allows a group of users to edit a group of websites. The shared platform 3580 may be software configured to determine which groups of users 3540-3560 have access to edit which websites 3511-13. In some embodiments, the hosting server 3510, which hosts multiple websites 3511-13, may itself function as the shared platform 3580.

[0422] The end user's 1530 browsing of the website 3511 using the web browser 131 on the web browsing device 130 may include a user interface 3531 of the 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. The 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 the back-end plug-in code 3533 to be executed in the plug-in server 3520. For example, when an end user 3540 clicks on a playback control in a video player plug-in, the front-end plug-in code 3532 executes to make a request to stream the video, and the back-end plug-in code 3533 may further compress the video based on network bandwidth availability.

[0423] 36 illustrates a technique for controlled access to co-hosted websites according to some embodiments of the present disclosure. As shown in FIG. 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 access websites that are not part of an authorized group, but are not allowed to access websites that are not part of an authorized group. 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 differing from the other by URL root. For example, co-hosted website 3711 in common root 1 can share the domain www.a.com, and co-hosted website 3731 in common root 2 can share the domain www.b.com. Alternatively, co-hosted website 3711 in common root 1 can have a common sub-domain a.wixsite.com, and co-hosted website 3731 in common root 2 can have a common sub-domain b.wixsite.com. Websites with a common root can be co-hosted on a hosting server or hosting environment to create an isolated environment and eliminate interaction with other sets of co-hosted websites. The co-hosted websites can also have different plug-in servers to create isolated environments for running plug-in code. The co-hosted website 3711 of common root 1 and the co-hosted website 3731 of common root 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 of the 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 or a virtual machine 3820 or an operating system process 3830. In some embodiments, the isolation environment 3521 may include one or more containers 3810, virtual machines 3820, and operating system processes 3830 (e.g., serverless code), each executing a 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 allows 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 other specific sub-areas of the website. The secure communication channel may restrict access of the front-end plug-in 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 be denied access to sub-area 3940. The accessible sub-areas of the plug-ins may be listed in a tabular format, a trusted registry, a configuration file, or a 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., sub-domain 3910, sub-domain 3920, sub-domain 3940, etc.) and define their connection permissions. Such a list or mapping may allow certain connections or actions by sub-domain 3910, sub-domain 3920, and sub-domain 3940 and deny other connections or actions. In some embodiments, all communications go through one or more hubs (e.g., hubs that perform authentication or authorization checks). By allowing 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-domain initiating the communication. For example, a getId() method call may be used to identify the originating sub-domain ID of the communication message and determine if it is included in a permission 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 a front-end plug-in code 3532 of a plug-in 3530. The end user 1530 access may result in an iframe being created for the front-end plug-in code 3532 to run alone. In some embodiments, the front-end plug-in code 3532 may be copied to different subareas 3712-3713 of the website 3511 for running alone. 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 running in an iframe may not have access to client-side cookies (e.g., HTTP cookies).

[0427] FIG. 41 is a flow chart illustrating the steps involved in accessing and executing websites and plug-in code according to some embodiments of the present disclosure. As shown in FIG. 41, in step 4110, the website hosting system 3500 hosts websites that share one or more common data elements, templates, pieces 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, the 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 a user to edit various aspects of a website.

[0429] In step 4130, a user's effort to access a website for editing purposes causes the web hosting system 3500 to evaluate whether the user making the request 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 may use the editing tools 411 to provide administrative and / or editing access to other users. Additionally, in some embodiments, editing rights may depend on whether the user is a registered user or has been authenticated to access the web hosting system 3500.

[0430] If the answer in step 4130 is "no," the requested access to the website may be denied and the user may need to request editing privileges from an administrator of the website. Process 4100 is considered complete if access to edit the website cannot be obtained. Alternatively, process 4100 may cycle back to steps 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 the front-end or back-end code.

[0432] In step 4160, the website hosting system 3500 receives and stores the plugin changes. The user uploaded plugin 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 may edit plug-in code (eg, front-end plug-in code 3532 or back-end plug-in code 3533) over multiple sessions to allow 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). The execution of the plug-in code includes the creation of an isolation environment 3521 for executing the code. The isolation environment 3521 may include separation of the client side and server side 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, the web pages may be generated via a website development system such as that provided by WIX.COM. As shown, a database may 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 areas, courses by degree, and news), as well as options for public, back-end, and database features. Additionally, the toolbar 4204 may include various options for adding and editing content on the webpage.

[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. The 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 with the example above, a user creating a "course" database may set various different permissions for the database and corresponding dynamic pages that may be based on it. 310 options are accessible. Permissions 4310 may address content of the web page, data input 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 accessible only 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 comprised 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 4316). As shown, field 4416 contains an image corresponding to a course titled TING. In some embodiments, a user may further define a type or layout for 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] FIG. 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 dynamic web page created may include content from a database. As shown, content 4520 includes a course description 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 many dynamic pages, each linking to a different part 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 is 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 Lists & Grids option, which allows the user to create repeaters and various other elements that display multiple objects. To populate the repeater instances with content, a user can link the repeater or individual instances to a data set, such as data stored in a database. In some embodiments, the user may decide to add one 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: image, text (place name), text (description), and a "read more" hyperlink icon. In edit mode, the 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 discussed above, each element of the instance can be connected to a different portion of the database. For example, three combinations of elements 4724 can each be linked to a different column in the database that corresponds to the content to be respectively extracted from the database. In this way, the three combinations of elements 4724 have a common layout, but each has different textual or graphical 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 difference 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 communication interface that transmits data through the communication interface. A machine or computer readable storage medium causes a machine to perform the described functions or operations and includes any mechanism that stores information in a form accessible by a machine (e.g., computing device, 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 communication interface includes any mechanism that interfaces with any of the wired, wireless, optical, etc. media for communicating with another device, such as a memory bus interface, a processor bus interface, an Internet connection, a disk controller, etc. The communication interface may be configured by providing configuration parameters and / or sending a signal to prepare the communication 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 a system for carrying out the operations herein. The system 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 program may be stored on a computer-readable storage medium such as any type of disk including, but not limited to, floppy disks, optical disks, CD-ROMs, and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions, each connected to a computer system bus.

[0446] The 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 to 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 programming languages ​​such as 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, etc.). 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] Although 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 aspects of the 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 aspects of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall 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 Websites and Stateless Serving Architecture 1 System 2 of the present invention Use scenarios of the conventional system and the system of the present invention 3 Use of the system of the present invention in a WBS context 5 Acronyms used 6

[0451] Websites and Stateless Serving Architecture 1. When a user interacts with a website, they typically do not interact with BE code or a web server, but rather with client-side pages, web applications, and FE code running on the client machine / browser much of the time. However, this client-side website / application still makes multiple HTTP (or other) server requests. These may include, for example: 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 the submission of 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. A "server" in this context can refer to an actual physical server, but 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 request. 3. Users expect the system (client + server + communication medium) to be very responsive 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 100ms). The server-side measurement is used because it does not take into account network transmission times, which can be variable. 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 in the browser immediately, but the page may take significant additional time to load, and the user may begin interacting with the page before it has completely 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 a pre-allocated server. Such a server can provide a continuous session context, but this configuration is very difficult to scale up, since the server must be continuously associated with the user (or users) and can 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, may 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 for the response. 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 the existing system must be completely interchangeable and cannot be adapted to a specific website or related pages. Thus, 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 Invention 10. As described herein, the system of the present invention includes fast boot 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. Typically starting a new virtual machine takes several minutes. Starting a new docker container still takes 2-3 seconds. Both of these times are unacceptable. 12. 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 instruct it to load such content. 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 materials (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., the 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 (eg, 15 minutes), the system may drop the standby container. 17. To preserve the user state and preserve the user's sense of working within a single session (with continuous context), a persistent context is maintained using a combination of client-side storage (e.g. browser local storage, cookies, etc.) and server-side storage (e.g. saving to a server DB).

[0453] Use scenarios of conventional and inventive systems 18. Given 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, typically <form>Working locally in a browser running a local page with HTML tags. This can also be done using JavaScript or HTML setup that can initiate Ajax or Fetch calls or HTTP requests. 18.3. A form may make several requests during it that are sent to the server (e.g. getting a list of allowed values ​​from the 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 the code to the client). Such requests may be implemented as HTTP requests or using different mechanisms. 18.4. When a user submits a form, the form is validated by a FE script, it is then sent to the server, activating a server process that executes the associated BE code so that the form can (for example) be saved to a database. 19. In the above scenario, user activity is determined by HTTP requests or other mechanisms. Using the mechanism, a user might generate (say) 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 would 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 could not timely cold start a server, or even a VM or container, for each specific HTTP request (containing code specific to a given site), so they had to either support sites that did not have certain BE features, or keep a specific server instance running for the entire form-filling session (and thus 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 (say) 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 usage 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 (where most of the time 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 amount of resources (servers, containers, etc.). 24. Incidentally, because the user is working locally on the form, if the user closes and reopens the browser window, they will 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 in the browser's local storage. Thus, if the user closes and reopens a partially filled in form window, the reopened form will contain the previously filled in 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 long as needed (e.g., using the browser's local storage). 26. Also note that the injection of specific component code and associated FE / BE scripts is typically done site-wide (i.e. all special components and scripts used on all pages 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 (either from the same user or another user). 27. However, the system may implement different levels of granularity depending on the amount of "material" being populated, on the one hand, and on its usage pattern, on the other hand. Thus, the system may implement a populating granularity level of (for example) pages, page groups (i.e., site sections), sites, or site groups. For example, the case of site groups 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 populated. The container can then be reused to handle requests to any site in the group, not just a single 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. Editing a Site - A site definition (e.g. XML / JSON data, or DB records, or actual HTML page material) is edited by a visual editor application that typically runs in a browser with server support. Such a site may contain 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 may also invoke the site in preview mode. The editor may also support a publish operation to publish a version of the site for use by external users. 28.2. RT (Run-time) Mode - The system serves the published site to the user while activating FE or BE code as required. 29. The system of the present invention described above can be used in both the edit and RT modes 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 as in-memory structures client-side by the editor client (e.g. as a JSON representation). 30.1.2. The site's 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. Site's JSON / FE site code / BE site code is persisted in DB (if user explicitly saves it). 30.4. Temporary storage of FE / BE code is limited so that users can continue editing the same code via the container they are "moved" to. This is necessary because the FE / BE code of a site 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 doesn't 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 the current page. 32. When operating in runtime mode, the system operates as described above for serving normal websites. A WBS may have a viewer module (required for all sites edited with the WBS), and such a 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 the 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 at the bottom left of the editor. To show the sidebar, click the view icon at 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] Normal Page Regular pages on your site will appear just below the Pages section title. To change the settings for a page, click the settings icon that appears when you hover over the page name. 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 to see Click the settings icon shown. To change the settings of a page, such as its 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 name of the router prefix and related 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 the page section header.

[0461] Lightbox If you've added a lightbox to a page on your site, it will appear in the Lightbox section of your sidebar. This section is only visible if you've 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 in 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, click the settings icon that appears when you hover over the file name.

[0462] Backend The Backend section of the sidebar lists files that are not publicly accessible from your site. The Backend section is where you put code that you want to run server-side. You can create JavaScript files, web modules, and text files for use in the backend, and you can organize these files into folders. In the backend section of your site, there may be two special JavaScript files: the data.js file contains code for data hooks, and the routers.js file contains the router and data binding router hooks. It contains the code for 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, click the settings icon that appears when you hover over the file name.

[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 your collection, update a collection's 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 the Database Collection About the Router About Data Binding Router Hooks

[0465] Home>Wix Code>Wix Code Basics Use the Code Panel Visit the Wix Code Resource Center to learn more. · Click here to view this article 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 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 your site pages. There are two tabs on the left side of the code panel: 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 the 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 in 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, reference the elements using the same syntax as above, 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 that relates 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 statement" 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 allow you to use the element and add functionality to your site. After selecting an element, 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, a text element has an isVisible property that returns whether the element is actually visible on the screen. This property is read-only. A text element also has 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 an animation to the hide method by specifying it within the parentheses:

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 the following code to your site (we've added comments to explain each part of the code):

number

[0475] Warnings and Errors While writing code in the Code panel, you may encounter warnings and errors. Warnings appear in yellow and errors in red. These are manifested as a colored wavy line under the relevant code and an icon to the left of the line number. To view the warning or error message, hover over the icon.

[0476] caveat Warnings in your code are informational messages that draw your attention to code that you might want to change. Warnings don't 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 might not work as expected or might not run at all. Make sure you fix all errors in your code before you publish your site for your site visitors to use.

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 opens with

number

[0479] Test your code Although your code will run on your published site, it's a good idea to test your code before publishing 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 will 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 the Database Collection 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. So each item contains fields that are defined by the columns in the collection. 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. Give your collection a name. Note that you cannot change the name later. 3. By default, the "Site Content" collection permission preset is selected, which 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 you edit the live version in the Dashboard. Clicking the "Edit Live Data" link at the top of the screen will take you to the Dashboard's Content Manager.

[0485] Normal Field Each field in 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 your 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 the field are updated.

[0487] Field Key The field key is used when referencing the field in your code using the Data API or Dataset API. For example, to insert an item using the Data API, you would use the field keys: 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 desired. important: You cannot change a field key after you create the field.

[0488] Field types A field type defines what kind of data a field contains. When adding a new field in the Content Manager, you choose one of the following field types. Read here about field type support and limitations. ·reference ·text ·image ·Boolean Number Date and time Rich Text URL ·document Field types are also used when connecting page elements to fields in a collection. A particular input element can only be connected to fields of the associated field type. For example, a text element can be connected to a text or URL field, but not to an image field. The Content Manager will not let you add a new value for an incorrect 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 the 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 a best practice to ensure that each item has a unique value in the primary field. For more information, see About reference fields.

[0490] System Fields Every database collection contains the following default fields, which cannot be edited and are hidden by default: [Table 5] Values ​​for ID fields can be assigned when you add an item using the Data API or import new data from a CSV file, and cannot be changed afterwards. In all other cases, values ​​for these fields are generated automatically 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 contains the dynamic page's prefix 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 whose URL 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 content of a calculated field. However, if you change the URL of the 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 permission model allows you to 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 which 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 come into your site. You do this by configuring the router to receive all incoming requests with a specified prefix, then defining the logic to execute when a request with that prefix is ​​received. It determines what action to take, what 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 that is exclusive to them. · Return a custom HTTP response code. The API reference for the router can be found here.

[0495] URL prefix When you create a router, you decide which requests to route based on the URL prefixes you specify. Select whether to process a URL prefix with a URL prefix. 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 that is 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 rules: ·<router prefix> _router(request) ·<router prefix> _sitemap(sitemapRequest)

[0496] router() The router() function sends a page request with the defined prefix. The router receives a WixRouterRequest object that 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. We use this function to ensure that search engines can find links to your pages in the router. 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. You can access that data in your front-end page code using 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 describes 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 with example code for a simple routing scenario. The routers.js file is located 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] Example 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 are imported, as well as the WixRouterSitemapEntry object.

number

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

number

[0505] Router Function Note that all incoming requests with the URL prefix you specified when creating the router will be sent to the router for processing. You will handle these requests in the router() function. 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 with the ok() function, use 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 that 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 following this 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 than for regular pages. Learn more about SEO for Wix pages here. You can define a 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 pages. 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 the pages on your site. 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 their dynamically different versions, you should create a Sitemap that contains all the possible URLs that are 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. Inside 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 the 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 check 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 your site and retrieve the HTTP resource. > Advanced: Modules available for invoking the service

[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 this function:

number

[0514] Invoking 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. This avoids security concerns such as exposing API keys. For example, consider calling a third-party weather service to find the current weather in 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 choose a dynamic page type To add a dynamic item page To add a dynamic category page >Use dynamic page dataset settings Previewing a dynamic page Link to a dynamic page >Delete a dynamic page >How to convert between dynamic and normal pages Create dynamic page URLs >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 a single 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. You store the content on the page itself, but content for dynamic pages is stored in database collections. 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. You want to edit the content of your site without making any changes 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 a collection that all 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 your collection. You want to use this field to store the name of the recipe. You add a Meal field to your 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, you'll 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 meal 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 our dynamic item page. Note: This example illustrates 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 Page 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 with "<>") has not yet been placed on the page. For example, "<Recipe Title>" is just placeholder text for a text box where the actual recipe name will appear, and 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 of the placeholders has been replaced with specific information about the cupcake recipe, and how the images show cupcake images from the collection. Please pay attention to: On the same page, you can preview the Eggs Benedict recipe and see 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. Let's say you want to create a page that can display recipes based on the meals 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 can't 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 dynamic page URLs Making multiple dynamic page URLs unique About the Database Collection 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 or 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 affect 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 your collection. In general, hooks run regardless of whether an interaction with a collection is initiated by a page element or programmatically using the Data API. However, Data API calls from your site's back-end 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 a few different points in the lifecycle of a data interaction that you can hook into. Different hooks take 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 for example in afterQuery, the hook function will be called repeatedly, once for each item. · itemId: The ID value of the current item. query: The WixDataQuery object to be executed. · count: The number of items in the count. error: The error object. [Table 15]

[0525] Related content How 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 on the router page:

[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 can check who is requesting the page and based on the user 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 binds data but before the page is displayed. You can use this hook to change the router response based on the data you get. For example, you can have two versions of a page, one for portrait images and one for landscape images. After pulling the images from the database, you can display the page that corresponds to the image orientation.

[0531] afterSitemap() This hook is triggered after the sitemap is created. You can use this hook to modify the list of pages in the sitemap. For example, you can add 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 one, 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 Information settings for the page. 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 is located in the Backend section of the Site Structure sidebar. Data binding router hook functions are named according to the following convention:

number

number

Claims

1. 1. A non-transitory computer-readable medium for updating a back-end database including a data set to be populated on a plurality of web pages of a website, the computer-readable medium, when executed by at least one processor, comprising: 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 said at least one group of data elements in a database; generating a plurality of virtual web pages, each of which is a preview of a corresponding actual web page before the corresponding actual web page goes live, each of which is not designed with functionality for updating the database; displaying each group of at least one data element on a separate page of said 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; converting the edits of the virtual web page into updates for the database; storing the updates in the database; during a live view of a corresponding actual web page associated with the virtual web page, enabling the corresponding actual web page to be displayed with the updates made to the virtual web page during the preview; 23. A non-transitory computer-readable medium comprising instructions for causing the at least one processor to execute:

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

3. 2. The non-transitory computer-readable medium of claim 1, wherein the steps further comprise displaying user-selectable features that enable the user to navigate across the plurality of virtual web pages to individually and dynamically display each of the plurality of virtual web pages.

4. 2. The non-transitory computer-readable medium of claim 1, wherein said steps further comprise the step of displaying a user-selectable feature that enables the user to select a particular virtual web page from the plurality of virtual web pages based on an identifier of the particular virtual web page.

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

6. The non-transitory computer-readable medium of claim 1 , wherein said steps further comprise associating a unique URL with each of said plurality of virtual web pages.

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

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

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

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

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

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

13. The operation is accessing a software based router associated with the plurality of virtual web pages; 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 a received URL; The non-transitory computer-readable medium of claim 1 , further comprising:

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

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

16. 1. A computer-implemented method for updating a back-end database that includes a data set that populates a plurality of web pages of a website, the method comprising: 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 said at least one group of data elements in a database; generating a plurality of virtual web pages, each of which is a preview of a corresponding actual web page before the corresponding actual web page goes live, each of which is not designed with functionality for updating the database; displaying each group of at least one data element on a separate page of said 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; converting the edits of the virtual web page into updates for the database. and, storing the updates in the database; during a live view of a corresponding actual web page associated with the virtual web page, enabling the corresponding actual web page to be displayed with the updates made to the virtual web page during the preview; 4. A computer-implemented method comprising:

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

18. 17. The computer-implemented method of claim 16, further comprising displaying user-selectable features that enable the user to navigate across the plurality of virtual web pages to individually and dynamically display each of the plurality of virtual web pages.

19. 17. The computer-implemented method of claim 16, further comprising displaying a user-selectable feature that enables the user to select a particular virtual web page from the plurality of virtual web pages based on an identifier of the particular virtual web page.

20. 17. The computer-implemented method of claim 16, wherein the identifier of the particular virtual web page is based on a data element associated with the particular virtual web page.

21. 17. The computer-implemented method of claim 16, further comprising associating a unique URL with each of the plurality of virtual web pages.

22. 22. The computer-implemented method of claim 21, wherein each of the plurality of virtual web pages is generated based on a site map that references the unique URL of each of the plurality of virtual web pages.

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

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

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

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

27. The computer-implemented method of claim 16 , wherein the data elements are received from an external source via the user interface.

28. 1. A system for enabling dynamic editing of a web page to update a back-end database that contains a data set populated on the web page, the system comprising: an online database configured to store a plurality of data elements for display on a plurality of web pages, 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 a website, each separate web page having no functionality for updating the online database; At least one processor, remotely providing instructions to a browser for providing an interface displaying an editable version of the first web page generated based on the group of at least one data element, said interface allowing a user to edit said at least one data element; converting edits to the editable version of the first web page received via the interface into updates for the online database; storing said updates in said online database; enabling displaying the first web page with the updates made to the editable version of the first web page during a live view of the first web page; At least one processor configured to: A system comprising:

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

Images