$config->httpHost preferred usage

[davo]

What's the advantage of $config->httpHost/my/page over just /my/page when making references in templates.

[LostKobrakai]

Sometimes you need to generate full urls, e. g. if you send emails. More generally, everytime the url should be used without the context of "this is the current domain", which the browser has, if you're already on the website.

[davo]

Thank you

So you'd normally just express it as /URL/to/my/page then. No need for the domain? The reason I ask is I've been developing a site on a sub domain, soon to be the real domain. Just trying to prep for the change over

[LostKobrakai]

The beauty of relative urls is, that it's independent of it's domain. So you don't need to change anything, if you don't have any hardcoded url bits.

[Martijn Geerts]

 The reason I ask is I've been developing a site on a sub domain, soon to be the real domain.

For the next time, it's better to avoid this. It'll save you extra unnecessary work.

[davo]

Thanks. All noted

FYI, sub domain was being used as the original domain is being used for the existing site. Have to run in parallel for a short while.

[kongondo]

...FYI, sub domain was being used as the original domain is being used for the existing site. Have to run in parallel for a short while.

Were you developing on the production site then? Not locally?

[davo]

Originaldomain.com has the original site

Subdomain.originaldomain.com has the new site.

These are both on a production server but on completely different vhosts.

When one site is reAdy to take over, the original domain vhost is renamed to old.originaldomain.com and the new site is renamed to originaldomain.com

This way both sites stay live with minimal down time and ability to switch back should there be issues.

I'm sure others have many other ways to achieve the same

[LostKobrakai]

For the next time, it's better to avoid this. It'll save you extra unnecessary work.

It shouldn't matter where your developing, as long as you don't hardcode anything. The only thing to change, if it's going live, is /site/config.php to reflect the new domain. 

Edit: For future reference, maybe the RewriteBase has to be changed as well, but this depends on the server configuration.

[Martijn Geerts]

@LostKobrakai, are all url assets used in WYSIWYG fields abstracted by default ? So are they are converted at runtime to valid urls? 

I know there's a module that can do that, but is it now the default in ProcessWire ? 

And what about url used in javascript, stylesheets etc.

It's just a good practice to make your dev environment the same as the real domain. 

[davo]

Hmmm, the only issues I've had recently were when moving a site to a bitnami stack for off line use. The problem I found with that was the default installation was something like localhost/processwire. This didn't work so well when I tried to import the site into it.

The way I got around this was to clone the virtual server the production site was running on and run it on virtual box on the laptop. Possibly over kill but worked.

The first option did at least high light the issue of urls to me.

[LostKobrakai]

@Martijn Geerts

Ok, the Markup generated by WYSIWYG fields wasn't on my radar, but at least all images and urls added with the processwire specific plugins produce relative urls. 

Stylesheets also do work with relative urls. For javascript just add this line to make it work, if you really need a full url.

<script ...>
  var host = <?php echo $config->httpHost; ?>;
</script>

[Martijn Geerts]

@LostKrobrakai, it's not a real big deal to develop in a sub folder and everything can be solved. 

I just prefer to drag'n'drop the development folder to the end location and import the SQL without additional steps.

[LostKobrakai]

Yeah, it's certainly more error prove. Most of my sites have to be filled with the final content, before they go live and that's not my job to do that. So the subdomain options is quite convenient.

[davo]

It shouldn't matter where your developing, as long as you don't hardcode anything. The only thing to change, if it's going live, is /site/config.php to reflect the new domain. 

Edit: For future reference, maybe the RewriteBase has to be changed as well, but this depends on the server configuration.

I can't find any reference to the domain in this file? What line should it be on?

[adrian]

I can't find any reference to the domain in this file? What line should it be on?

Should be right at the very end:

$config->httpHosts

[davo]

Should be right at the very end:

$config->httpHosts

I can't find that in /site/config.php

mine ends:

$config->userAuthSalt = 'xxxxxxxxxxxxxxxxxxxxxxxxx'; 

/**
 * Installer: File Permission Configuration
 * 
 */
$config->chmodDir = '0755'; // permission for directories created by ProcessWire
$config->chmodFile = '0644'; // permission for files created by ProcessWire 

[adrian]

Then it sounds like you are running an old config.php file - a version of PW from before that setting was added. You can grab a new version and take a look through to see if there are any other new settings you are missing. I don't recommend replacing it with a new version - you're better off just adding the new settings to make sure you don't break any of your database settings, userAuthSalt etc.

[OrganizedFellow]

Thank you

So you'd normally just express it as /URL/to/my/page then. No need for the domain? The reason I ask is I've been developing a site on a sub domain, soon to be the real domain. Just trying to prep for the change over

Here's a real word example.

$base_url  = $_SERVER['SERVER_NAME'];
switch ($base_url) {
	// LOCAL CONFIG
	case "mytestsite.dev":
		$config->dbHost    = 'localhost';
		$config->dbName    = 'mytestsite';
		$config->dbUser    = 'user1';
		$config->dbPass    = 'PaSsWoRd1';
		$config->dbPort    = '3306';
		$config->debug     = true; 
		$config->httpHosts = array('mytestsite.dev/', 'www.mytestsite.dev/');
		break;
	// LIVE CONFIG
	case "mylivewebsite.com":
		$config->dbHost    = '127.0.0.1';
		$config->dbName    = 'mylivewebsite';
		$config->dbUser    = 'user2';
		$config->dbPass    = 'pAsSwOrD2';
		$config->dbPort    = '3306';
		$config->debug     = false; 
		$config->httpHosts = array('mylivewebsite.com/', 'www.mylivewebsite.com/');
		break;
}

I have that in my config.php file.

I can now freely make all my changes off line without fear of messing something up.

Then all I do is dump and copy/paste the database.

[OrganizedFellow]

I found this, thought I'd share:

http://processwire.com/api/variables/config/
 

Maintaining a separate development configuration file

 

You may optionally maintain a separate development configuration file at /site/config-dev.php. When present, ProcessWire will use this file rather than /site/config.php. This may be useful on your development and/or staging server and allows you to maintain the same /site/config.php file between staging and production server. As an example, your /site/config-dev.php file may have the database connection information specific to your development server, while your /site/config.php has the database connection information specific to your production server. This prevents the possibility of overwriting your production server's configuration file during migrations and mirrors. Of course, you will want to ensure that your config-dev.php file does not end up on your production server by adding it to the file exclusion list of whatever tool you are using to transfer files.

 

I've not tried it, but it sounds like I would make a copy of 'config.php' and rename it 'config-dev.php'. One with the live server settings and the other with the developmental server settings.

Makes sense. Especially if there are other variables in config that need changing,

I'm guessing perhaps timezone? That might change, pending the location of the live server.

Maybe even appendTemplateFile and prependTemplateFile for various testing scenarios?

BTW: I noticed the $config->adminEmail = ' '; is blank on all my sites. It shouldn't be, should it?

And $config->timezone = 'America/Denver'; is mentioned twice.