cmgmyr

Got it, thanks again!

Oh, that's not so great. Is there a way to exclude some sub domains? I'm only using a few of them so it would be easy to manually update.

Thanks, worked great!

Hello everyone, I have a site where any number of other domains can point to it. Right now I just have: RewriteCond %{HTTP_HOST} ^domain.com [NC] RewriteRule ^(.*)$ http://www.domain.com/$1 [L,R=301] Which obviously just works for domain.com how can I adjust this so it forces the redirect for any domain that comes through? Thanks in advance, -Chris

I thought about your comment some more and yes, you are right. Right now it just comes down to a few things: money - why not get $3-$5K for a site plus future upgrades as opposed to $50-$100/mo? time - I only have so much time do do the development on the custom sites and the SaaS sites, to combine them I would need more time. I still need to stay on track with deadlines, so it's easier to keep them separate. So again, yes you are right about moving everything over to the SaaS system and I probably will be doing that in the not too far off future, right now it just doesn't make sense to.

No, unfortunately I don't have anything up live yet. I'm hoping to get the "main" company site up sometime this week. I will update this post again once it's up and running though. Thanks for your 2 cents. You are half right about that (IMO). There are a lot of clients/companies that want specialized features that others might not want, or would be hard to develop SaaS wise. If you are talking about e-commerce, some just have straight forward pricing, others have crazy price structures that need extra attention. For the purposes of this project I'm just going to offer very straight forward pricing and shipping options in order to keep the programming as simple as possible and to keep my development time to a minimum. In the future I can adjust it as I get more feedback about the system, I'm sure I could develop other module/plugins for these specific features (similar to magento). BUT, my business "plan", if you will, is similar to 37 signals which is keep it simple and easy so anyone can use your product. Magento is a great program but definitely bloated and very hard for un-tech savvy people to use right out of the box. I have a few people signed up for this service right now so I want to get it up and running asap, then I can develop more for it as it becomes larger (and I start making some $$$). I hope all of that made sense

Thanks for the feedback, that's what I ended up going with. I haven't gotten through all of the details yet but it's going well so far. Also, to take it a step further, once I'm finished with the programming I'm going to duplicate it, take out all of the SaaS features so it's a "one company" site, and use that as a base for my custom sites if someone wants some additional features. That will cut down about 80% of my time for my custom stuff, which is huge. So just like you said "money in the bank"!

I would add some additional data to the tables packages (package_id, name, price, sort) options (option_id, name, price, base_package_id) First I would see which package they selected, on the next page list options that are above that "sort" value and attached to the "base_package_id". So at that point that package sequence is based on the "sort" since I could delete packages or add some, so after a while the ID's wouldn't have any importance (as far as sorting goes).

No, all users would need to pick an initial package. Then they will be able to add-on any options that are in the higher level packages.

It's just another way to handle an IF ELSE statement if($this->store_salt){ $salt = $this->store_salt; }else{ $salt = FALSE; }

Thanks for the feedback. Your assumptions for 2 & 3 were correct, but not #1. The package price will be set as the "base price" then additional options can be added. What about this for the structure: packages (package_id, name, price) options (option_id, name, price, base_package_id) The total at checkout will be the package price plus whatever all of the options add up to that are not in that base_package_id. Would that work better?

Hey Everyone, I'm having a tough time putting everything together in an efficient way, so I figured I would throw it out there to get some opinions. I have some web software where users can signup for a package, and each package has different options available. Users will also have the ability to add on an option that's not in their current package (instead of upgrading to the next package with that option), in order to save them some money. I would also need a simple way to query these options to see what they have available to them to open up or deny options to them. One of my thoughts is to have all of the packages in a table and have each option set to "yes" or "no" depending on if that option is allowed. Obviously this isn't that efficient as far as adding new features in the future. The other thought would be to create multiple tables: packages - package_id, name, price options - option_id, name, price packages_option_map - map_id, package_id, option_id users_map - user_map_id, user_id, map_id Is this the best way to handle this? Am I missing something? Any other advise/insight would also be helpful. Thanks in advance, -Chris

*bump* ...anyone?

Hey Everyone, It's been a long time that I haven't been on here but it's good to be back. It looks like things have been changing a lot! I've been working on a new application that I will be offering to my clients/possible clients. For all intensive purposes it's a website builder with a lot of options in different price plans per month. I've built this in the CodeIgniter framework and with programming that has been tested on a number of other sites for the past 2 years...so it's pretty solid. My initial idea was to have one website controlling all of the other ones and set up sub-domains for users that they can set up CNAME's to for their domain, this way their clients/customers don't know they they are using my site. The idea is to be able to push out updates, new features, and bug fixes regularly. This would obviously lean toward the SaaS option. My second idea is to just take this software and install it for each domain. This would be a little easier at the moment and would take less time since I have most of this already done. The problem would be with the future updates. If I have one site it's not too bad to update, 10 sites would be a pain, 100 sites would take forever. Since I already have a few businesses "signed up" for this new service I would like to get it up and running as soon as possible for them, but I want to minimize the amount of time I would have to put into each one in the future. I'm still leaning toward the SaaS option but this means that I have to add in a lot more programming/logic initially before anyone can start using it. Has anyone done anything like this before? Any advice or opinions about each option? Any insight or feedback would be greatly appreciated. Thanks! -Chris

Check out this site: http://www.maaking.com/ he has a user login system that might give you a good start.