[DBTech] DragonByte Shop [Paid] 6.7.0

[DragonByte Tech]

1. For whatever reason, name effects are being applied randomly. So if one member with a fancy name is online, it seems like the next user will also have the same name style, even if they haven't bought it:

While I still can't replicate this, in the next version I have made a change to the way user name styles and user title styles are loaded.

Previously, the CSS granted by the items would be added dynamically to the style property, so it would look like this:
<span style="font-weight: bold;">xXxCoolUsernamexXx</span>

Now, I've re-written it to work similar to the way user group styling works in XF, where it caches all the CSS and dynamically generates CSS classes. It'll now look like this:
<span class="username--dbtechShopStyle$">xXxCoolUsernamexXx</span>
(where $ is the internal purchase ID for the particular user name style item)

There's no way for me to guarantee it will fix your issue, but it just might.

The same change has been applied to user title styles, although you didn't specifically report that issue (yet).

 

[Feanor]

I have been testing this version a bit and these are things I found that may need to be fixed or suggestions I would make. Also, I should note that I'm coming from the vB version, not the previous XF version. I'm really liking the trade feature.

1. Item stock doesn't seem to work.

2. No check boxes on the main inventory page for active and hidden. When there are a ton of items in the inventory, it takes a long time to make adjustments by clicking each item to make these changes. Any chance this could come back?

3. No quantity of items sold statistic in the shop. This was also from a previous version.

4. I like how the permissions work for categories/items, but would it be possible to split the "View" permission into two: view in postbit/inventory and view in shop? The reason for this is because some items won't always be shown/sold in the shop for everyone, but I wouldn't want to hide them from the postbit or make it look like the items are gone completely.

Thanks!

 

[DragonByte Tech]

1. Item stock doesn't seem to work.

Can you elaborate, please?

2. No check boxes on the main inventory page for active and hidden. When there are a ton of items in the inventory, it takes a long time to make adjustments by clicking each item to make these changes. Any chance this could come back?

It would clutter the interface too much so sadly no, sorry.

3. No quantity of items sold statistic in the shop. This was also from a previous version.

Can you elaborate?

4. I like how the permissions work for categories/items, but would it be possible to split the "View" permission into two: view in postbit/inventory and view in shop? The reason for this is because some items won't always be shown/sold in the shop for everyone, but I wouldn't want to hide them from the postbit or make it look like the items are gone completely.

You can override the "Buy items" permission per item to achieve this

 

[Feanor]

Can you elaborate, please?

The stock amount of the item isn't displayed anywhere in the shop and when the amount is set to 0 it can still be purchased.

Can you elaborate?

One of the pieces of information that the shop used to display with each item was how many of them have been sold so far, in the field called Sales Statistics. There was other information here as well:

You can override the "Buy items" permission per item to achieve this

This removes the purchase button, but I'm trying to not have it show up in the shop at all. How can this be done without it being removed from users' inventory/postbit?

 

[DragonByte Tech]

The stock amount of the item isn't displayed anywhere in the shop and when the amount is set to 0 it can still be purchased.

Confirmed, will be resolved in the next version, thanks.

One of the pieces of information that the shop used to display with each item was how many of them have been sold so far, in the field called Sales Statistics.

This, along with stock, will be displayed in the sidebar on the item overview page in the next version.

This removes the purchase button, but I'm trying to not have it show up in the shop at all. How can this be done without it being removed from users' inventory/postbit?

Can you elaborate on the use case for this? At the moment, I don't see the value in splitting up the permissions, in my view it will only add extra confusion for admins. If you could explain your use case I might be convinced

 

[Feanor]

Confirmed, will be resolved in the next version, thanks.


This, along with stock, will be displayed in the sidebar on the item overview page in the next version.

Good to hear, thank you.

Can you elaborate on the use case for this? At the moment, I don't see the value in splitting up the permissions, in my view it will only add extra confusion for admins. If you could explain your use case I might be convinced

My site has hundreds of custom items, many of which are associated with seasonal events, so they are rotated in and out of the shop. Some may even show up in the shop only once or twice and never return because they are much rarer items, so users must then trade them with each other for a higher price as the rarity increases. Forcing them to be listed in the shop would cause hundreds of unpurchasable items to be displayed here. This is even more relevant for some items that we give out as prizes (or through other methods) and are never actually sold in the shop. It's okay if the item has an inventory page, but I wouldn't want all of them listed anywhere in the shop itself because users will see tons of items that aren't for sale.

Edit: I wanted to also mention that with the old one, items had an "Active" check box for the item itself and one for each shop. Since this (and different shops) are gone, splitting the view permission would basically be a replacement to achieve the same thing, but by usergroup.

 

[DragonByte Tech]

My site has hundreds of custom items, many of which are associated with seasonal events, so they are rotated in and out of the shop. Some may even show up in the shop only once or twice and never return because they are much rarer items, so users must then trade them with each other for a higher price as the rarity increases. Forcing them to be listed in the shop would cause hundreds of unpurchasable items to be displayed here. This is even more relevant for some items that we give out as prizes (or through other methods) and are never actually sold in the shop. It's okay if the item has an inventory page, but I wouldn't want all of them listed anywhere in the shop itself because users will see tons of items that aren't for sale.

I see. I'm still not 100% sure if I want to add to the complexity of the add-on by introducing another View permission. Your use case is absolutely valid, but I also have to consider normal use cases where not having to work out an extra permissions layer would be preferable.

A compromise would be to create new categories for these items. It wouldn't stop these items from appearing on the main page, but it would stop them from being intermixed with other, purchasable items when viewing your "normal" categories.

