29 replies to this topic

[ryan]

Thanks Robert, it looks like that worked! I renamed the old 2.0 repository and changed the URL with this command:

git remote set-url origin git@github.com:ryancramerdesign/ProcessWire-2.0.git

I pushed a test commit and it worked exactly as it should. So I will plan to do the same thing on the current P21 repository after I've given people some advance warning of the change. My plan is to rename the P21 to just "ProcessWire" (same name as the old 2.0 repository).

Assuming there were others still tracking the 2.0 repository (hopefully not), do these look like the correct commands that they would need to execute in order to track the new one?

git remote set-url origin git://github.com/ryancramerdesign/ProcessWire-2.0.git

or

git remote rm origin
git remote add origin [color=#282828][font=Georgia,]git://github.com/ryancramerdesign/ProcessWire-2.0.git[/font][/color]

[Robert Zelník]

Yes, that are the right commands.
Maybe after renaming the P21 repository it would be useful to create a new temporary "P21" repository with a README file with a message about the name change.

[ryan]

That's a good idea. I will plan to do that.

[apeisa]

What happens if you haven't renamed your origin and you git pull the new branch (which has only README)? I assume it will throw errors, but I am not sure.

[diogo]

Can't this temporary P21 be a copy of P22 with the README explaining?

[ryan]

Can't this temporary P21 be a copy of P22 with the README explaining?

I think this is probably the best way to do it. That will hopefully prevent the problem that Antti mentioned.

[Christoph]

The update process is really easy ) Just the need for changing the .htaccess is a bit annoying as I make individual changes there.
Is there a better way then just comparing the files everytime?

[Soma]

The update process is really easy ) Just the need for changing the .htaccess is a bit annoying as I make individual changes there.
Is there a better way then just comparing the files everytime?

You can use file compare in various IDE's. Also I think there's no easier way than do it manually, but I think the .htaccess doesn't change in every update. Most convenient way would be to look at the commit log on github if there really were any changes on the htaccess and which.

[Pete]

Yup - I think we were advised to update the .htaccess in one release (can't honestly remember) but it's certainly not the norm and I'm sure Ryan would mention it if it were required.

[ryan]

It's true that the htaccess doesn't change very often, but when it changes, you want to be sure to get it. So I think it's best for people to include that (and /index.php) in addition to replacement of the /wire/ directory, when doing an upgrade.

If you look in PW's htaccess file, you'll see it's very clear about where the ProcessWire directives start and end:

#####################################################
# START PROCESSWIRE HTACCESS DIRECTIVES
# @version 2.2
#####################################################

...and all of PW's htaccess directives go here...


#####################################################
# END PROCESSWIRE HTACCESS DIRECTIVES
#####################################################

So when I'm customizing an htaccess, I either place my custom directives above ProcessWire's, or if they need to go somewhere in the middle, I add a comment to make it clear that it's specific to the site I'm working on, and I indent it more than the others so that it stands out even more:

              # THIS DIRECTIVE IS FOR DI.NET ONLY: 
              RewriteCond %{HTTP_HOST} !^www\. [NC]
              RewriteRule ^ http://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

This makes it really easy to manage a customized .htaccess file through upgrades.