Due to the fact that I am using the OWIN authentication, I had to put the cms on a different website. The cms is at cms.domain.com and in my VS project for domain.com I simply pointed the "piranha" connection string to the right database. So far everything was working perfectly, I only had to change the MediaProvider do deal with the domain name issues for the 2 retrieve methods of IMediaProvider.
Now I'm trying to integrate the menu using the #UI.Menu helper, however it looks like the helpers are not using the database of the Web.Config file (I have no problem to retrieve posts from C#). I only see the Start page listed. To confirm it I have also tried to change the site description from cms.domain.com/manager and to display it with the helper #Site.Description but it still shows default site description so it really looks like there is another database around..
Where does data used by the HTML helpers come from? And How can I fix that?
UPDATE : It seems that it is actually a caching issue, it has nothing to do with the connection string.
Piranha CMS caches a lot of meta-data for performance and to minimize the round-trips to the database. The site information, as well as the sitemap is two of these things as these will most likely be used in every page-rendering.
The default cache implementation uses the IIS cache, which is per application pool. The cache is invalidated when data is modified in the manager interface, but if you for example would run the manager interface in another application pool (site/application) this will make the caching fail, causing the kind of errors you describe.
Not being sure how your application is set up, this is my primary guess. If you are in fact running the client web & the manager in different application pools, and you need to continue doing this you should try one of the following approaches.
Implement a distributed cache provider
Set the system param CACHE_SERVER_EXPIRES to 1
Setting the param to 1 invalidates all server cache after one minute. This is of course not to recommend if you are expecting a lot of traffic to your site as it will more or less disable the caching mechanism.
I hope this helps you.
Best regards
Håkan
All of sudden it's now working. The only thing I remember to have done is delete duplicate entries in the dbo.page table. It's all working now, however it doesn't explain why the Site Description wasn't retrieve properly too. But never mind, I hope this will help someone else. I hope custom authentication will be built-in in the next release of Pirhana CMS !
Related
In IIS I want to deploy a sub application in a website. I really don't want to bother with having to update the root website's web.config with location tags all over the place.
Is it possible to direct the sub application to just totally ignore the root website's web.config?
Okay, so that's my question. The following is just additional information that could lead someone to offer an alternate solution I haven't thought of but if possible I hope you won't judge my post on the following since, as I mentioned, the above is my question... this is just extra information for the interested:
I am deploying several websites. Each website will have an admin application which will have the same codebase. I want the admin application to be available at site1.com/admin, site2.com/admin, etc.
In the past I did something similar on another project, but instead of having sub apps I did sub domains to another site... so it would have been like site1.admin.com, site2.admin.com, etc. Nice thing about this solution was the ease of just adding additional bindings for any new site (and the application would look at host name to apply proper theming, configuration, security, etc.). I would have preferred this solution again but it just won't work this time because we can't easily secure a proper domain name for that purpose and aside from that we would prefer the user stay on the same domain name anyway just from a marketing perspective.
So ultimately my goals are:
Have the web address be "sitename.com/admin"
Only deploy the admin application to one location
Avoid spending 2 days trying to figure out how to properly configure everything so that configs don't clash and then still end up with a
few errors I spontaneously find over the course of the next week and
eventually find one that requires me to reprogram a large section of
code in order to play nicely with the root website. (If you can't
tell, I may have minor PTSD from trying something like this a couple
years back).
I mean, what would be really super is if I could have admin be its own web application and have bindings like "site1.com/admin" and "site2.com/admin" but obviously that's not possible. But maybe there are some other straightforward solutions I haven't thought of yet?
I want to build a rails app that will host multiple domains(sites).
Some content will be similar across all the sites which is why I want it in the one database/app. I thought that I could use a different controller for each domain/site with each action relating to a single page ( each site will only have 4-5 pages ).
This seems possible given the answer here, however I'd like to know what effects this would have on caching, using nginx as the server ( As it's mostly static content I'd like to use page caching )
i.e wouldn't the app need to hit at every request to process the right page/domain?
I dont think thats a good solution. You should setup the application n times and handel the domains/subdomains using nginx and the upstream module.
Using one single instance of an application for various domains seems to be a loose solution to me. I would avoid that unless the content of the sites does depend on another directly. And even in that case I think an API is the better solution.
We are building an app where multiple websites are powered by a single site on IIS
We have a web-based tool where webmaster can edit the "resx" files, like:
/App_GlobalResources/es/Backend.es.resx
However there is two problems with this:
changing these files effects all sites.
It also causes the entire IIS site to restart.
Is there another approach to this?
I think storing the strings in a DB may be a bad idea as it will cause hundreds of SQL lookups per page.
Use a database driven resource provider that supports caching. And you are in luck because someone else already done it
Do you provide an interface to edit the resx files? If so, cache them in the Application scope and expire the cache when they are updated. Then, store them in the database. This way, you'll have both speed and flexibility.
Just because the data is in database, doesn't mean it'll be slow. Cache is the solution. Of course, the first lookup will be slow, but subsequent lookups will be as fast as you can get.
I would like create web app like shopify.com.
User can pickup subdomain(or domain), theme and have own store.
How can I do this?
Create main application, deploy it automatically like new standalone version and update it via git?
I'm using Rails 3.
Thanks for your advice.
Based on replies:
When I choose to use only one application (without multiple instances) and give user his subdomain, it will looks like their own website. But everything will be in one database (It's good idea?). And how can I have multiple themes in Rails app?
Take a look at LocomotiveCMS, specifically the routing system. Locomotive actually hosts multiple sites inside a single rails application. It does this by inspecting the request URL when it comes in and setting the current_site variable with the site which is set up to handle the domain. Then the current_site is actually just an object which contains all the pages, contents, settings, etc. for the specific site being served up.
So to answer your question, I think a good solution is to give your rails app the ability to serve up multiple sites based on the domain. It's not that hard, and it seems less fragile to me than trying to automatically deploy new instances of an app.
So far I have understood, you want to let your users have their own subdomain, different theme but the functionality would be same right. Users just need to have a feel of something of their own.
Well definitely, you need to have a single application that supports multiple subdomains.
A quick googling gave me [ http://37signals.com/svn/posts/1512-how-to-do-basecamp-style-subdomains-in-rails ]. May be you can get some insights from here.
For example if your service is http://www.myfi.com, a brief idea can be:
When a customer is registering, you should let him choose his subdomain. And the newly created account will be associated with this subdomain with a url. Say, http://customer1.myfi.com.
You should register for domain *.myfi.com so that anyone in the world hit with anysubdomain.myfi.com, it comes in your application.
Then from the url part, you should identify the subdomain (customer1) that is being used, and need to set that in session.
Now when someone will try to login, you must verify the account in the context of that subdomain's account.
In fact, all following actions need to be handled in the context of the subdomain's account.
Just tried the gather a glimpse of the implementation here. If you have confusion about something specific, share that also.
Edit:
Whenever you are thinking about multiple theme, you must have simple design which is completely driven by css and js. The app/view files should contain only content and HTML nodes with class names or ids.
Generally a UI designer can put more helpful ideas about how to make such theming mechanism. But all I can feel is, based on the chosen theme by customer, you have to load different css and js.
Actually the strategies can be indefinitely sophisticated and scalable, but its always wise to start with something easy. Then ideas will automatically evolve into better ones.
I'd love to use page caching on a Rails site I run. The information on each page is mostly constant, but the queries that need to be run to collect the information are complicated and can be slow in some cases.The only obstacle to using page caching is that the administrative interface is built into the main site so that admin operations can be performed without leaving the page of interest.
I'm using Apache+mod_rails (Passenger). Is there a way to indicate to Apache that .html files should be ignored when the current user either has a session variable or a cookie named 'admin'*? The session variable need not be evaluated by Apache for validity (since it will be evaluated by Rails in this case).
Is there a way to indicate to Apache that .html files should be ignored when the current user either has a session variable or a cookie named 'admin'*?
I believe it is not really possible. Even if it is, I guess should be very tricky.
Instead you can use Action Caching. A quote from docs:
One of the issues with page caching is
that you cannot use it for pages that
require checking code to determine
whether the user should be permitted
access.
This sounds like exactly your case.
But if you still really need Page Caching via web server, I think you better implement separate pages for admin and non-admin.
This is because of one reason. When you enable Page Caching rails doesn't process the request at all and thus there is no way to know if user is authenticated or not.
You probably can overcome this using Dynamic Page Caching. The idea is basically to add the "admin" part from the JavaScript. I don't personally like this a lot though.
One more update: quick search brought me to this article.
The idea is to cache page conditionally and plug mod_rewrite to serve admin pages.
Will work for you but is pretty dirty solution.