Upgrading from 1.5.3 to 1.13.0 in steps went wrong+discussion
Hi Ariel, nice to see your name again and to hear that you're bringing your Wagn up to date. First off, I'm very glad to hear that you dumped your database first. I'm sure we'll be able to work out any problems so long as that's the case.
Here are some things that *could* have gone wrong:
1. you may have run only "rake db:migrate" and not "rake wagn:migrate". The former only handles structural migrations and not card migrations.
2. it might not be finding files because they're not in the right directory. are they in the 'files' directory in the root of your deck?
3. you will need a runtime JavaScript environment for 1.13, because it represents javascript and coffeescript in cards and then compiles them into a single output file. if you can't get therubyracer to work, have a look here for other options.
4. you could be having caching issues. I would recommend removing your tmp directory entirely regardless, and if you're using memcached, then it's worth restarting the daemon.
5. it's possible you're having permission errors.
If that doesn't get you running, can you post some error messages from the log? All those pink "error rendering" things should be leaving messages in log/production.log in your deck root.
Also see wagn in production for (imperfectly organized, as of yet) hints.
Hello, Ethan.
Thanks for the welcome back. :3
Although I don't want to, I am fully prepared to start over from the 1.5.3 snapshot. I think all five of those things may be going wrong. A silver lining on the dark cloud over my site is that the database I'll throw away (if I have to repeat the upgrade) won't have any data that'll be missed if lost.
1. I did run "rake db:migrate" as the surviving upgrade instructions said I should, but I did not run "rake wagn:migrate". I found a mention of it, but I couldn't find out which version(s) had that command, it was unrecognized on 1.6, and I couldn't find a description of what rake commands were available.
2. My files are in multiple subdirectories in public/card_images and public/card_files.
3. According to "bundle show", I have therubyracer 0.12.1, which didn't have any problems installing. It was only 0.11.0 required by earlier versions of wagn that can't install. I also have coffee-script 2.3.0, coffee-script-source 1.8.0, and execjs 2.2.2, libv8 3.16.14.7.
4. I didn't even think of looking for a cache. Removing tmp/* resulted in the following actions logged to log/production.log and then the dispatcher logging a crash:
==> log/production.log <==
Connecting to database specified by database.yml
Started GET "/" for 208.38.215.22 at 2014-10-20 17:00:28 -0700
Processing by CardController#read as HTML
[paperclip] Saving attachments.
==> log/dispatch_err.log <==
#
# Fatal error in heap setup
# Allocation failed - process out of memory
#
Shortly after, but before any other HTTP requests were logged, I got the Welcome card, and the following appeared in the log:
==> log/production.log <==
Connecting to database specified by database.yml
Started GET "/" for 208.38.215.22 at 2014-10-20 17:11:42 -0700
Processing by CardController#read as HTML
Error rendering *account links / raw: Card::PermissionDenied : for card : ["No create rule for "]
Rendered text template (0.0ms)
Completed 200 OK in 10062.5ms (Views: 29.8ms | ActiveRecord: 545.7ms)
Started GET "/files/*all+*style+*machine_output-10392.css" for 208.38.215.22 at 2014-10-20 17:11:54 -0700
Processing by CardController#read as CSS
Parameters: {"explicit_file"=>true, "id"=>"*all+*style+*machine_output", "rev"=>"10392"}
Sent file /home/arielmt/thornton2.com/files/2688/10392.css (0.3ms)
Completed 200 OK in 1106.2ms (ActiveRecord: 32.7ms)
Connecting to database specified by database.yml
Started GET "/files/*all+*script+*machine_output-0..js" for 208.38.215.22 at 2014-10-20 17:12:10 -0700
Processing by CardController#read as JS
Parameters: {"view"=>"bad_address", "id"=>"files/*all+*script+*machine_output-0."}
Rendered text template (0.0ms)
Completed 404 Not Found in 1060.9ms (Views: 59.2ms | ActiveRecord: 94.0ms)
Started GET "/files/*logo-small-3491.png" for 208.38.215.22 at 2014-10-20 17:12:15 -0700
Processing by CardController#read as PNG
Parameters: {"explicit_file"=>true, "id"=>"*logo", "size"=>"small", "rev"=>"3491"}
Started GET "/files/*logo-medium-3491.png" for 208.38.215.22 at 2014-10-20 17:12:15 -0700
Processing by CardController#read as PNG
Parameters: {"explicit_file"=>true, "id"=>"*logo", "size"=>"medium", "rev"=>"3491"}
Sent file /home/arielmt/thornton2.com/files/79/medium-3491.png (0.5ms)
exception = ActionController::MissingFile: Cannot read file /home/arielmt/thornton2.com/files/79/medium-3491.png
Rendered text template (0.0ms)
Completed 404 Not Found in 87.8ms (Views: 1.2ms | ActiveRecord: 0.0ms)
Sent file /home/arielmt/thornton2.com/files/79/small-3491.png (0.6ms)
exception = ActionController::MissingFile: Cannot read file /home/arielmt/thornton2.com/files/79/small-3491.png
Rendered text template (0.0ms)
Completed 404 Not Found in 185.9ms (Views: 1.2ms | ActiveRecord: 2.6ms)
Started GET "/files/feed_icon-medium-2110.png" for 208.38.215.22 at 2014-10-20 17:12:16 -0700
Processing by CardController#read as PNG
Parameters: {"explicit_file"=>true, "id"=>"feed_icon", "size"=>"medium", "rev"=>"2110"}
Sent file /home/arielmt/thornton2.com/files/190/medium-2110.png (0.4ms)
exception = ActionController::MissingFile: Cannot read file /home/arielmt/thornton2.com/files/190/medium-2110.png
Rendered text template (0.0ms)
Completed 404 Not Found in 81.7ms (Views: 1.2ms | ActiveRecord: 0.0ms)
5. As the log snippets show, I'm certainly having permission errors in addition.
wagn in production is one of the many tabs I kept open during the whole ordeal (saved in Firefox).
Also, despite the passage of time and bits of shell hacking, I am still very much a Rails novice.
Hi Ariel, I wouldn't start over just yet. I think you might actually be reasonably close.
Re #1, a big part of the reason we separated the structural and content migrations was so that we could stop doing all these incremental upgrades (or at least doing them so often). If you now run "wagn update" (as is indicated in the new Updating card), that should run all the content migrations since the first one we created. If that works, my guess is that we're in pretty good shape.
Re #2, wow those are old. I had to look, but I think the card_images and card_files should have gotten migrated when you ran the 1.8 migrations . Do you have a "local" directory in your pre-gem directory? That migration should have upgraded the card_images and card_files to local/files. *That's* what you want to move to "files" in your new deck directory.
Re #3 seems like you're ok there, right? The newer gems should be fine.
Re #4 cool, might be worth doing that again after you run the upgrade
Re #5, that one may actually be fixed by the card migration, too.
Basically, Wagn has 2 kinds of data: the database, and the files directory. If #1 and #2 go ok, we should be in good shape.
Running "wagn update" resulted in the following:
migrating structure
migrating cards
set symlink for assets
However, nothing was in public/files, public/local does not exist, and public/card_images and public/card_files are as they were.
Immediately after "wagn update" finished, I deleted tmp/* and touched tmp/restart.txt again, but nothing has changed in site behavior.
I'm looking at the migration rb you linked and having a hard time understanding how it names the files it should've moved. However, a thought occurred to me while reading it: Does the migration assume an absolute path to the deck? That is, does it assume the root is (in my case) /home/arielmt/thornton2.com/ even if I move it to /home/arielmt/wagn-migrations/wagn-1.8.0/ on another system?
DATABASE:
oof, by the look of things, the card migrations have already run. (otherwise you should see more messages below "migrating cards"). But the error in your log suggests the cards aren't correctly migrated, because there seem to be permission cards missing. that concerns me, and it suggests you might have to go through another round of incremental upgrades after all. Before we go there, though, can you run this query for me in your database:
"select id, codename from cards where codename is not null order by codename;"
FILES:
The migration should not assume an absolute path, it should take place wherever you're running it. Re the naming, yeah, that's hard to see in the migration, because the actual naming code isn't really there, it's in the attachment handling module, and the directory containing all that is determined by configuration options. Basically, the directory is the card_id and the revisions are based on the revision_id, and all that should be in "local/files" as of that release.
At some point in the process you had to move from the pre-gem setup (all-in-one) to the post-gem setup (where the gem is tucked away and the "deck" is separate). The instructions for this (eg here) involve creating a whole new deck. Is that what you did?
If so, to find the local files you may need to go back to the old pre-gem directory and look for a "local/files" directory (it's not in public; "local" is in the root of the app).
+------+----------------------------+
| id | codename |
+------+----------------------------+
| 100 | account |
| 683 | accountable |
| 2369 | account_links |
| 685 | add_help |
| 10 | administrator |
| 2363 | alerts |
| 668 | all |
| 2370 | all_plus |
| 15 | anonymous |
| 8 | anyone |
| 9 | anyone_signed_in |
| 779 | attach |
| 673 | autoname |
| 3 | basic |
| 773 | bcc |
| 787 | by_create |
| 784 | by_name |
| 178 | by_update |
| 652 | captcha |
| 5 | cardtype |
| 770 | cc |
| 33 | children |
| 2656 | coffee_script |
| 2376 | comment |
| 994 | create |
| 819 | created |
| 2586 | css |
| 17 | date |
| 700 | default |
| 2375 | delete |
| 130 | discussion |
| 2562 | double_click |
| 138 | edited |
| 92 | editors |
| 2545 | email |
| 103 | favicon |
| 18 | file |
| 2364 | foot |
| 137 | from |
| 2365 | head |
| 82 | help |
| 77 | home |
| 50 | html |
| 19 | image |
| 37 | included_by |
| 41 | includes |
| 645 | input |
| 56 | invite |
| 2657 | java_script |
| 639 | layout |
| 2557 | layout_type |
| 39 | linked_to_by |
| 43 | links_to |
| 79 | logo |
| 2677 | machine_input |
| 2673 | machine_output |
| 35 | mates |
| 2366 | navbox |
| 2367 | now |
| 20 | number |
| 86 | options |
| 649 | options_label |
| 2622 | password |
| 52 | phrase |
| 22 | plain_text |
| 47 | pointer |
| 2373 | read |
| 2360 | recent |
| 825 | referred_to_by |
| 822 | refers_to |
| 63 | request |
| 654 | right |
| 7 | role |
| 96 | roles |
| 2372 | rstar |
| 2624 | salt |
| 2666 | script |
| 2683 | script_card_menu |
| 2685 | script_html5shiv_printshiv |
| 2680 | script_jquery |
| 2684 | script_jquery_helper |
| 2682 | script_slot |
| 2681 | script_tinymce |
| 2587 | scss |
| 2361 | search |
| 30 | search_type |
| 660 | self |
| 739 | send |
| 653 | set |
| 672 | setting |
| 2626 | signin |
| 12 | signup |
| 2588 | skin |
| 2371 | star |
| 2627 | stats |
| 2625 | status |
| 699 | structure |
| 2601 | style |
| 2609 | style_functional |
| 2608 | style_jquery_ui_smoothness |
| 2610 | style_standard |
| 776 | subject |
| 89 | table_of_contents |
| 61 | thanks |
| 53 | tiny_mce |
| 55 | title |
| 64 | to |
| 51 | toggle |
| 2623 | token |
| 658 | type |
| 656 | type_plus_right |
| 2374 | update |
| 4 | user |
| 2368 | version |
| 1 | wagn_bot |
| 714 | watchers |
| 2550 | when_created |
| 2553 | when_last_edited |
+------+----------------------------+
118 rows in set (0.01 sec)
The only deviation I made from the pre-gem to gem setup was, after running "wagn new thornton2.com" and editing config/database.yml, running "cp -an ~/old/public/* ~/thornton2.com/public/" (-n for --no-clobber to avoid stepping on existing files).
I didn't understand that "local/files" was supposed to be in the deck root and not in public, so I definitely neglected to copy that, and I don't remember seeing it there. I'll look when I spin up my migration VM again.
I found local/ in the 1.8.0 migration directory, and I have copied it into its place that was missing in the live site, so a copy now lives as /home/arielmt/thornton2.com/local/ on my host.
the old "local/files" should become the new "files" (no local). as in /home/arielmt/thornton2.com/files.
If you try that, does that fix all the file loading issues?
That fixed the image loading issue.
Awesome. So now I want to look into this "no create rule" issue and figure out whether that rule card is actually missing or whether something is breaking in interpreting the rule.
Can you try loading the page "/*create" and seeing if it shows you any rules there?
If that doesn't work, you can try this SQL: "select * from cards where right_id = 994". (That's the id of the create card, based on the search results you pasted above).
If you don't get any results there, I might try running something like this from your deck root:
bundle exec wagn -r 'Card::Auth.as_bot { Card.create! :name=>"*all+*create", :content=>"Anyone Signed In" }'
does that memory error show up every time you restart the server?
I'm not able to access any part of the card *create except its view unless I know the URL.
The query returned the following 17 names (and all the other fields, which overflowed my terminal window):
discussion+*right+*create
*star+*create
*rstar+*create
HTML+*type+*create
Cardtype+description+*type plus right+*create
*watcher+*right+*create
*all+*create
*all plus+*create
Sign up+*type+*create
Role+*type+*create
Layout+*type+*create
*account+*right+*create
CSS+*type+*create
SCSS+*type+*create
Skin+*type+*create
JavaScript+*type+*create
CoffeeScript+*type+*create
The memory error shows up every time I've watched the application restart, yes.
(I have the ruby command in my /bin/sh dispatcher redirecting stderr to log/dispatch_err.log, which is why I was able to see it. That's something I wasn't able to do while using Passenger.)
Well, the good news is that everything I've seen of your data looks like everything migrated just fine, and it sounds like your files are now fine, too.
The bad news is that it kind of seems like we're now in the realm of sys admin problems that are further from my expertise. That's not an error message I've ever seen before. How much memory does this server have? Is it possible you need to reset memory limits in passenger or memcached or something?
The thing that gives me pause is that it says "saving attachments" before the error, which suggests for some reason that it's trying to create a card on bootup. If that's the case, maybe something will show up if we up the log level. Could you try adding this to config/application.rb and see if you get more interesting info in the log?
config.log_level = :debug
my shared-host server has 32 GB RAM, and I don't think I'm using memcached. They say I'm under a memory limit and that the server kills processes exceeding that limit automatically, but there's no information what that limit actually is.
I can't go back to Passenger because it calls the wrong ruby binary (too old for wagn), and my host gives no interface to Passenger except an on-off switch.
This is what was logged when rendering the Welcome card. It crashed after the last line (COMMIT):
Started GET "/" for 192.119.41.247 at 2014-10-22 21:07:53 -0700
Processing by CardController#read as HTML
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 100 AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.2ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 3 AND `cards`.`trash` = 0 LIMIT 1
(1.0ms) (
select coalesce(count(*),0) as count from cards t
where t.right_id = '100' and t.trash is false
)
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 77 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 52 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (0.9ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 2099 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'welcome' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.6ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 660 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 658 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 668 AND `cards`.`trash` = 0 LIMIT 1
(3.1ms)
select rules.id as rule_id, settings.id as setting_id, sets.id as set_id, sets.left_id as anchor_id, sets.right_id as set_tag_id
from cards rules join cards sets on rules.left_id = sets.id join cards settings on rules.right_id = settings.id
where sets.type_id = 653 and sets.trash is false
and settings.type_id = 672 and settings.trash is false
and rules.trash is false;
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 669 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.6ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 653 AND `cards`.`trash` = 0 LIMIT 1
Card Load (2.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'set+*layout' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*layout' AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.2ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 47 AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.4ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 656 AND `cards`.`trash` = 0 LIMIT 1
Card Load (2.0ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 654 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2372 AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.2ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2370 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (0.7ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 4208 LIMIT 1
Card Load (1.4ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'default_layout' AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (0.9ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 7014 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*head' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 15 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2371 AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.0ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2395 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'set+*read' AND `cards`.`trash` = 0 LIMIT 1
Card Load (3.6ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*read' AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (0.5ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10004 LIMIT 1
(1.2ms)
select refs.referee_id as party_id, read_rules.id as read_rule_id
from cards read_rules join card_references refs on refs.referer_id = read_rules.id join cards sets on read_rules.left_id = sets.id
where read_rules.right_id = 2373 and read_rules.trash is false and sets.type_id = 653;
Card Load (0.9ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 55 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (0.7ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 2193 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 103 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 19 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (0.6ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 2114 LIMIT 1
Card Load (0.9ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2397 AND `cards`.`trash` = 0 LIMIT 1
Card Load (2.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'set+*update' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*update' AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (0.6ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10006 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2534 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*update+*right' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 672 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'setting+*right' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.6ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'set+*option' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*option' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 30 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (1.4ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10148 LIMIT 1
Card Load (2.1ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'anyone_signed_in' AND `cards`.`trash` = 0 LIMIT 1
Card Load (2.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 7 AND `cards`.`trash` = 0 LIMIT 1
Card Load (2.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2618 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'set+*style' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*style' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2673 AND `cards`.`trash` = 0 LIMIT 1
Card Load (8.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*all+*style+*machine_output' AND `cards`.`trash` = 0 LIMIT 1
Card Load (2.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'pointer+*machine_output' AND `cards`.`trash` = 0 LIMIT 1
Card Load (24.4ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 18 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (0.8ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10436 LIMIT 1
Card Load (8.9ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2562 AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.1ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 51 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (8.6ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10206 LIMIT 1
Card Load (0.9ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2686 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'set+*script' AND `cards`.`trash` = 0 LIMIT 1
Card Load (17.1ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*script' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2685 AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2657 AND `cards`.`trash` = 0 LIMIT 1
Card Load (12.5ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*all+*script+*machine_output' AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.1ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2675 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.9ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2669 AND `cards`.`trash` = 0 LIMIT 1
Card Load (6.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*script+*right' AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (5.3ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10346 LIMIT 1
Card Load (1.6ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2677 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.9ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*all+*script+*machine_input' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.9ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'pointer+*machine_input' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2670 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (1.0ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10347 LIMIT 1
Card::Revision Load (0.7ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10363 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'script_jquery' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'script_tinymce' AND `cards`.`trash` = 0 LIMIT 1
Card Load (2.6ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'script_slot' AND `cards`.`trash` = 0 LIMIT 1
Card Load (9.6ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2656 AND `cards`.`trash` = 0 LIMIT 1
Card Load (7.1ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'script_card_menu' AND `cards`.`trash` = 0 LIMIT 1
Card Load (6.4ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'script_jquery_helper' AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (1.8ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10440 LIMIT 1
(0.5ms) BEGIN
(4.2ms) delete from card_revisions where card_id=2689 and id > 10440
SQL (5.1ms) INSERT INTO `card_revisions` (`card_id`, `content`, `created_at`, `creator_id`) VALUES (2689, 'script: jquery\nscript: tinymce\nscript: decko\nscript: card menu\nscript: jquery helper', '2014-10-23 04:07:56', 15)
Card Load (6.4ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 2396 AND `cards`.`trash` = 0 LIMIT 1
Card::Revision Load (4.9ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10005 LIMIT 1
(8.5ms) UPDATE `cards` SET `current_revision_id` = 10442, `updated_at` = '2014-10-23 04:07:56' WHERE `cards`.`id` = 2689
SQL (1.2ms) DELETE FROM `card_references` WHERE `card_references`.`referer_id` = 2689
(0.4ms) update cards set references_expired=NULL where id=2689
Card::Revision Load (0.6ms) SELECT `card_revisions`.* FROM `card_revisions` WHERE `card_revisions`.`id` = 10442 LIMIT 1
SQL (0.5ms) INSERT INTO `card_references` (`present`, `ref_type`, `referee_id`, `referee_key`, `referer_id`) VALUES (1, 'L', 2680, 'script_jquery', 2689)
SQL (0.3ms) INSERT INTO `card_references` (`present`, `ref_type`, `referee_id`, `referee_key`, `referer_id`) VALUES (1, 'L', 2681, 'script_tinymce', 2689)
SQL (1.4ms) INSERT INTO `card_references` (`present`, `ref_type`, `referee_id`, `referee_key`, `referer_id`) VALUES (1, 'L', 2682, 'script_slot', 2689)
SQL (1.6ms) INSERT INTO `card_references` (`present`, `ref_type`, `referee_id`, `referee_key`, `referer_id`) VALUES (1, 'L', 2683, 'script_card_menu', 2689)
SQL (0.4ms) INSERT INTO `card_references` (`present`, `ref_type`, `referee_id`, `referee_key`, `referer_id`) VALUES (1, 'L', 2684, 'script_jquery_helper', 2689)
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 699 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.6ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*all+*script+*machine_input' AND `cards`.`trash` = 0 LIMIT 1
(1.1ms) (
select t.name from cards t
where t.left_id = '2689' and t.trash is false ORDER BY t.updated_at desc
)
Card::Reference Load (4.9ms) SELECT `card_references`.* FROM `card_references` WHERE `card_references`.`referee_id` = 2689
Card Load (5.6ms) SELECT `cards`.* FROM `cards` INNER JOIN `card_references` ON `card_references`.`referer_id` = `cards`.`id` WHERE `card_references`.`referee_key` = '*all+*script+*machine_input'
(12.4ms) (
select t.name from cards t
where t.left_id in (
select tx.id from cards tx
where tx.left_id = '47' and tx.trash is false
) and t.right_id in (
select tx.id from cards tx
where tx.codename = 'type_plus_right' and tx.trash is false
) and t.trash is false ORDER BY t.updated_at desc
)
Card Load (4.3ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 714 AND `cards`.`trash` = 0 LIMIT 1
Card Load (1.3ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*all+*script+*watcher' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'pointer+*watcher' AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 638 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.8ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`id` = 5 AND `cards`.`trash` = 0 LIMIT 1
Card Load (0.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = 'cardtype+*watcher' AND `cards`.`trash` = 0 LIMIT 1
Card::Reference Load (4.8ms) SELECT `card_references`.* FROM `card_references` WHERE `card_references`.`referee_id` = 2689 AND `card_references`.`ref_type` = 'I'
Card Load (2.7ms) SELECT `cards`.* FROM `cards` WHERE `cards`.`key` = '*all+*script+*machine_input+*watcher' AND `cards`.`trash` = 0 LIMIT 1
[paperclip] Saving attachments.
(1.2ms) COMMIT
More specifically, Passenger calls the system ruby:
/usr/bin/ruby --version
ruby 1.8.7 (2010-08-16 patchlevel 302) [x86_64-linux]
And right now I'm using this ruby:
~/.rbenv/shims/ruby --version
ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-linux]
Might you consider setting PassengerRuby in a .htaccess file?
Huh, learn something new every day. I was treating Passenger as a magic black box that only my Web host could control. Thank you for finding that helpful bit of documentation; I'll try it later today.
I'm back to using Passenger, and I'm still getting a crash on the first occurrence of "[paperclip] saving attachments" after most rails restarts.
I also did a nuke-and-reimport of my database because, while troubleshooting this problem, spammers took advantage of Recaptcha's absence to spam cards with the anyone-can-edit rule. Immediately after reimporting my database, I ran "wagn update" and restarted rails.
I noticed that I accidentally left a syntax error on the *css card that was present during the whole migration, and---purely by coincidence---I was able to log in and edit cards. I edited the *css card to comment out the syntax error (I had meant to comment out everything during the upgrade), and I'm now using the default CSS theme aside from the gear and triangle icons in card header bars.
I'm making no headway in this problem, so I spent the last two days re-migrating my wagn. I can continue with the post-migration problem if need be, but I had to deactivate it because the spam problem was too much. This time, I started with the same 1.5.3 database but with the *css card blanked.
The migration was performed on a Debian 7 (Wheezy) VM with 256 MB RAM (all the memory I can spare on my poor lappy). It's running ruby 1.8.7 (2012-02-08 patchlevel 358) [i486-linux]. I can upgrade it to ruby 1.9.3 in a matter of seconds once I reach a version of Wagn that supports it.
I downloaded the .zip files from https://github.com/wagn/wagn from the branches/tags matching the Wagn version numbers. Before each migration attempt, I unzipped the version into my deck, and I ran `bundle install --without hosting postgres sqlite test`. After each migration success, I dumped and gzipped my database and tarred up my deck.
Migrating from Wagn 1.5.3 to 1.6.0 was successful. I had to uncomment ruby-openid in Gemfile, and `bundle exec rake --tasks` showed db:migrate but no wagn:migrate task.
Migrating from Wagn 1.6.0 to 1.6.1 was successful. The steps I had to do were the same.
I have not yet been able to migrate from Wagn 1.6.1 to either 1.7.0 or 1.7.2. Again, I had to uncomment ruby-openid in Gemfile, and again `rake --tasks` showed db:migrate but not wagn:migrate. However, running `bundle exec rake db:migrate` errored out before migration began. Right after printing "----------- Wagn Loaded -----------", rake aborted with "uninitialized constant Wagn::Initializer". The latest line in the trace not in /var/lib/gems/1.8/ was config/initializers/wagn_init.rb:1. wagn_init.rb consists only of the single line "Wagn::Initializer.run".
This trace was performed with the command `bundle exec rake --trace db:migrate 2>&1 | tee wagn-1.6.1-to-wagn-1.7.2-migration.log`:
rake/rdoctask is deprecated. Use rdoc/task instead (in RDoc 2.4.2+)
DEPRECATION WARNING: Rake tasks in vendor/plugins/asset_packager/tasks, vendor/plugins/open_id_authentication/tasks, and vendor/plugins/recaptcha/tasks are deprecated. Use lib/tasks instead. (called from /var/lib/gems/1.8/gems/rails-2.3.11/lib/tasks/rails.rb:10)
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Invoke setup (first_time)
** Execute setup
** Execute environment
----------- Wagn Loaded -----------
rake aborted!
uninitialized constant Wagn::Initializer
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:466:in `load_missing_constant'
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:106:in `const_missing'
/home/arielmt/migration/thornton2.com/config/initializers/wagn_init.rb:1
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:171:in `load_without_new_constant_marking'
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:171:in `load'
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:547:in `new_constants_in'
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:171:in `load'
/var/lib/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:622:in `load_application_initializers'
/var/lib/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:621:in `each'
/var/lib/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:621:in `load_application_initializers'
/var/lib/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:176:in `process'
/var/lib/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `send'
/var/lib/gems/1.8/gems/rails-2.3.11/lib/initializer.rb:113:in `run'
/home/arielmt/migration/thornton2.com/config/environment.rb:11
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:182:in `require'
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:182:in `require'
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:547:in `new_constants_in'
/var/lib/gems/1.8/gems/activesupport-2.3.11/lib/active_support/dependencies.rb:182:in `require'
/var/lib/gems/1.8/gems/rails-2.3.11/lib/tasks/misc.rake:4
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:205:in `call'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:205:in `execute'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:200:in `each'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:200:in `execute'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:158:in `invoke_with_call_chain'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:176:in `invoke_prerequisites'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:174:in `each'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:174:in `invoke_prerequisites'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:157:in `invoke_with_call_chain'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/task.rb:144:in `invoke'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:112:in `invoke_task'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `each'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:90:in `top_level'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:84:in `top_level'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:62:in `run'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:129:in `standard_exception_handling'
/var/lib/gems/1.8/gems/rake-0.9.2/lib/rake/application.rb:59:in `run'
/var/lib/gems/1.8/gems/rake-0.9.2/bin/rake:32
/usr/local/bin/rake:23:in `load'
/usr/local/bin/rake:23
Tasks: TOP => db:migrate => environment
Running without hoptoad
Hmm, I'm actually a little skeptical that remigrating will solve the memory problem.
Here's one thing you might consider: what if you put the fully migrated version (meaning the db and the files directory) on ye olde laptoppe and try firing up the server there?
I can at least shed a little light on why there's so much memory usage right at the beginning. Your server is trying to generate compressed CSS and JavaScript files based on multiple cards. This has to happen exactly once (at least until you update CSS or JavaScript). If you got that to work and could start loading pages locally, then you could probably copy the db and the files *back* over to the live server and have it work. You do need both the db and the files directory, because this process updates a File card for both CSS and JavaScript, and the File card involves both kinds of data.
Admittedly, this might be slow on the laptoppe, but at least it shouldn't go nuclear, and once the files have been generated, I wouldn't anticipate this kind of spike.
Re the spam; once you get things working, you might make sure you're using captcha (see the *captcha setting) and have the *read permissions set the way you want them.
I think I can run Wagn easily enough on my laptop. All I have to do is run script/server and browse to the same port with any Web browser, even lynx or curl, right?
I'd still like to understand the new Wagn::Initializer problem I ran into this morning so I can go ahead with repeating the migration. The benefits I see are that I'll be running without spam polluting a card's history in my DB, Wagn won't have to deal with parse errors when trying to optimize my CSS and JS, and I'll have a better understanding of why the mistakes I made during the initial upgrade attempt were mistakes.
I think you just need to go 1.5.3 to 1.6.1 to 1.8.0 to present.
The current migration code gives this message when your data is older than 1.6.1:
"
Your database is not ready to be migrated to #{Wagn::Version.release}.
You will need to do incremental upgrades.
Please first install version 1.6.1 and run `rake db:migrate`.
Then install version 1.8.0 and run `rake db:migrate`.
Sorry about this! We're working to minimize these hassles in the future.
"
I can't remember the complete rationale for choosing these releases (Wagn 1.7 came out back in 2011), but basically before we separated structural and content migrations it was very difficult to keep supporting old migrations, so we had to set up increments like this. Still, you can be pretty confident that if you go straight from 1.6.1 to 1.8.0 you won't miss anything.
I'm not sure I understand the comment with the parse errors; did you change CSS/ js somehow?
Remigration: I'll try skipping 1.7.x. Thanks.
First try: Instead of commenting out the CSS on the *css card like I intended, I accidentally left half a class uncommented, with dangling properties and a closing brace with no opening brace in its definition. This happened immediately prior to the upgrade, and I didn't catch it until after the upgrade was finished and the new version was live. If Wagn tried to optimize the CSS then, it would've had to struggle with the error. I went back and looked at the start of log/production.log on the very first access, before I made the screenshot on this ticket, and saw this:
Started GET "/" for 192.119.41.247 at 2014-10-20 06:49:05 -0700
Processing by CardController#read as HTML
[paperclip] Saving attachments.
Error rendering *head / raw: Card::Oops : Stylesheet Error:
Invalid CSS after " display: inline": expected "{", was ";"
Rendered text template (0.0ms)
Completed 200 OK in 12122.4ms (Views: 47.3ms | ActiveRecord: 771.7ms)
Started GET "/files/*logo-small-3491.png" for 192.119.41.247 at 2014-10-20 06:49:24 -0700
Processing by CardController#read as PNG
Parameters: {"explicit_file"=>true, "id"=>"*logo", "size"=>"small", "rev"=>"3491"}
Sent file /home/arielmt/thornton2.com/files/79/small-3491.png (0.6ms)
exception = ActionController::MissingFile: Cannot read file /home/arielmt/thornton2.com/files/79/small-3491.png
Rendered text template (0.0ms)
Completed 404 Not Found in 85.0ms (Views: 1.3ms | ActiveRecord: 0.0ms)
Started GET "/files/*logo-medium-3491.png" for 192.119.41.247 at 2014-10-20 06:49:24 -0700
Processing by CardController#read as PNG
Parameters: {"explicit_file"=>true, "id"=>"*logo", "size"=>"medium", "rev"=>"3491"}
Sent file /home/arielmt/thornton2.com/files/79/medium-3491.png (0.5ms)
exception = ActionController::MissingFile: Cannot read file /home/arielmt/thornton2.com/files/79/medium-3491.png
Rendered text template (0.0ms)
Completed 404 Not Found in 31.5ms (Views: 1.2ms | ActiveRecord: 0.0ms)
Started GET "/files/feed_icon-medium-2110.png" for 192.119.41.247 at 2014-10-20 06:49:24 -0700
Processing by CardController#read as PNG
Parameters: {"explicit_file"=>true, "id"=>"feed_icon", "size"=>"medium", "rev"=>"2110"}
Sent file /home/arielmt/thornton2.com/files/190/medium-2110.png (0.6ms)
exception = ActionController::MissingFile: Cannot read file /home/arielmt/thornton2.com/files/190/medium-2110.png
Rendered text template (0.0ms)
Completed 404 Not Found in 97.2ms (Views: 1.5ms | ActiveRecord: 0.0ms)
Started GET "/wagn/BlkAlloc" for 66.249.69.9 at 2014-10-20 06:50:12 -0700
Processing by CardController#read as */*
Parameters: {"id"=>"BlkAlloc"}
[paperclip] Saving attachments.
Error rendering *head / raw: Card::Oops : Stylesheet Error:
Invalid CSS after " display: inline": expected "{", was ";"
Rendered text template (0.0ms)
Completed 200 OK in 2164.5ms (Views: 1.4ms | ActiveRecord: 51.5ms)
Ahhhh. That error I understand.
As you appear to have gathered, It means that in the process of concatenating and compressing your CSS (an improvement that speeds up performance), the CSS libraries detected an error in the *css card.
Here's how you fix it.
go to /*css?style=simple_skin in the browser. This will make the page load with a simple grey-and-white skin that doesn't use the *css card. You can should be able to add ?style=simple_skin to any page that's breaking (including the signin page if that's an issue).
-e
I have my wagn running in a VM, and I fixed the *css card. However, I'm still facing four major problems.
*) I'm getting "error rendering *account links (raw view)" as the content of the "*account links" card whenever I'm not signed in, but I'm getting the link to my user card, the invite link, and the signout link as its content whenever I am signed in. I have two Web browsers in the VM: Iceweasel, which is signed in; and Chromium, which is not.
*) If I sign out, I won't be able to sign in again because the *signin card shows "error rendering *signin (core view)" as its content while not signed in. (It renders properly while signed in.) This appeared only after changing the content of *css to nothing but a string of CSS comments.
*) Going through Config and checking card rules, I'm seeing only the text "not a rule" everywhere that I should be seeing access to the "create" rule. The cards "*create" and "*create+*right" do exist, but each of them is a different type: *create is a "Basic" card while *create+*right is a "Set" card.
*) I verified my ReCaptcha keys on my Google account are pasted correctly into config/application.rb (as config.recaptcha_public_key and config.recaptcha_private_key in class Application of module Thornton2Com), and both "*captcha" and "Discussion+*right+*captcha" are set to yes. Nevertheless, I'm able to post to Discussion cards in Chromium (where I'm not signed in) without being challenged with a captcha.
I got the idea of changing the type for *create to Setting, but it isn't an option in the list. I saved a DB snapshot and tried deleting *create, but Wagn wouldn't let me. I'm going to need to edit the DB directly, ain't I.
I found out what caused the *create card to exist as a Basic card. In May '12, I was fumbling around trying to make it so anyone could add +discussion cards but only those signed in could add any other cards. I created the card discussion+*right+*create, not realizing that *create would be created as well, in a futile attempt to make that happen. The version I was on at the time was 1.5.3.
I restored my DB from snapshot and edited the cards table, row where name is *create, type_id field to be the same as the *read and *update rows. This change fixed three of the four major problems I noted above and allowed me to use Wagn to fix the captcha rules that were the fourth major problem.
Moving Wagn with my database to a virtual machine, fixing the card type error in the database, upgrading and testing Wagn there, and moving Wagn back to my shared host was the solution. I'm back up and running, and now on 1.14.1.
WOOHOO!
Sorry I didn't help much in the home stretch; I was offline for most of Thanksgiving ;)