CMS rendering method and equipment

By building a CMS rendering platform and distinguishing the types of processing user access, memory fragmentation, low performance and security risks in the CMS rendering method are solved, and efficient rendering and customized effects are achieved.

CN120407978APending Publication Date: 2025-08-01HUBEI GUOLING COMPUTER TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510297440.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-03-13
Publication Date
2025-08-01

AI Technical Summary

Technical Problem

The existing CMS rendering methods have problems such as memory fragmentation, poor performance, limited customization and security risks.

Method used

By building a CMS rendering platform, including Git server, renderer, browser simulator, render trigger rule analyzer, URL rule management module and content management module, we receive instructions in real time and distinguish between real user access and crawler access, generate static pages or update content, and use Nginx routing for static file detection and cache, and improve rendering efficiency.

Benefits of technology

It effectively avoids system vulnerabilities, improves page rendering efficiency, saves resources, enhances system security, and meets customized needs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120407978A_ABST
    Figure CN120407978A_ABST
Patent Text Reader

Abstract

The invention provides a CMS rendering method and device, and relates to the field of webpage rendering, and the method comprises the steps: S1, constructing a CMS rendering platform, uploading a template to the CMS rendering platform, and generating a page and content; s2, the CMS rendering platform receives an instruction in real time, if a page and content change instruction is received, the step S3 is executed, if a real user access instruction is received, the step S4 is executed, if a crawler access instruction is received, the step S5 is executed, and otherwise, the step S2 is repeated; s3, updating the page or updating the content, and returning to the step S2; s4, displaying the page and the content, and returning to the step S2; and S5, displaying the special static page, and returning to the step S2. According to the method, the real user access instruction and the crawler access instruction are distinguished, only the special static page is displayed for the crawler access instruction, resources are saved to serve the real user access instruction, and the page rendering efficiency is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of web page rendering, and particularly to a CMS rendering method and device. Background Art

[0002] The defects existing in the current CMS rendering methods mainly include memory fragmentation problems, low performance, limited customization, and security risks, etc.

[0003] 1. Memory fragmentation problems:

[0004] When using CMS for garbage collection, memory fragmentation may occur. These fragments will affect the efficiency of new object allocation and promotion operations, and may even lead to frequent Full GCs, thus affecting the responsiveness of the system.

[0005] 2. Low performance:

[0006] Some CMS frameworks or systems have low performance when processing a large amount of data due to poor code optimization and redundant database design. This not only slows down the website speed but also seriously affects the user experience.

[0007] 3. Limited customization:

[0008] Although the CMS framework provides certain customization functions, it is still limited in terms of functions and design and cannot fully meet the needs of all users. This may lead to a lack of uniqueness in the functions and appearance of the website.

[0009] 4. Security risks:

[0010] The wide use of the CMS framework makes it vulnerable to hacker attacks. Some CMS systems have frequent system vulnerabilities due to low code quality and lack of timely updates and maintenance, increasing the risk of website data being stolen or tampered with. Summary of the Invention

[0011] In view of this, the purpose of the present invention is to provide a CMS rendering method and device for solving problems such as memory fragmentation, low performance, limited customization, and security risks existing in the current CMS rendering methods.

[0012] The present invention provides a CMS rendering method, including the steps of:

[0013] S1: Construct a CMS rendering platform, upload a template to the CMS rendering platform, and generate a page and content;

[0014] S2: The CMS rendering platform receives instructions in real time. If it receives instructions for page and content changes, it proceeds to step S3; if it receives instructions for real user access, it proceeds to step S4; if it receives instructions for crawler access, it proceeds to step S5; otherwise, it repeats step S2.

[0015] S3: Update the page or the content and return to step S2.

[0016] S4: Display the page and the content and return to step S2.

[0017] S5: Display a dedicated static page and return to step S2.

[0018] Preferably:

