Recent content by Zak Smith

Just found the same issue with the 1.1.1 upgrade. I updated the support ticket with details. I reverted the template but its content is definitely not reverted to the default (style 0) version. I've left it without applying my normal diffs so you can take a look. thanks.

Details in the ticket - thanks. You can log in via ssh and check out a text dump of the database from last night (mysqldump), run mysql, or log into the admin cp.

Here's an illustration. In the first capture, we have the one that exhibits part of the issue. In style 3 ("TESTING"), message_user_info was changed a long time ago. It was listed in the Obsoleted Templates list. I did hit Revert from there. But obviously this is still my modified...

I have one template (from an obsolete style) left in the state where it has been "reverted" but the modified one is still showing up. If you want to poke around the database to see what's up I can provide a login to the machine. I think all my production templates are fixed, but I am kind of...

If I take an up to date template and add a comment and repeat the process, I cannot get it to happen. However, this is not quite the same flow because I'm not hitting the Revert button from the Outdated Template list. IE, there is no way I can put stuff back into the Outdated List. I did have...

I was using 1.04. Just updated to 1.1. I have about a dozen templates with minor changes as listed by "Outdated templates." My normal procedure done on all updates until now is: 1. On the "prior" version, run a script that downloads (with WebDAV) all templates from style 0 ("master") and my...

That's the point of this very minor mod.

Not sure. If you open the if it needs to be closed somewhere... ? I've ported this mod up to the latest version and it still works fine.

So here's how one of the diffs looked $ diff 0/thread_watch 2/thread_watch 30c30 <<input type="radio" name="email_subscribe" value="1" id="ctrl_email_subscribe_1" /> --- ><input type="radio" name="email_subscribe" value="1" id="ctrl_email_subscribe_1" checked="checked" autofocus="true" /> 36c36...

Knowing that eventually I'd have to merge my template changes to new versions of XenForo, I create these scripts. They're useful for guys who prefer to do development on unix (as opposed to web forms), or want an easier way to diff different versions of templates. They can also ensure that you...

Perhaps. Thank you for your time.

That a non-unified conception of user permissions has lead to code that does not operate in a consistent manner in this case does not justify the behavior. Every bug has an explanation, that's not what bug reports are about (ie, what the behavior is vs what it ought to be).

That statement is false. The user does not have permission to view/change styles because only one style has "Allow user selection" checked. The admin class of users does have permission to select styles with that option selected. QED. Whether or not the permission the admin class has is...

That's an interesting interpretation of the concept of user permissions. There is an option that is shown to certain classes of users but not shown to other classes of users. Thus, it is an implicit attribute, or "permission", of the user classes -- whether or not it is considered by the...

I have three styles, 1. the "Default Style" 2. TBAC1 (the production one) - set as default 3. - child of TBAC1, for testing only #1 and #3 have "Allow user selection" unchecked. From the Admin control panel, if I use Test Permissions on a normal user (ie, a dummy user "John Smith"), the...