foxfirefey: A fox colored like flame over an ornately framed globe (Default)
foxfirefey ([personal profile] foxfirefey) wrote in [site community profile] dw_dev2009-07-22 02:12 pm
Entry tags:

Worrisome error involving user prop "s1_lastn_style"

So, due to some difficulties with my VPS provider, I've had to reinstall Dreamwidth from scratch. I didn't mind! It was a great opportunity to brush up some of the installation documentation and reacquaint myself with the installation process. However, I've run into an awkward error involving user prop "s1_lastn_style" not existing in this new installation.

The Apache error log says this:

Prop does not exist: user - s1_lastn_style at /home/dw/cgi-bin/ljlib.pl line 780.
[Wed Jul 22 16:04:32 2009] [error] [client 67.160.37.217] Invalid userprop s1_lastn_style passed to LJ::load_user_props. at /home/dw/cgi-bin/LJ/User.pm line 6815.\n, referer: http://foxfirefey.dev.memewidth.org/profile

I can stop it from happening by commenting out an offending line of code:

push @needed_props, $s1prop if $eff_view =~ /^(?:calendar|day|friends|lastn)$/;


Which you can see in more context here:

diff -r 215c981ac1f0 cgi-bin/LJ/User.pm
--- a/cgi-bin/LJ/User.pm        Tue Jul 21 23:08:22 2009 -0500
+++ b/cgi-bin/LJ/User.pm        Wed Jul 22 20:51:35 2009 +0000
@@ -8309,7 +8309,7 @@
     $u->{'_journalbase'} = LJ::journal_base($u->{'user'}, $opts->{'vhost'});
 
     my $eff_view = $LJ::viewinfo{$view}->{'styleof'} || $view;
-    my $s1prop = "s1_${eff_view}_style";
+    #my $s1prop = "s1_${eff_view}_style";
 
     my @needed_props = ("stylesys", "s2_style", "url", "urlname", "opt_nctalklinks",
                         "renamedto",  "opt_blockrobots", "opt_usesharedpic", "icbm",
@@ -8320,7 +8320,7 @@
     # is reply/month/entry/res and that means it *has* to be S2--S1 defaults to a
     # BML page to handle those, but we don't want to attempt to load a userprop
     # because now load_user_props dies if you try to load something invalid
-    push @needed_props, $s1prop if $eff_view =~ /^(?:calendar|day|friends|lastn)$/;
+    #push @needed_props, $s1prop if $eff_view =~ /^(?:calendar|day|friends|lastn)$/;
 
     # preload props the view creation code will need later (combine two selects)
     if (ref $LJ::viewinfo{$eff_view}->{'owner_props'} eq "ARRAY") {
`

But, I'm not sure that's the entire issue, so I'd really like people with more experience to know about this, just in case it's important. [personal profile] sophie has been helping me with suggestions, and I can note that:

* I have upgraded to tip
* Deleting all the files that are obsolete with $LJHOME/bin/cvsreport.pl -n -1 | xargs -i rm $LJHOME/{} has not fixed it
* This user should be using S2--the default style is S2 Negatives, and I haven't changed anything since account creation on them, and when I comment out that line the page does display Negatives.

[personal profile] sophie has also had me do a query of:

SELECT `userid`, `name`, `value` FROM `userprop` LEFT OUTER JOIN `userproplist` USING (`upropid`);


To make sure there are no null userprops or stylesys ones.
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2009-07-22 09:25 pm (UTC)(link)
I think this might be related to bug 1378.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

[staff profile] mark 2009-07-23 12:28 am (UTC)(link)
The s1 props should die, including all references to them in the code. Might be a little tricky to remove them, but I think your patch is probably right. Test a bunch!
kareila: Rosie the Riveter "We Can Do It!" with a DW swirl (dw)

[personal profile] kareila 2009-07-24 01:19 am (UTC)(link)
The problem is described right there in the comment: "load_user_props dies if you try to load something invalid." $u->preload_props is just a user method that calls LJ::load_user_props.

Now that we've pulled all the s1 props out, anything that tries to load any them will break. It's okay not to try to load them, because we weren't using them in the code anyway, because s1 is dead.

The reason it doesn't break on existing installs is that the properties still exist in the MySQL database; they've only been removed from the file that populates the database for new installs (proplists.dat).