ryan

ProcessWire 2.2 [soft launch]

30 posts in this topic

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 by ryan
Added 'Other Changes' section and more upgrade notes.
1 person likes this

Share this post


Link to post
Share on other sites

Great news Ryan!

Don't forget to change from 2.1 to 2.2 on the downloads page.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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? :unsure: But perhaps we'll take over the ProcessWire repo once again with v2.2.

Share this post


Link to post
Share on other sites

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 ;)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Also might be worth asking from github if they could help renaming the repo. I agree that this is better do sooner than later.

Share this post


Link to post
Share on other sites

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? :unsure: 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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 person likes this

Share this post


Link to post
Share on other sites

Okay that settles it, I will plan to rename it before we send out 2.2 press releases.

1 person likes this

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

post-2-0-68851800-1329227574_thumb.gif

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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]

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.