meteor-admin
meteor-admin copied to clipboard
yogiben
Admin style interferes with app style
In other words, by installing bootstrap and font:awesome the appearance of the normal application is altered. Ideally, meteor-admin should be standalone with no side effects.
We used to wrap adminlte style in .admin-layout but it defines some properties on html and body so it wasn't working well. In the new version we are injecting css file on admin routes only.
Yes... It's ugly.
Router.configure({
waitOn: function () {
if(Router.current().route.getName().indexOf('adminDashboard')==-1)
$('head').find('link[type="text/css"]:not(.__meteor-css__)').remove();
}
});
as an idea: For larger projects it might be better to split your application into two apps: a frontend-app and an admin-app. This would also save some bandwidth.
You could share code with packages that could contain things like Schema-definitions, etc.
The two apps would either communicate via ddp or just access the same database.
I ended up doing exactly that (frontend and backend as separate apps, Atmosphere package for shared collections and publications).
In general, your approach works fine - the only problem I found is that this doesn't work with meteor deploy, because every meteor.com-App always gets its own database. You need to have control over the MONGO_URL, so you have to deploy to Modulus, Heroku, or whatever.
you could serve the whole content from the frontend-app, which manages its collections and have the admin-app connect via ddp to the running frontend app. You could even access and modify the public instance of the frontend-app from your local running admin-app (or vis-verca, but i think it is better that way performance-wise). :+1:
I have the same issue. I've tried approaches that instead of removing it, add it when you're logged in as admin and using an admin route. Unfortunately the packages use bootstrap as a dependency so eliminating it from the project and manually adding it isn't very reliable.
Running two apps sounds really messy when it comes to local development too. This is a pretty big flaw, and is causing all sorts of issues on my app unfortunately. Anyone have any ideas on how to contribute in a way that would update this?
One solution I've seen in another package is to put a link in the HTML templates, which retrieves Bootstrap from a CDN, rather than using the package. This way, you get easy, explicit control over the pages on which Bootstrap is imported. Devs, would that be a workable solution for you?
