Wagn 1.0 was a pioneering web app. Wagn 2.0 will be a pioneering web app and web platform.
The current release (Wagn 1.8) gets us considerably closer. To name a few highlights:
- uses Rails 3 - the latest and greatest.
- supports Ruby 1.9 (1.8.7 still works)
- new file and image handling is more secure, flexible, and re-usable
- new settings editor is much crisper and easier to understand
- Almost 50 tickets resolved: new features, bug fixes, performance enhancements, etc.
This release includes more resolved tickets and more commits than any prior Wagn release, and yet the codebase is actually smaller than ever.
Always back up your database and uploaded files.
From your decko root directory run:bundle update
Run the following:decko update
In your decko's root directory, edit Gemfile, config/application.rb, and config/routes.rb, and script/wagn, replacing “wagn” with “decko”. (Keep the same capitalization pattern.)
From your decko root directory run:mv script/wagn script/decko
If your Wagn was NOT installed from a gem, then first check the Wagn version of your existing installation:
For version 1.10 through 1.12.6
- Create a new Wagn app using steps 1 and 2 from the installation section above.
- Copy config/database.yml from the old site to the new one.
- Copy the old local/files contents to the new files directory.
- If you have edited config/wagn.yml in your old site, make the corresponding changes to the new config/application.rb file.
- Follow the standard upgrade procedure above.
Upgrading pre-version 1.10
First update your Wagn to version 1.10 via the old update mechanisms, and then follow the directions above to then upgrade to the wagn gem.
- Wagn will no longer work with Ruby 1.8.6. Rails 3 requires a minimum of Ruby 1.8.7. Wagn will work fine with 1.8.7 but will run faster with Ruby 1.9 versions. (This is the first release of Wagn that supports Ruby 1.9).
- Unlike previous versions, Wagn now defaults to running in production mode. We do this so that a default Wagn installation can require significantly fewer libraries, and so that Wagn users can avoid some installation hassles associated with developing with Rails 3's asset pipeline. In consequence:
- You should review your database.yml file to be sure your database is configured in production.
- Unless you plan to do custom development, we recommend that you configure your wagn to use only the gems necessary for production. For a typical mysql installation, your .bundle/config file should look something like this:
- If you want to modify wagn code see Wagn in development.
- If you're running a production site, see Wagn in production -- there are several recommended changes.
- config/wagn.rb is no longer used. You can now set options via config/wagn.yml. The file is not necessary, but if you would like to use it, you can copy it from config/samples/wagn.yml
- The URL pattern for searches has changed, and search URLs of the old pattern will break. For example, a search that used to look like http://wagn.org/search/interwiki now looks like http://wagn.org/*search?_keyword=interwiki The corresponding URL to generate RSS feeds has also changed, from e.g. http://wagn.org/search/interwiki.rss to http://wagn.org/*search.rss?_keyword=interwiki There will be more changes like this as we clean up URLs - see RESTful Web API and add a modular mechanism for custom URLs.
√ http://en.dwagn.org/wagn/*account+*right+*content ("item": "change")
Added "sort" to WQL:
Changed to offer radio buttons of the options:
√ css references in *tinymce
√ local image references in *css
√ drop superfluous indexes on cards table.
√ drop unused tables: permissions, card_files, card_images, system, open_id stuff, db_files
√ edited to editor in WQL
√ new Layout cardtype.
These we want to do after we handle card parts when creating previously virtual cards (status:):
I looked at several sites and couldn't find any issues with these cards. I can believe there might be rules out there missing sets, or, more generally, plus cards missing parts. If we find any of those, my inclination would be to try to build a smarter migration that's smart about the pattern and finds all the busted data it can. -efm
TODO: ticket the following (and move over comments until double horizontal rule)
We can't migrate Cardtype+*type+*content, because it will override all kinds of custom Cardtype cards. Eg, on wagn.org alone (which is not our biggest problem), it would break Ticket, Deck, Support Ticket and probably several others.
We could check each |cardtype| card, and if anyone beside WagnBot has edited it, add a |cardtype|+*self+*default card.
--John Abbe.....Sun Mar 20 19:08:29 -0700 2011
So...most of the tickets in testing now can only be tested on the new server?
--John Abbe.....Sun Dec 18 22:18:15 -0800 2011
Yes. Would it be helpful if I made so that you could still somehow access the old site? --efm
So far I've just been testing whatever seemed most interesting/fun/easiest to me. If you want to let me know what you think is most critical, or most in need of testing, I can throw your criteria into the mix as well...
hmm. good question. I guess if there are ones that look easy to close it would help improve the signal to noise ratio...
--John Abbe.....Fri Dec 23 23:58:41 -0800 2011
What new Layout cardtype? (not seeing it on test or play)
--John Abbe.....Mon Jan 02 15:56:01 -0800 2012
It's not there to migrate yet, but I need to create a new Layout cardtype for handling _main. Discussed briefly in add reference syntax for main card of page -efm
Just ran all the migrations on test, play, and cp staging.
--Ethan McCutchen.....Tue Jan 03 20:47:58 -0800 2012
guess we should prioritize the "_main" testing...
--Ethan McCutchen.....Wed Jan 04 10:40:26 -0800 2012
Documentation to update:
views: new and edit (and editor), and (for code only) open_rule, closed_rule
CQL Syntax - _main, sorting by plus cards
.file - new file formats for downloading