Creating Physical Pages VS Single Page handles multiple URL Request
Permalink 1 user found helpful
I am facing an architecture decision of whether programmatically creating thousands of product pages under sitemap using addPage C5 API or extend c5_library_request class resolve different url request using a single page render page content.
Probably the first approach by writing a script for generating pages will benefit more from native concrete5 SEO, meta page attributes, sitemap generation and adding page tracking code etc. But the script is costly in terms of updating existing product page and adding new products (delete page, update template if product switch to another category and create new page)
second approach is easy for migrating large number of products to the site, won't have thousands page created under dashboard sitemap. But require customize sitemap generator, metadata update before page load, and html full page cache etc.
I'd like to know which approach will be better for a site contains 60000 + product pages under 4 levels of category structure.
Thanks in advance.
Probably the first approach by writing a script for generating pages will benefit more from native concrete5 SEO, meta page attributes, sitemap generation and adding page tracking code etc. But the script is costly in terms of updating existing product page and adding new products (delete page, update template if product switch to another category and create new page)
second approach is easy for migrating large number of products to the site, won't have thousands page created under dashboard sitemap. But require customize sitemap generator, metadata update before page load, and html full page cache etc.
I'd like to know which approach will be better for a site contains 60000 + product pages under 4 levels of category structure.
Thanks in advance.
You should contact hereNT. He has a slick addon for managing page types currently in the PRB that would be very useful should you decide to go with the multiple page solution. It may even be good enough to sway your decision :)
I think you would want to do is a bit tricky.
It seems like you want to not only import the products, but update them with content later? Like if something changes in a POS / Inventory tracker, it gets pushed to the concrete5 site?
So, you'd want a dashboard single page that goes through and imports everything from csv or xml or whatever. The api to actually create pages is pretty simple.
As you create each page, you could grab the cID of the page and the ID from the other system and put them in a custom table. Then when you need to update, you'd do something like spit out a csv with the records that have changed. Loop over that, grab the page object that goes with the ID from the other system, then update it.
If you do a custom page type with a controller, you could even easily make an updateSelf($data = array()) {} function on the page type, and just pass in the new values.
The problem might be how you want to search / organize / filter them. Depending on how that works, you might want to do 'category' pages, with an attribute for what they are. Then if the category of the product changes, the page is moved to the new category in that updateSelf() function. You would probably want to make sure that the old URLs are saved or turned into redirects or something, too.
Once you have the pages in, if they are set up in composer, then you could use something like my page manager, but it wouldn't push back to the other environment. So there you could have whatever metadata you want. Basically that's just a way to add dashboard pages that are similar to the built in page search, but specific to one particular page type.
The sitemap is not really going to do you much good for 60K pages, though. You're going to have to use page search or a manager of some sort if you are trying to keep track of them.
In the page type, you could also do things like use a package element for the display content, and use the category of the page to pick which template is included. Or you could do multiple different page types that inherit from the same core controller, but each have different update functions and view templates.
Dunno, there are a lot of different ways to do it, none are all that easy. I'd need more info to really tell you what, specifically you need to do, though.
I am going back to freelance at the end of the month, so if you wanted someone to consult and tell you how the architecture should be... ;)
It seems like you want to not only import the products, but update them with content later? Like if something changes in a POS / Inventory tracker, it gets pushed to the concrete5 site?
So, you'd want a dashboard single page that goes through and imports everything from csv or xml or whatever. The api to actually create pages is pretty simple.
As you create each page, you could grab the cID of the page and the ID from the other system and put them in a custom table. Then when you need to update, you'd do something like spit out a csv with the records that have changed. Loop over that, grab the page object that goes with the ID from the other system, then update it.
If you do a custom page type with a controller, you could even easily make an updateSelf($data = array()) {} function on the page type, and just pass in the new values.
The problem might be how you want to search / organize / filter them. Depending on how that works, you might want to do 'category' pages, with an attribute for what they are. Then if the category of the product changes, the page is moved to the new category in that updateSelf() function. You would probably want to make sure that the old URLs are saved or turned into redirects or something, too.
Once you have the pages in, if they are set up in composer, then you could use something like my page manager, but it wouldn't push back to the other environment. So there you could have whatever metadata you want. Basically that's just a way to add dashboard pages that are similar to the built in page search, but specific to one particular page type.
The sitemap is not really going to do you much good for 60K pages, though. You're going to have to use page search or a manager of some sort if you are trying to keep track of them.
In the page type, you could also do things like use a package element for the display content, and use the category of the page to pick which template is included. Or you could do multiple different page types that inherit from the same core controller, but each have different update functions and view templates.
Dunno, there are a lot of different ways to do it, none are all that easy. I'd need more info to really tell you what, specifically you need to do, though.
I am going back to freelance at the end of the month, so if you wanted someone to consult and tell you how the architecture should be... ;)