[0019] The CMS rendering platform includes: a Git server, a renderer, a browser simulator, a rendering trigger rule analyzer, a URL rule management module, and a content management module.

[0020] Preferably, step S1 is specifically as follows:

[0021] S11: Push the template to the Git server.

[0022] S12: The CMS rendering platform deploys the template to the page area.

[0023] S13: The Git server notifies the renderer.

[0024] S14: The renderer obtains all columns, texts, and single pages from the content management module, and generates the URLs of each page according to the URL rules provided by the URL rule management module.

[0025] S15: The renderer sends each URL to the browser simulator for individual requests.

[0026] S16: The browser simulator designates the successfully requested URL as the specified URL. When it receives the page load completion instruction, it reads the current DOM and sends the specified URL and the current DOM to the renderer.

[0027] S17: The renderer stores the received current DOM as a plain text file with the specified URL and uses the plain text file as the content.

[0028] S18: The browser simulator summarizes the Api requests that occur during page rendering and sends the summarized Api requests to the rendering trigger rule analyzer.

[0029] S19: The rendering trigger rule analyzer analyzes the content and columns on which the specified URL depends and generates the page.

[0030] Preferably, step S3 is specifically as follows:

[0031] S31: After receiving the change instruction for the page and content, the rendering trigger rule analyzer reads the dependency relationship and obtains the page range that needs to be regenerated;

[0032] S32: The rendering trigger rule analyzer sends the new URL to the renderer;

[0033] S33: If the change instruction is to update the page, the renderer performs the page update operation;

[0034] S34: If the change instruction is to update the content, the renderer performs the content update operation;

[0035] S35: If the change instruction is completed, return to step S2; otherwise, return to step S31.

[0036] Preferably, the specific operation of the renderer for performing the page update operation is as follows:

[0037] The renderer converts the new URL into a new page in the manner of steps S15 to S19.

[0038] Preferably, the specific operation of the renderer for performing the content update operation is as follows:

[0039] The renderer converts the new URL into a new content in the manner of steps S15 to S17.

[0040] Preferably, step S4 is specifically as follows:

[0041] Generate an Api request, and obtain the static files corresponding to the page and content according to the Api request,

[0042] Detect the static files through Nginx routing; if an Api response static cache exists for the detected Api request, display the static files; otherwise, perform an Api service dynamic response.

[0043] A CMS rendering device includes: a processor and a storage medium; the processor loads and executes the instructions and data in the storage medium to implement the CMS rendering method described above.

[0044] The present invention has the following beneficial effects:

[0045] After receiving the instruction, the CMS rendering platform updates the page content, avoiding system vulnerabilities caused by untimely updates; distinguishes and processes real user access instructions and crawler access instructions, and only displays dedicated static pages for crawler access instructions, saving resources to serve real user access instructions, and improving the rendering efficiency of the page. Description of the Drawings

[0046] Figure 1 It is a flowchart of the method of the embodiment of the present invention;

[0047] Figure 2 This is the structural diagram of the device according to the embodiment of the present invention;

[0048] The implementation, functional features and advantages of the present invention will be further described with reference to the embodiments and the accompanying drawings. Specific embodiments

[0049] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0050] Refer to Figure 1 , the present invention provides a CMS rendering method, including the steps:

[0051] S1: Build a CMS rendering platform, upload the template to the CMS rendering platform, and generate pages and content;

[0052] As an embodiment

[0053] The CMS rendering platform includes: a Git server, a renderer, a browser simulator, a rendering trigger rule analyzer, a URL rule management module, and a content management module.

[0054] Specifically, the Git server is used to upload templates and record template versions.

[0055] The renderer is used to manage and trigger the generation process.

[0056] The browser simulator is used to simulate client requests and render Vue pages.

[0057] The rendering trigger rule analyzer is used to analyze the dependency relationship of a page on specified data by analyzing the column / content / single-page API requested by a certain page. When the specified data changes, it triggers the generation of SEO static pages.

