History

History [Paid] 2.6

No permission to buy ($35.00)

AndyB

Well-known member
AndyB submitted a new resource:

History - Displays a list of previously viewed threads.

Premium upgrade:

This XF2 add-on along with the entire collection can be purchased for $25.00 USD. Your Premium upgrade will allow you to download as many XF2 add-ons as you like for one year. Please see the entire collection located in the Resources area at this URL:

https://www.xf2addons.com/

Note: all my XF1 add-ons are still 100% free and are supported by donations.

Description:

Displays a list of previously viewed threads.

As you browse different threads...

Read more about this resource...
 
Added xf_history table
I hope that is a typo? xf_tablename is reserved for Core XenForo use only. At a minimum, it needs to be xf_PREFIX_tablename eg, something like xf_andyb_history.
 
I hope that is a typo? xf_tablename is reserved for Core XenForo use only. At a minimum, it needs to be xf_PREFIX_tablename eg, something like xf_andyb_history.
Where did you come up with this?

Performing a reinstall in this way is a destructive operation and it will remove all data you have created. Additionally, bear in mind that only tables with the xf_ prefix are cleared. This is a significant reason for the recommendation that all tables, even for add-ons, should be prefixed with xf_

Granted, the table name would be better with andyb in it in case XF decides to do something with a history table, but it isn't really needed. It would also keep all of his tables in one place in the table listing if he named all of his tables with andyb. ;)

Again, it would be good practice to use andyb in his tables, but there's nothing requiring it that I know of.
 
Where did you come up with this?
@Mike and @Chris D have mentioned this several times over the years, plus is just common sense practice to avoid potential table name and field name conflicts between core tables/fields and addon tables/fields. Mike even explained recently that the 1st party addons are now using the xf_PREFIX_tablename standard as well (setting the standard for 3rd party addons to follow).

Here is a recent response from Mike in a bug report that involves a non prefixed table : https://xenforo.com/community/threads/upgrade-from-1-5-to-2-beta-error.133444/#post-1171575
When it comes to tables, you must use the xf_ prefix and then a unique prefix for you/your add-on. To emphasize this, the RM now uses xf_rm_resource as a table; MG uses xf_mg_category.

To name a few of the recent conflicts:

There is an addon that adds the tables xf_thread_field and xf_thread_field_value instead of xf_PREFIX_thread_field xf_PREFIX_thread_field_value. When attempting to upgrade to XF2, those clashed with the tables that XF2 added to support thread fields.

xf_wdget table is another example of a non prefixed able that is/was causing upgrade problems because that table is being added/used by the [bd] Widget Framework in XF1 and XF2 now also has its own table named xf_widget.

IIRC, they added in additional handling to prevent the upgrades from puking out for KNOWN conflicts (like the ones I listed).

Table Name: xf_PREFIX_tablename eg. xf_rm_resource
Field Name (when adding to a core table): PREFIX_fieldname eg, xfrm_resource_count
 
@Mike and @Chris D have mentioned this several times over the years, plus is just common sense practice to avoid potential table name and field name conflicts between core tables/fields and addon tables/fields. Mike even explained recently that the 1st party addons are now using the xf_PREFIX_tablename standard as well (setting the standard for 3rd party addons to follow).

Here is a recent response from Mike in a bug report that involves a non prefixed table : https://xenforo.com/community/threads/upgrade-from-1-5-to-2-beta-error.133444/#post-1171575


To name a few of the recent conflicts:

There is an addon that adds the tables xf_thread_field and xf_thread_field_value instead of xf_PREFIX_thread_field xf_PREFIX_thread_field_value. When attempting to upgrade to XF2, those clashed with the tables that XF2 added to support thread fields.

xf_wdget table is another example of a non prefixed able that is/was causing upgrade problems because that table is being used by added the [bd] Widget Framework in XF1 and XF2 now also has its own table named xf_widget.

IIRC, they added in additional handling to prevent the upgrades from puking out for KNOWN conflicts (like the ones I listed).

Table Name: xf_PREFIX_tablename eg. xf_rm_resource
Field Name (when adding to a core table): PREFIX_fieldname eg, xfrm_resource_count
Thank you!

I had not seen that until you pointed it out. But, I've been doing it automatically myself :)
 
  • Like
Reactions: Bob
We do mention it elsewhere in the dev docs, though maybe it's not clear. We specifically mention it in the context of column names:
The naming here is significant; columns added to core XF tables should always be prefixed. This serves two important purposes. The first being that there is less risk of conflicts happening with duplicate column names, in case XF or another add-on has reason to add that column in the future. The second being that it helps more easily identify which columns belong to which add-ons in case some issues arise in the future.
Then later on when talking about adding a column:
The same principles apply here in terms of naming. A significant difference is that all tables should additionally be prefixed with xf_.
"The same principles" being that some prefix should be applied to the table name in addition to the xf_ prefix. So, indeed, in this case, xf_andyb_history would be a much better name.

If for whatever reason XF adds a xf_history table in the future, we'll have problems with this add-on.
 
Top Bottom