I need to be able to serve different versions of my whole site per client. Certainly beta vs production but it would be nice to serve one or two prior production versions. Client customization is encouraged and I don't wish to force all clients to follow the (anticipated) pace of development.
Which version to serve is stored in the db.
From what Ive read so far a custom view engine may be the most straightforward way to accomplish this but before heading down this road I would welcome any advice and comment.
Thanks for insight!
Eric
EDIT: It isn't just the views that are different; controllers, master pages, images, CSS...
If the rules regarding which version is displayed to which user, I'm guessing they need to authenticate first. If that's the case you'll have opportunity to set a cookie on the user.
I would probably set a cookie on authentication that determines which version to show the user and then use a URL Rewriter like IIRF to direct requests with that cookie set to the beta version of the site.
Has the added benefit of users being able to opt back to the production site if they have issues with the beta.
I went down the view engine route How do I implement a custom RazorViewEngine to find views in non-standard locations?
Basically it's pretty stright forward, we have the same controllers models, etc. All the code is shared. The rendering of the views though is based on a "brand". So the view engine is clever enough to say if I'm brand A then the view will live in {standard view location}/brand/viewname.
It's hierachical though so if the view is in the branded folder it uses that one, else it falls back to the default location. It's basically an extension of the standard model used by MVC to find the location of the view source.
Related
I have a multi-tenant wagtail set up and we are currently working on getting up to date. We've just recently upgraded to v2.15 which introduced audit logging for all models instead of just page models.
AFAICT from looking through the wagtail code, the changes for a page model are only visible to superusers or admins with can_add_subpage or can_edit permissions which seems to effectively support multi-tenancy.
However, for all the other models there is no limitation put into effect. This means that an admin for Site A is seeing when changes are made to Site B or anytime a user is added or edited. We are using email addresses as usernames so this presents a rather major privacy issue.
This method hasn't been updated in any newer version, AFAICT, so I don't believe that just upgrading will fix this.
Does anyone have any ideas on either any wagtail settings we can change to keep Site and user changes invisible to non superusers or how we might localize BaseLogEntryManager.viewable_by_user so we can override the default wagtail implementation to our needs?
We have previously done something somewhat similar with the search available to admins by creating our own src/app/templates/wagtailadmin/pages/search.html and creating our own local version of https://github.com/wagtail/wagtail/blob/stable/2.13.x/wagtail/admin/views/pages/search.py
I had thought about trying to do something similar here however that doesn't seem like a good thing to do given how different those circumstances are and I think it was only possible using the register_admin_search_area hook.
I run a fairly large multitenanted Wagtail site. I have made public gist of the code we use in Wagtail 2.16 to restrict reports.
One of the main things we had to patch is the filters on the reports page. We do not want users on one site to even know there are other users in the system. This is implemented in the site_specific_get_users_for_filter method.
Although our non-page models all have site_ids, it was not possible to filter ModelLogEntries in site, so we settled for hiding that report from everyone except superusers.
I have a web application in Laravel 7 and Vuejs2 which have some pages like home, about, cities and help. these page need to be crawled by search engines.
I have tried both ways, prerendering and server side rendering without success.
for pre-render there is only one package prerender-spa-plugin which is very old and not updated since 5 years.
server-side-rendering is also difficult because my web app is already designed and is going to production, it is hard to implement that now, and also not recommended to implement server-side-rendering because of 5 pages.
any suggestion are appreciated to make these 5 pages crawelable by search engine.
update:
my application contain other pages and components which do not need to be SE optimized, pages like user account and profiles.
Overall, I recommend the usage of Nuxt if you want something that could deliver a professional experience, on top of managing all the flexibility that you wish to have with an SSR/SSG tool.
Here is a more detailed answer regarding your currently available tools to achieve some SEO-crawlabale content: https://stackoverflow.com/a/69075962/8816585
You mentioned that you wished to keep some pages as SPA-only, this is also feasible thanks to the generate.exclude key of the configuration: https://stackoverflow.com/a/66472634/8816585
I am new guy to Demandware and I am switching from Magento to Demandware.
Demandware is not opensource I am not getting proper tutorials, stuff to understand the concepts of it.
I am from Magento so I know the Magento MVC structure.
But in Demandware we have different concepts like pipelines, pipelets, ISML scripts, ECMA script, DW scripts etc.
I want to know the MVC pattern of Demandware.
How it works and what are the basic concept I need to concentrate?
I would suggest to request a Demandware XChange account as soon as possible for you, so that you get access to the Demandware community portal and also to the API documentation.
In short:
Models are Demandware Forms and Demandware API objects
Controllers are Demandware Pipelines (there are JavaScript Controllers that are recently released, you may find these easier to understand if you have Node.js experience). These can call DW Scripts (DemandwareScript is based on ECMAScript standard 5.0 for JavaScript with some extensions like E4X and optional types)
Views are the isml templates. You should avoid including a lot of logic in them, either with isml tags like isif, isloop, etc. or with isscript.
Any further questions - let me know.
Hope this helps,
Zlatin
I hope you'll be able to avoid pipelines and dwscript. Those are a bit older. The most recent version works with plain old JavaScript, with pipelines being replaced by controllers.
Be aware that the underlying JavaScript engine is Rhino, which isn't really modern.
The Demandware documentation is open source now anyone can access to without having an exchange account it has the latest SFRA(javascript) based concepts as well
here is the link for the docs
Demadware Documentation
Demandware is very much designed around the MVC concept (in theory). The pipelines are basically your controllers and each pipeline filename (the xml file) is the first part of the URL and the start nodes inside the pipeline are the second part of the URL that basically represent the controller (eg Cart.xml has a start node called Show, so the url is Cart-Show). At the end of the pipeline flow chart is, usually, an interaction node to that links to an ISML file, those are basically the View and are HTML with some minor Demandware-specific markup.
Typically in the MVC world you try to prevent putting business logic in the views, however if you use SiteGenesis as your starting point you'll find that not to be the case on most of the pages. If you switch to using Javascript Controllers instead of Pipelines, then it'll be closer to the Magento style of MVC (but using NodeJS-like syntax).
I don't even know if this is even possible, but I thought I'd ask.
I am creating a small CRUD application but I have multiple sites. Each site would use the CRUD. The application would have common CRUD methods and style, but each individual site would apply different forms. I want to avoid creating multiple CRUD applications that varied only in specific content (just different forms).
I want to have something like this:
mycrud.website1.com
mycrud.website2.com
mycrud.website3.com
I can create a subdomain for each individual site no problem. But is it feasible to point all the subdomains to one MVC application directory? And if it is possible any suggestions for how I might go about restricting users from website1 from seeing website2 or website3 content? Is that something "roles" could take care of (after authenticating user)?
Thanks.
There are a lot of websites that do this, not just with MVC. Some content farms point *.mydomain.com to a single IP and have a wild card mapping in IIS.
From there, your application should look at the URL to determine what it should be doing. Some CMS systems operate in this manner, using the domain as a key to deciding what pages to load.
I've built a private labelable SAS application (Software as a Service) that allows us to host all of our clients in a single application. Some clients have customizations to pages or features. We are able to handle that by creating custom plugins for each client that over-ride the Controllers or Views when needed.
All clients share a common code base and aside from each clients custom theme/template they are the same. Only when a client had us customize one feature did we need to build out their plugin DLL. Now, this is advanced stuff so it would require heavy modifications to your code base but in the end if it's what your application needs it is 100% possible.
First - the easy part is having one web site for all three domains. You can do that simply with DNS entries. No problem. All three domains should point at the same ip.
As far as the content, you could do that in a number of ways. I think your idea of roles is pretty solid. It also leaves open the possible of a given user seeing content from both site1 and site2, if that would ever be necessary.
If you don't want to force users to authenticate, you should look at other options. You could wrap your CRUD logic and data access logic into separate libraries and use them across three different sites in IIS. You could have one site and display content based on the request URL. There's probably a lot of other options too.
I come from a background of coding my client website projects from scratch with MySQL and PHP. They are typically public facing sites with a mixture of static content, dynamic content plus a little functionality here and there (i.e. account, searching etc). Nothing too heavy.
So I generally code up a little CMS site to let them update what they need to, put it in a protected folder and that's that.
Now I'd like to use CodeIgniter and more of a MVC approach for my next site. Should I be doing anything to separate the CMS out from the rest of the site or is it simply another area (with its own controllers/models etc) and extra authentication?
There are several good methods to create an admin interface in CodeIgniter described at:
http://philsturgeon.co.uk/news/2009/07/Create-an-Admin-panel-with-CodeIgniter
You probably will want to look mostly at "#2" on his list; it's lightweight and not much additional work.
The CMS is part of the site, if by CMS you mean administration panel / backend of your application, you can use the above link provided by coreylink as it details different ways to create an admin panel.
My personal preference is to create a folder called 'admin' in my controllers directory and create semantically meaningful names so my urls are webapp.com/admin/users and so on.