[0058] The URL rule management module sets the URL rules for column pages, content pages, and single pages (home pages), so that the system knows which URL is used to access each column and content in the template.

[0059] The content management module is used to provide an enumerated data source for columns, content, and single pages in the rendering process, and also provide specific page content.

[0060] As an embodiment

[0061] Step S1 is specifically:

[0062] S11: Push the template to the Git server;

[0063] S12: The CMS rendering platform deploys the template to the page area;

[0064] S13: The Git server notifies the renderer;

[0065] S14: The renderer obtains all columns, texts, and single pages from the content management module, and generates the URLs of each page according to the URL rules provided by the URL rule management module;

[0066] S15: The renderer sends each URL to the browser simulator for individual requests;

[0067] S16: The browser simulator uses the successfully requested URL as the specified URL. When receiving the page load completion instruction, it reads the current DOM and sends the specified URL and the current DOM to the renderer;

[0068] S17: The renderer stores the received current DOM as a plain text file with the specified URL and uses the plain text file as the content;

[0069] S18: The browser simulator aggregates the Api requests that occur when rendering the page and sends the aggregated Api requests to the rendering trigger rule analyzer;

[0070] S19: The rendering trigger rule analyzer analyzes the content and columns on which the specified URL depends and generates a page.

[0071] S2: The CMS rendering platform receives instructions in real time. If it receives instructions for page and content changes, it enters step S3. If it receives real user access instructions, it enters step S4. If it receives crawler access instructions, it enters step S5. Otherwise, it repeats step S2;

[0072] Specifically, when a real user accesses, Nginx routes to the Vue template, and then Nginx performs static file checks for Api requests. If a corresponding Api response static cache is detected for the Api request, the static file is returned. Otherwise, the request is routed to the Api service for dynamic response. Thus, pure static access is achieved in most cases.

[0073] When Nginx detects a crawler, it directly returns the SEO - specific static page of the corresponding URL. Since crawlers focus on the data in the page rather than the display effect, although the SEO - specific static page cannot fully restore the display effect, it has achieved the purpose of SEO.

[0074] S3: Update the page or the content, and return to step S2;

[0075] As an embodiment

[0076] Step S3 is specifically as follows:

[0077] S31: After receiving the page and content change instructions, the rendering trigger rule analyzer reads the dependency relationship and obtains the page range that needs to be regenerated;

[0078] S32: The rendering trigger rule analyzer sends the new URL to the renderer;

[0079] S33: If the change instruction is to update the page, the renderer performs an update page operation;

[0080] S34: If the change instruction is to update the content, the renderer performs an update operation;

[0081] S35: If the change instruction is completed, return to step S2; otherwise, return to step S31.

[0082] As an example

[0083] The renderer performs the following operations to update the page:

[0084] The renderer converts the new URL into a new page according to steps S15 to S19.

[0085] As an example

[0086] The renderer performs the following operations to update the content:

[0087] The renderer converts the new URL into new content according to steps S15 to S17.

[0088] S4: Display the page and content, and return to step S2;

[0089] As an example

[0090] Step S4 is specifically as follows:

[0091] Generate an API request and obtain the static files corresponding to the page and content according to the API request.

[0092] Static files are detected through Nginx routing; if it is detected that there is an API response static cache for the API request, the static file is displayed; otherwise, the API service dynamic response is executed.

[0093] S5: Display the dedicated static page and return to step S2.

[0094] Specifically, what is finally generated is a SEO-specific static page and an API response static cache, which means storing the API response in a plain text file.

[0095] See Figure 2 , Figure 2It is a schematic diagram of the operation of the hardware device according to an embodiment of the present invention. The hardware device specifically includes: a CMS rendering device 401, a processor 402, and a storage medium 403.

[0096] A CMS rendering device 401: The CMS rendering device 401 implements the CMS rendering method.