Because per-item permissions "bubble down" from per-category permissions, making those categories hidden would unfortunately also hide the items, but I could potentially add a new per-category setting that excludes items from that category from displaying on the overview (front page).

Would that be an acceptable compromise?

 

[Feanor]

I see. I'm still not 100% sure if I want to add to the complexity of the add-on by introducing another View permission. Your use case is absolutely valid, but I also have to consider normal use cases where not having to work out an extra permissions layer would be preferable.

A compromise would be to create new categories for these items. It wouldn't stop these items from appearing on the main page, but it would stop them from being intermixed with other, purchasable items when viewing your "normal" categories.

Because per-item permissions "bubble down" from per-category permissions, making those categories hidden would unfortunately also hide the items, but I could potentially add a new per-category setting that excludes items from that category from displaying on the overview (front page).

Would that be an acceptable compromise?

It would be perfect if that sort of setting was a whole permission in the categories and items.

Because the drawbacks of doing it as a single category setting are: category clutter and one thing we do, which is prepare a list of items before a seasonal event starts. As we prepare, we make it so only admins can view these items in the shop. Then turn it on for everyone once it's ready. But this compromise would be better than nothing and address most of what I was looking for.

 

[DragonByte Tech]

It would be perfect if that sort of setting was a whole permission in the categories and items.

The whole point of it being a setting is so that it's not a permission

category clutter

You could use sub-categories to reduce clutter. If you only use top-level categories, that would make the left side menu very long indeed.

prepare a list of items before a seasonal event starts. As we prepare, we make it so only admins can view these items in the shop. Then turn it on for everyone once it's ready. But this compromise would be better than nothing and address most of what I was looking for.

This wouldn't change that at all, we were talking about items that go off sale after events, not items being prepared before events.

 

[DragonByte Tech]

It would be perfect if that sort of setting was a whole permission in the categories and items.

I feel I should clarify why it has to be a setting and not a permission. When I'm fetching the list of items for the main page, I can deal with settings stored next to other information next to category title, category description, etc.

In code terms, I'd be asking the database for all items belonging to categories that has "show items on the main page" turned on.

If it was a permission, however, it would be impossible to determine that the same way. If I fetch the 20 latest items, and all 20 of them are invisible on the store front, then you're left with a blank store front with no items displayed.

In other words, I can't check for the permission until the data is already fetched from the database.

Hopefully that made some amount of sense.


EDIT: Come to think of it, this might work better as a per-item flag rather than a per-category flag. I'll go with that design for the feature going forward.

 

[Feanor]

EDIT: Come to think of it, this might work better as a per-item flag rather than a per-category flag. I'll go with that design for the feature going forward.

I think that could work. Just to clarify though: would this prevent it from showing up on the main page and the category page? (And what if a category has no items enabled to be shown here- will it not be displayed in the list?)

 

[DragonByte Tech]

would this prevent it from showing up on the main page and the category page?

Yes it would.

And what if a category has no items enabled to be shown here- will it not be displayed in the list?

Empty categories will still display in the sidebar list as they currently do.

 

[DragonByte Tech]

DragonByte Tech updated [DBTech] DragonByte Shop with a new update entry:

6.1.0 Beta 3

Update highlights

Welcome to the third Beta version of DragonByte Shop v6.1.0

Version 6.1.0 represents a complete re-write of the product, making it more deeply integrated with XenForo 2.1, improving performance, and making bugfixes easier.

The Beta label means all missing / planned functionality has now been added, and the system is now ready for more wide-scale testing.

Before we delve into the changes, let's get some things out of the way:

• This...

Read the rest of this update entry...

 

[dehness]

Hey @DragonByte Tech,

The upgrade from 6.0.4 > 6.1.0 seems to just process indefinitely...

 

[DragonByte Tech]

Hey @DragonByte Tech,

The upgrade from 6.0.4 > 6.1.0 seems to just process indefinitely...

If there's still more dots being added then it is working as intended. There's a lot of data changes from 6.0 to 6.1, and for performance reasons they are split into multiple steps (some of which can spawn their own child processes).

 

[dehness]

If there's still more dots being added then it is working as intended. There's a lot of data changes from 6.0 to 6.1, and for performance reasons they are split into multiple steps (some of which can spawn their own child processes).

It's been going for several hours now, while the credits add-on was finished in seconds.

 

[DragonByte Tech]

It's been going for several hours now, while the credits add-on was finished in seconds.

If it's still filling out dots, so that it isn't stalled, then there's some possible causes:

1. Your "Items" table is very large, as it's converting certain columns of items from serialized data to JSON
2. Your "Transaction log" table is very large, same reason
3. Your "Purchase" table is very large
4. Your "Lottery" table is very large
5. Your "Category" table (bearing in mind it's merged shops with categories) is very large
6. Your "Lottery prize" table is very large

 

[dehness]

Your "Transaction log" table is very large, same reason

Yup. This looks to be the culprit. 3.6m entries, mostly related to "interest" payments.

How would I go about checking how much it has done so far? Or should I just cancel it and delete the logs, then start the upgrade again?

At 7 hours later, this is getting a bit much for me to bear:

 

[DragonByte Tech]

How would I go about checking how much it has done so far? Or should I just cancel it and delete the logs, then start the upgrade again?

I wouldn’t cancel it as you can’t be sure whether it will resume correctly. You can try deleting entries while it’s running as it should notice there’s no more entries and move on.

 

[Slayeon]

Hello, when users add youtube urls to profile music it does not work and creates an error