ryan Posted January 17, 2012 Share Posted January 17, 2012 (edited) I've merged the 2.2 dev branch into the 2.1 master branch, making 2.2 the current stable version. I've been switching my own sites between the two branches for weeks without issue, and I've not had any reports from others about compatibility issues, so believe it's safe to merge. However, there are a lot of changes between the two so use caution when pulling in the latest commit. By that I mean backup and test everything out to ensure all still works as expected. Of course, this is something you should always do, but especially so in this case (it merged more than 50 commits from the dev branch). Language Support The LanguageSupport modules are now included in the ProcessWire stable branch, but they are uninstalled by default. These LanguageSupport modules are still considered beta, as I think we need more people using and testing them before we can consider them non-beta. To install them, just click "install" on the LanguageSupport module in your Admin > Modules. It will install everything else. You can also uninstall the LanguageSupport modules just as easily as installing them by just uninstalling the LanguageSupport module (and it will uninstall the rest). I will be adding a Language Packs section to the Download page soon. Thanks to all those that have helped with making translations. In the coming weeks, we will also be making more and more of the core modules translatable, so we'll need continued help from our translators. Special thanks to Avoine (http://avoine.fi) for being a sponsor of ProcessWire 2.2. You will see their name start to appear elsewhere on the site as a thanks for them helping to make the Language Support possible in ProcessWire. Other changes The LanguageSupport modules are the major drive of this version. However, there are several other changes and additions, including: Add module dependencies support. Add module auto install and uninstall support, to correspond with dependencies. Add 'page-create' permission to Setup > Templates > Template > Access. Update to latest version of TinyMCE (3.4.7) Add new Page Clone module to core (may be installed from Admin > Modules) Update error log file to include hostname. Made tab delimited rather than colon delimited. Added built-in multi-site/multi-domain support optiona via config file /wire/config.index.php Addition of several new hooks, especially in the $pages API var and files Inputfield. Add new 'Site' link in default admin theme. Numerous other bug fixes and optimizations, see the commit log for details. Upgrading an existing installation There is no formal upgrade process for going from ProcessWire 2.1 to 2.2, so all you need to do is pull in the latest commit (when you have time to adequately test it). If you aren't tracking the source on GitHub, then you'll want to download the latest ZIP and then do the following: Replace your existing /wire/ directory with the new one in the ZIP. Replace your existing /index.php with the new one in the ZIP. Replace your existing /.htaccess file with the htaccess.txt file included in the ZIP. That's all you need to do. However, I suggest renaming or backing up your existing /wire/, /index.php and /.htaccess files just in case you need to revert for any reason. This is standard procedure with any upgrade. Please let me know how everything works for you. After installing, there is one change that may affect you if you are using multiple non-superuser roles with page edit access. A user must now have page-create permission on a Template in order to create a new page that uses that template. You'll see this setting on any template that is defining access, on its access tab. So if you have non-superuser roles with edit access, go in and add that page-create permission for any templates that they should be allowed to create new pages from. Edited January 17, 2012 by ryan Added 'Other Changes' section and more upgrade notes. 1 Link to comment Share on other sites More sharing options...
diogo Posted January 17, 2012 Share Posted January 17, 2012 Great news Ryan! Don't forget to change from 2.1 to 2.2 on the downloads page. Link to comment Share on other sites More sharing options...
apeisa Posted January 17, 2012 Share Posted January 17, 2012 Great news. One question: are you planning to update the reposity or do we stick with "P21"? Or maybe merging to "ProcessWire" and start using branches there? Not sure how other projects handle different versions with their software, but branches feel like pretty natural way to do it. Link to comment Share on other sites More sharing options...
ryan Posted January 17, 2012 Author Share Posted January 17, 2012 I was planning to keep it in P21, but of course the name is no longer reflective of the version. I think that others do it by just keeping their original one, like ProcessWire (rather than P21). This comes from me being a Git newbie, I didn't know how to use branches when I started. But now we've got all of our "watchers" on P21, and I'd hate to lose them. So not exactly sure what to do? But perhaps we'll take over the ProcessWire repo once again with v2.2. Link to comment Share on other sites More sharing options...
nikola Posted January 17, 2012 Share Posted January 17, 2012 Great news Ryan! Can't wait to try all these new features. Good work (as usual ). Link to comment Share on other sites More sharing options...
Nico Knoll Posted January 17, 2012 Share Posted January 17, 2012 Ehm... could you add/update the following lines to the default "Page Name" module: ä=ae ö=oe ü=ue ß=ss That are german symbols and it's better if it would be like this Link to comment Share on other sites More sharing options...
ryan Posted January 17, 2012 Author Share Posted January 17, 2012 Nico, we can't put those in like that just because they translate differently into other languages. We actually did originally, but then learned that it was producing an incorrect translation in Finnish and Russian. However, you can configure how you want these translated in Modules > Inputfield > InputfieldPageName Link to comment Share on other sites More sharing options...
slkwrm Posted January 18, 2012 Share Posted January 18, 2012 Great news! What if just start using new ProcessWire repo but also keep P21 as a mirror? Also put a link on a main page of it and maybe put additional info file for those who just checkout without visiting the page. Then users can transfer gradually. Anyway, this transition should happen sometime, so it's better to do it sooner then later) Ready to participate in translation, just let me know when everything is ready. Cheers. Link to comment Share on other sites More sharing options...
apeisa Posted January 18, 2012 Share Posted January 18, 2012 Also might be worth asking from github if they could help renaming the repo. I agree that this is better do sooner than later. Link to comment Share on other sites More sharing options...
WillMorris Posted January 18, 2012 Share Posted January 18, 2012 Just an FYI: readme.txt and copyright.txt still say 2.1. Link to comment Share on other sites More sharing options...
vikingkarwur Posted January 30, 2012 Share Posted January 30, 2012 @Ryan : Thanks Link to comment Share on other sites More sharing options...
Robert Zelník Posted February 7, 2012 Share Posted February 7, 2012 I was planning to keep it in P21, but of course the name is no longer reflective of the version. I think that others do it by just keeping their original one, like ProcessWire (rather than P21). This comes from me being a Git newbie, I didn't know how to use branches when I started. But now we've got all of our "watchers" on P21, and I'd hate to lose them. So not exactly sure what to do? But perhaps we'll take over the ProcessWire repo once again with v2.2. Ryan, you can rename your Github repository without concerns, your watchers will remain untouched (I have checked it with my repository). Just go to admin > Settings > Repository and set the name you want. Link to comment Share on other sites More sharing options...
ryan Posted February 7, 2012 Author Share Posted February 7, 2012 Thanks Robert, that's definitely good to hear. I will plan to do that. I'm wondering if this will mess up people that are tracking the repository, making them have to set a new remote, or if Git does some kind of redirect automatically? That's probably not an easy question to answer... I may have to do a test to find out. I just want to avoid inconveniencing people as much as possible. I'd rather just keep the repository name 'P21' than cause any problems for people. But hopefully can find a way to rename it without any side effects. Link to comment Share on other sites More sharing options...
apeisa Posted February 7, 2012 Share Posted February 7, 2012 If I remember correctly it requires one line command to update origin repo after renaming. Probably some kind of mirroring from old repo is possible but not sure... Link to comment Share on other sites More sharing options...
Robert Zelník Posted February 7, 2012 Share Posted February 7, 2012 Maybe some mess will happen, but I don't see this as a big issue. People will see that the pull request doesn't work, so they can check Github or processwire.com and they will find a message about the update. It's quite common situation for open source projects that sometimes they change their name or move to another code hosting service. Link to comment Share on other sites More sharing options...
raik Posted February 9, 2012 Share Posted February 9, 2012 Maybe some mess will happen, but I don't see this as a big issue. People will see that the pull request doesn't work, so they can check Github or processwire.com and they will find a message about the update. It's quite common situation for open source projects that sometimes they change their name or move to another code hosting service. I agree with Robert about it and better now than later when there is a lot more watchers. I had troubles finding processwire in github because of the P21 name. 1 Link to comment Share on other sites More sharing options...
ryan Posted February 9, 2012 Author Share Posted February 9, 2012 Okay that settles it, I will plan to rename it before we send out 2.2 press releases. 1 Link to comment Share on other sites More sharing options...
Robert Zelník Posted February 14, 2012 Share Posted February 14, 2012 Ryan, in my opinion the first important step should be to stabilize the state of the releases. Currently, when the download link on the home page refers to the master branch on github, it doesn't actually refer to the stable 2.2 release, but to the development version, which is changing with each new commit to the master branch. There should be a particular commit tagged "2.2" and the links should refer to that tag, otherwise you can not guarantee that the package for download is really working as expected. Link to comment Share on other sites More sharing options...
ryan Posted February 14, 2012 Author Share Posted February 14, 2012 Robert, what I link to actually isn't the dev branch. I maintain a separate dev branch locally and then updates go into the master branch after I've tested them to make sure they are working properly. If I'm working on something major, I have that dev branch at GitHub as well so people can switch to it to help test. But I get what you are saying about tags and sending downloaders to that. I'm a little mixed about that because I'm always fixing, optimizing and improving things and would hate to send people to something that is something older than the latest stable. But I suppose I could still do that with tags like 2.1.1.2 or something like that, and then update the download link and version number in the source every time I push a commit. This would at least enable more easy communication of exactly what version someone is using when an issue comes up. I'm willing to give it a try. But that leads to a question: how do I get tags to go to GitHub? I added tag "v2.2.0" to PW as soon as I released the version a few weeks ago, but that tag has yet to show up anywhere at GitHub. Yet if I type "git tag" locally, I can see it. Perhaps I haven't attached it to a specific commit? I need to read up on tags. As a test, I renamed the old ProcessWire 2.0 repository from "ProcessWire" to "ProcessWire-2.0". It worked, but GitHub is telling me "unexpected bad things" and I usually try to avoid unexpected or bad things: They are saying "we" will not setup redirects, but they aren't saying it can't be done. It seems like that leaves open the possibility that I can setup redirects somehow? (maybe just wishful thinking?) How do I update my local repository to point to the new location? What instructions should I give others to update their location? I'm going to test this all with the v2.0 repository before attempting with the 2.2 repository. Thanks, Ryan Link to comment Share on other sites More sharing options...
Robert Zelník Posted February 14, 2012 Share Posted February 14, 2012 I didn't know that you have a separate local branch. In this case it's ok. Git tags are always created locally, they have to be pushed to the remote server (GitHub in this case) by this command: git push --tags It seems that it is not possible to set a Github redirect from the old repository to the new one. Local repository update: I used to do this in the GUI frontend (gitg), so I am not familiar with the command line, but this should work: git remote rm origin git remote add origin git://github.com/someuser/newprojectname.git Or in recent versions of git: git remote set-url origin git://github.com/someuser/newprojectname.git http://gitref.org/remotes/ http://stackoverflow...-name-in-github Link to comment Share on other sites More sharing options...
ryan Posted February 14, 2012 Author Share Posted February 14, 2012 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] Link to comment Share on other sites More sharing options...
Robert Zelník Posted February 14, 2012 Share Posted February 14, 2012 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. Link to comment Share on other sites More sharing options...
ryan Posted February 14, 2012 Author Share Posted February 14, 2012 That's a good idea. I will plan to do that. Link to comment Share on other sites More sharing options...
apeisa Posted February 14, 2012 Share Posted February 14, 2012 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. Link to comment Share on other sites More sharing options...
diogo Posted February 14, 2012 Share Posted February 14, 2012 Can't this temporary P21 be a copy of P22 with the README explaining? Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now