The best way to develop a modx site

Hi there,

I've been using modx for a couple of years now but I haven't yet found the best way to develop and launch a site.

My clients generally use cheap shared servers so to avoid any nasty surprises regarding what is and isn't installed on the server, I usually like to install in a subfolder on their server and develop the site there.

The problem is what to do when I want to go live. The obvious solution is mod_rewrite, but often this isn't an option (fasthosts is particularly a pain).

So I have to move the site from the subfolder but half the time I have problems, most usually in the manager.

I'd like to know what everyone else does when the develop in modx. (Please assume that you can't choose where the site is hosted.)

I think it'd be great if we could come up with a definitive, fool proof way of developing and launching in modx.

Thanks!

I work pretty much as you do although I sometimes also develop locally running xampp. Either way the site still needs to be moved at some point. It can be a bit tricky initially, I've moved a few sites now though and have the hang of it. I generally find re-running the install can solve any problems on a site that has been moved. Don't quote me on that though, I'm not sure what the official line is


Have you seen this? http://rtfm.modx.com/display/revolution20/Moving+Your+Site+to+a+New+Server

i've not found it a problem.

1. Move the site up a folder
2. Re-run the setup
3. Edit config.inc for the 4 urls that setup seems reluctant to change
4. Remove /subfolder in .htaccess if you'd set it

I am lucky in that we host most of the sites we develop on our own setup. If I developing in a shared hosting environment:

1. Install as normal. Rename index.php to _index.php (or whatever)
2. Set the request controller to the new index page (under system settings)
3. Disable "Friendly URLs" in the manager

That way you can test and develop in the servers environment without any conflicts. To launch do the same in the opposite order.

I like your solution Gibbs. Smart. Really, really smart!

What would you do if you were developing for a current static site?

Nice one Gibbs, I'll have to give that a go.

@Frogabog

That really depends. If it is just static HTML pages then install as normal but make sure the directory index points to the old index file. If those old static files end in .htm you will need to change the file extension that MODx uses under System > Content Types (i tend to leave it blank but you can have whatever extension you like).

Rewrites *should* favour physical files so there won'r be any issues with accidentally making duplicate URLs.

Edit: By the way I have a really bad habit of editing remote files as opposed to working locally so I'm sure some people won't recommend it. That said its a good method to avoid post-launch scares. [ed. note: last edited this post 12 years, 2 months ago.]

By the way I have a really bad habit of editing remote files as opposed to working locally so I'm sure some people won't recommend it. That said its a good method to avoid post-launch scares.

I was truly on board with the idea up till last evening when the Revo 2.2.0-pl site (sub-directory) I was working on remotely decided to eat up nearly 12gb of bandwidth. Which dumped the whole domain over quota by this morning. Being able to increase the quota myself is the only saving grace, or my client would have been really ticked off. It's only day two of February...

Although I guess this shows me there something to be said about preventing post-launch scares... the only indication I may have seen locally with the constant server requests and massive bandwidth usage might have been my fan running like mad.

This is my first time developing with MODX remotely. I like it... but then again maybe I don't like it.

Thanks very much for the information. I'm going to keep an eye on you now that you're here. Where have you been all this time anyway? :~}

I do have one question though. Insofar as FURL's, why would it be necessary to develop with FURL's on in MODX? I don't know for sure if the auto alias setting would work without everything else in place, but wouldn't it be fairly simple to just enable FURL's at a later date? On a small/medium site that shouldn't be too much to work in once it's ready, no?

I was truly on board with the idea up till last evening when the Revo 2.2.0-pl site (sub-directory) I was working on remotely decided to eat up nearly 12gb of bandwidth. Which dumped the whole domain over quota by this morning. Being able to increase the quota myself is the only saving grace, or my client would have been really ticked off. It's only day two of February...

12GB of bandwidth!? That's insane and sounds very iffy and wrong. Nearly everything you do in MODx results in either a file getting written to disk or a database query. No way could that result in 12GB of data being transferred and received in a month let alone a few days.

I do have one question though. Insofar as FURL's, why would it be necessary to develop with FURL's on in MODX? I don't know for sure if the auto alias setting would work without everything else in place, but wouldn't it be fairly simple to just enable FURL's at a later date? On a small/medium site that shouldn't be too much to work in once it's ready, no?

I don't see any issue with having them off. If you are making dynamic pages with variables being passed via the URL it is nice to see them in action though. I tend to develop remotely on sites that aren't live though so it usually isn't an issue.

Thanks very much for the information. I'm going to keep an eye on you now that you're here. Where have you been all this time anyway? :~}

The more I learn and use MODx the more I like it which is strange for a CMS in my case! So far its been ridiculously easy in terms of development and flexibility and clients seem to find it easy too. Win win

Quote from: gibbs_ at Feb 02, 2012, 08:16 PM

12GB of bandwidth!? That's insane and sounds very iffy and wrong. Nearly everything you do in MODx results in either a file getting written to disk or a database query. No way could that result in 12GB of data being transferred and received in a month let alone a few days

No kidding, and I'm not! I just took this off of the cpanel and I've been inspecting the daily bandwidth logs, it's all there.

Monthly Bandwidth Transfer 12010.96 / 15000 MB

And it wasn't a day's worth, but rather only about 10 hours. You could check out my frantic post from this morning when I found out the site was down due to bandwidth, after getting 500 errors yesterday evening and applying every fix I could think of or search for that didn't really work. Yes, something was horribly wrong with at least one, if not two plugins. The logs were nuts crazy. I'm terrified to install them again!

What's interesting is that after re-designing the site, the images pulled about 8gb/mo. I emergency raised the limit when it surprised me but I neglected to lower the limit after I optimized the images. So that's why it had 10gb available in the first place. It's a tiny little site that usually eats less than 1gb/mo, or up to 4gb Dec-March due to increased visitors (mountain snow causes this). Even 4gb is a lot if you ask me, which could be fixed with the new MODX site I'm working on. IF the owner agrees to pay, that is. He was fairly happy with his 1996 tables site and wants everything for free, so I'm not holding my breath.