Recent content by alethiophile

I'm trying to upgrade from the old Threadmarks Pro after going from Xenforo 1.5 -> 2.2. On running the upgrade command, I get: [root@guiling forum]# php cmd.php xf-addon:upgrade SV/Threadmarks...

I'm currently trying to set up a node which can be viewed by unconfirmed (registered) users, but not by guests. Giving view permission to the "Unregistered / Unconfirmed" group shows it to both groups. Various other forum settings allow you to condition directly on the user state, but I can't...

Is there a special procedure for upgrading to this from vanilla Threadmarks?

Okay, thanks.

It looks as if the page to define threadmark categories is limited to superadmins, not just admins. Is there a particular reason for that?

I noticed a bug today: it seems when a user has "delete own posts" but not "delete own threads" under this addon, they can delete their own threads anyway by deleting the OPs. For the moment have just turned off "delete own posts", which is redundant with the normal section's version anyway...

I tried IUS, but it conflicts with the native PHP package, and properly removing that to install the IUS version was more work than I wanted to do with the forum down. Ended up installing 5.6 through SCL, which doesn't conflict with anything, and lets the FastCGI work with the new PHP without...

Attempting to install this, and it errors out with "String could not be parsed as XML" on trying to read the addon file. I xmllint'd the file as a sanity check, and it is valid, so probably didn't get corrupted somehow. EDIT: Turns out this was an unrelated configuration issue that was keeping...

I ended up just upgrading my PHP, which I probably should do anyway. But 5.4 is still the default/latest version available in CentOS/RHEL 7, so compatibility is good.

It seems that this addon uses PHP syntax unique to 5.5+ (try/finally). It might be good to document this requirement; I started running into random syntax errors and refusal to rebuild the search table.

It seems this addon uses PHP try { } finally { }, and thus requires PHP 5.5+. This isn't noted in requirements. EDIT: On second look, seems it's in the plain Search Improvements addon, not this one.

This is very useful. What's the recommended procedure for upgrading while preserving existing threadmarks? Will just installing over the top work?

Failing back to the backup (some 4-5 days old) was an option, but not a great one. In the end I successfully got the full thing up, with only loss of user data that originated after the switch. This just worked by taking a full mysqldump from the imported (test) board, cutting off everything...

Okay, by re-running the import I've gotten a test database with a correct set of users. I've verified that user IDs are the same for each user in the test DB and the real one. Thus, the password data are available. Questions: 1. Is there anything wrong with just transplanting this table, and...

All check out positive. The restore file is indeed what's truncated, and all the data are still in the old DB. I'm vaguely hoping I can get users' passwords back by running another import (into a temporary DB) and looking at the auth table there.