I am new to Mautik and therefore need a guidance on the same.
Where should we setup mautik... on some folder or on sub domain to main site or a separate domain? How does the landing pages and forms gets its URL? Can it be embedded on another site on another domain or is it required to be hosted where mautik is hosted?
Moreover does single installation of mautik can be used for two or more different businesses site... which are not relevant.. and mainly a different customer for a marketing company? Or is it better to install mautik per business?
Can we track interactions from mobile app too using mautik?
First thing, I expect you are talking about Mautic and not Mautik.
You are free to choose whatever type of hosting you want, personally I Like to use independent container(could be lightweight) however I have seen people hosting on shared hosting as well.
If you are hosting on say example.com the landing page url will be example.com/landing-page same goes for all elements of mautic.
Yes forms can be embedded on other websites with a completely different domain. say example-something-else.com, you will need to put your tracking script on other site's head to make it work better. I for example check out this small tutorial https://tutorialsjoint.com/mautic-wordpress-integration/ it shows how you can use it in wordpress.
No it is not required that wherever you want to use mautic form should be on same host or domain.
However I recommend to use subdomain if usually just to save the hassle of buying a new domain and keeping the landing page urls more relevant. https://www.youtube.com/watch?v=K8lWaCabH1w this video shows how tracking works, it'll help you understand little better. Also here's official documentation: https://docs.mautic.org/en/contacts/manage-contacts/contact-monitoring.
You can use use one instance to manage multiple businesses I know people who are doing it but when the number of contacts, segments, campaigns, form, emails, landing pages grow with time it becomes a hassle to keep it clean. You can use category and a specific naming convention to keep them organized. But in a good way i will recommend to keep different instances in long run.
I am not sure about mobile apps but ideally it should be possible using tracking script or tracking pixel, perhaps you will need to turn off CORS restrictions.
I hope it was helpful.
Cheers!
No, you must use a VPS with Devian or Ubuntu, In a shared hosting it can cause problems. If you send many emails.
Landing pages can be made in html and pasted or edited in Mautic.
To use it in more sites you must create a user for each one, with their respective different email.
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 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.
So, this may be a kind of dumb question, but I checked the Google and got no hits. We want to host multiple Rails apps in a way that makes them look homogeneous. We want all the apps to have the same look and feel, and all the apps to use the same sign-on database.
Theming I think we could accomplish by just putting the site theme into a gem, and requiring that gem from our github repository in each app. However, auth is trickier.
I know that I can achieve this "for free" by just not making the different portions of the site (store, chat forums, etc.) different apps. If they're all, say, Rails Engines, we can basically drop them into the same application with their own namespaced routes, and have a single plugin that does auth.
However, for various reasons we'd like to keep these separate apps, if that's technically possible. The number one reason is scalability; since this will be a hosted site, we want the flexibility to spin up more instances of, say, the store (perhaps to handle a holiday sale rush), without needing to spin up the chat forums. Also, we want to be able to completely isolate the portions of the code that AREN'T intertwined.
Ideally, the databases would be separate too (keeping us from falling back into the rut of "put everything including the kitchen sink in the db"), but I do know that one "cheap" way to do cross-app auth is just to use the same plugin (say, Devise), and just point to the same DB.
So, I'm thinking that maybe the way to do this is to auth via a web service call. Is this prior art -- does anyone have a gem for this that "just works" so that authentication can be shared across all apps? Or am I just entering into a world of pain by trying to build things this way?
Thanks in advance!
You could do a single sign on approach described at:
http://blog.joshsoftware.com/2010/12/16/multiple-applications-with-devise-omniauth-and-single-sign-on/
The single sign on approach with oauth and devise has some drawbacks. The main problem I had was I was unable to extend the timeout time across multiple apps.
I'm developing a website but want a "Coming soon" page to be up for now. How do I structure a "Coming soon" page in my rails app 3.1? What's the best way to go about doing it.
Four options I'm considering are:
Have a static coming soon page in the public directory. Have rails routes point to it and then modify my routes file when I go live.
Have a page served by a controller pointing to www.myproject.com/home. I'll just change the routes file when I'm ready to go live to www.myproject.com
Use LaunchRock.com. Have my domain posted to LaunchRock and then point it to my site when I'm ready.
Use https://github.com/vinsol/Launching-Soon/
Which method is best suited for my Rails project?
Thank you
Any of these have different pros and cons. It's up to you really.
If you're close to launch, you'll have to set up a web-server and Rails anyhow, so either setting up a Rails controller for serving the static pages, or have a static page in your public directory, are probably the best choices then.
Personally I'd not serve the "coming soon" page through other sites/services.
One reason for having some sort of "coming soon" page is for SEO purposes. For that it's best to have full control over your site / page.
I'd go for using a Controller for the static pages, because you can more easily use the same layout as your site, and you can add dynamic content to that page (e.g. a sign-up or a contact form).
See:
http://railscasts.com/episodes/117-semi-static-pages
Option number 6) serve the static page through Rack
http://railscasts.com/episodes/222-rack-in-rails-3
Any of the above, and one more:
5.Have you webserver return a static page for all requests, bypassing rails completely.
Which one you use depends on how much trouble you want to go to, and whether you want some sort of basic app functionality (like announcements).
I suggest you make a list of what features you actually need, or are sure you'll use, and see how that matches with your list.
One thing to take into account is the time-frame. If the 'launching soon' is not going to be that soon then you'll want some way to easily keep people informed.
Put a static page with some copy up today for SEO purposes. Then consider your marketing objectives and think about what kind of features you need (e.g. mailing list signup, window into application data, viral video, etc). Balance the needs of those features against time taken away from actual development.
At the end you ask the right question (emphasis mine):
Which method is best suited for my Rails project?
But you don't give any context. Any of the methods you mentioned could be appropriate, but they are meaningless without understanding the business goals. A technical forum such as this is probably not the best place to ask at this stage.
I have two tasks both using rails:
To make an inventory app to help employees keep track of inventory
To make a website for the company for customers to visit and gain a bit of knowledge about our product
My plan is to have the inventory app for each branch of the company to have a domain like this:
branch1.example.com
branch2.example.com
branch3.example.com
and for the customer-facing website to simply be www.example.com
My question is, should I make two separate rails apps, one for the inventory app and one for the customer-facing website? Or would it be easier to manage the two as a single combined app? The two apps would not be likely to share much code.
And if I were to split my apps, how would I be able to host both of my apps using a single domain as seen above (with the use of subdomains) with heroku?
Thanks!
Well, there's not really one right answer, but being experience with rails, I would recommend one app.
If you split there will be many times you'll have to copy and paste common code (becomes unmanagable). Plus you'll deal with either a shared database or multiple databases.
Not splitting, you can use a wildcard domain and access the current subdomain via request.subdomain to easily do whatever logic needs to happen per subdomain. Also you will only need to create the Product model once.
In short, all the mentioned requirements sound tightly coupled enough that one app would be easiest.