[0097] Processor 402: The processor 402 loads and executes the instructions and data in the storage medium 403 to implement the CMS rendering method.

[0098] Storage medium 403: The storage medium 403 stores instructions and data; the storage medium 403 is used to implement the CMS rendering method.

[0099] It should be noted that in this article, the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or system. Without more limitations, the element defined by the statement "including one..." does not exclude the existence of additional identical elements in the process, method, article or system including that element.

[0100] The serial numbers of the above embodiments of the present invention are only for description and do not represent the advantages or disadvantages of the embodiments. In the unit claims listing several devices, several of these devices may be specifically embodied by the same hardware item. The use of the words first, second, and third does not indicate any order and these words can be interpreted as identifiers.

[0101] The above is only the preferred embodiment of the present invention, and does not limit the patent scope of the present invention. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present invention, or directly or indirectly applied in other related technical fields, is equally included in the patent protection scope of the present invention.

Claims

1. A CMS rendering method, characterized in that, Including the steps: S1: Build a CMS rendering platform, upload the template to the CMS rendering platform, and generate pages and content; S2: The CMS rendering platform receives instructions in real time. If it receives an instruction to change the page and content, it proceeds to step S3. If it receives an instruction for real user access, it proceeds to step S4. If it receives an instruction for crawler access, it proceeds to step S5. Otherwise, it repeats step S2; S3: Update the page or update the content, and return to step S2; S4: Display the page and content, and return to step S2; S5: Display a dedicated static page, and return to step S2.

2. The CMS rendering method according to claim 1, wherein: The CMS rendering platform includes: a Git server, a renderer, a browser simulator, a rendering trigger rule analyzer, a URL rule management module, and a content management module.

3. The CMS rendering method according to claim 2, wherein Step S1 is specifically: S11: Push the template to the Git server; S12: The CMS rendering platform deploys the template to the page area; S13: The Git server notifies the renderer; S14: The renderer obtains all columns, texts, and single pages from the content management module, and generates the URLs of each page according to the URL rules provided by the URL rule management module; S15: The renderer sends each URL to the browser simulator for one-by-one requests; S16: The browser simulator takes the successfully requested URL as the specified URL, reads the current DOM when it receives the page load completion instruction, and sends the specified URL and the current DOM to the renderer; S17: The renderer stores the received current DOM as a plain text file with the specified URL, and takes the plain text file as the content; S18: The browser simulator summarizes the Api requests that occur when rendering the page, and sends the summarized Api requests to the rendering trigger rule analyzer; S19: The rendering trigger rule analyzer analyzes the content and columns on which the specified URL depends, and generates a page.

4. The CMS rendering method according to claim 3, wherein Step S3 is specifically: S31: After receiving the instruction to change the page and content, the rendering trigger rule analyzer reads the dependency relationship to obtain the page range that needs to be regenerated; S32: The rendering trigger rule analyzer sends the new URL to the renderer; S33: If the change instruction is to update the page, the renderer performs the page update operation; S34: If the change instruction is to update the content, the renderer performs the content update operation; S35: If the change instruction is completed, return to step S2. Otherwise, return to step S31.

5. The CMS rendering method according to claim 4, wherein The renderer performs the page update operation specifically as: The renderer converts the new URL into a new page in the manner of steps S15 to S19.

6. The CMS rendering method according to claim 4, wherein The renderer performs the content update operation specifically as: The renderer converts the new URL into new content in the manner of steps S15 to S17.

7. The CMS rendering method according to claim 1, wherein Step S4 is specifically: Generate an Api request, obtain the static file corresponding to the page and content according to the Api request, Detect the static file through Nginx routing; if an Api response static cache exists for the detected Api request, display the static file; Otherwise, perform an Api service dynamic response.

8. A CMS rendering device, characterized in that: Including: A processor and a storage medium; the processor loads and executes instructions and data in the storage medium to implement the CMS rendering method according to any one of claims 1 to 7.