v2.28.0

Details

  • Filename
    Shopkeepers-2.28.0.jar
  • Uploaded by
  • Uploaded
    Sep 19, 2026
  • Size
    2.38 MB
  • Downloads
    87
  • MD5
    0da70795dc51dc3fbd634ad97bc15a8a

Supported Bukkit Versions

  • 26.3
  • 26.2
  • 26.1.2
  • 1.21.11
  • 1.21.10
  • 1.21.8
  • 1.21.7
  • 1.21.6
  • 1.21.5

Changelog

v2.28.0 for MC 26.3, 26.2, 26.1.2, 1.21.11, 1.21.10, 1.21.8, 1.21.7, 1.21.6, 1.21.5

I only list the primary changes here. For information on API changes, internal changes, and changes to the language files, you can find the complete changelog on Github: https://github.com/Shopkeepers/Shopkeepers/blob/master/CHANGELOG.md

  • Update for MC 26.3.
    • Add poplar sign and hanging sign shops.
  • Add support for multiple shop containers: Shop owners can now link additional containers to their player shops.
    • Config:
      • Add max-containers-per-player-shop (default: 9). Set it to 1 to keep the previous single-container behavior.
      • Add add-container-item (default: minecraft:lime_stained_glass_pane) for the add-container button.
      • Config migration 12: Rename enable-container-option-on-player-shop to enable-player-shop-open-container. It only controls now whether players can remotely open a container's inventory from the shop editor. The container information itself is always shown.
    • Editor: If max-containers-per-player-shop is greater than 1, the container button inside the editor allows shop owners to view and edit the linked shop containers.
      • Click the green glass pane item and then a nearby container to add it as an additional shop container. The usual checks apply (supported container, not already used by another shop, within max-container-distance, etc.).
      • Left/Right-click a container to cycle through the different container types.
      • If enabled, shift-right-click a container to remotely open it and inspect its content.
      • Shift-left-click a container to remove it after additional confirmation.
    • Available container types:
      • Stock: The shop retrieves trade result items from this container. Trades show as "out-of-stock" if the required result items cannot be found across the stock containers.
      • Earnings: The shop stores received items in this container. The shop prefers to store items in earnings containers that already contain the respective item.
      • Stock and Earnings: The container stores both stock and earnings (default).
    • If max-containers-per-player-shop is 1, the container editor button behaves similar to before, but includes some additional information now. The single container (and any other previously added containers) automatically act as Stock and Earnings.
    • The container information includes the coordinates, whether the container is a double chest, whether it is missing (i.e. no longer exists in the world), and, if support for multiple containers is enabled, its container type.
    • delete-shopkeeper-on-break-container only takes effect when the last shop container is broken. Broken containers remain in the shop's list of containers and show as "missing".
    • When moving a player shopkeeper, all of its containers must remain within the configured max-container-distance.
  • Add player shop expiration: Player shops can now be configured to expire after a certain duration.
    • Config:
      • Add setting player-shop-expiration-days (default: 0, disabled): If greater than 0, fully owned player shops (i.e. those that were not hired) expire and get deleted this many days after their current owner acquired them (i.e. after creation or transfer).
      • Add setting hired-player-shop-expiration-days (default: 0, disabled): If greater than 0, hired player shops expire and revert back to their for-hire state this many days after they were hired.
        • Note: Since we previously did not remember the previous hiring cost item once a shop was hired, this only applies to shopkeepers that are set for hire after this update. Existing previously hired player shops behave like fully owned player shops.
        • Expiration has no effect on shops that are currently already waiting to be hired.
        • Hiring a shop resets its expiration, even if it is hired again by its current owner, e.g. after it expired and reverted back to its for-hire state.
      • Add setting notify-shop-members-about-expiration (default: true): Controls whether shop owners and members are notified when their shops are about to expire.
        • If enabled, we notify players roughly 7 days, 3 days, 1 day, 12 hours, 1 hour and 10 minutes before their shop expires (configurable via player-shop-expiration-notification-thresholds), so they have a chance to clear their shop containers in time.
        • We remember when we last notified each player, so we avoid notifying again for the same shop and notification threshold.
        • Regardless of this setting, we always inform players about the expiration duration when they create or acquire a shop, and when a shop just expired and they happen to be online currently. However, we do not notify about shops that expired while they were offline.
      • Add setting player-shop-expiration-notification-thresholds (default: 10080,4320,1440,720,60,10): A comma-separated list of the notification thresholds in minutes before expiration at which shop members are reminded.
        • The default corresponds to 7 days, 3 days, 1 day, 12 hours, 1 hour, and 10 minutes before expiration.
        • Note: The expiration duration and notification thresholds are only rough estimates. For performance reasons, the plugin only checks for expirations and pending notifications every few minutes. Thresholds below this check interval may therefore not be reached before the shop expires.
    • Expiration is checked roughly every 5 minutes, starting 5 minutes after plugin startup.
      • Deleting an expired shop automatically unlocks its containers.
      • All expirations are logged to the server log.
    • Command: The /shopkeeper list output indicates when player shops will expire.
    • Command: Add /shopkeeper expiration [player] (alias /shopkeeper expiry) to manually list up to the next 8 shops of a player that are about to expire.
      • Permission: Without the optional player argument, this lists your own expiring shops (permission shopkeeper.expiration.own, default: true).
      • Permission: The player can be specified by name or uuid, which also accounts for offline shop members (permission shopkeeper.expiration.others, default: op).
      • This command can also be used from the console, in which case the player argument is required.
      • Note: Since the expiration duration is only an estimate, some of the listed shops may already have reached their expiration time, but not have been expired yet.
    • Metrics: Add bStats metrics player-shop-expiration-days and hired-player-shop-expiration-days.
  • Changes to the hiring of player shops:
    • Previously, hiring a shopkeeper fully transferred the ownership, including the ability of the new owner to delete the shopkeeper. Admins trying to use this feature to manage a controlled market area on their server had to manually monitor for stale market booths and set up new hireable shopkeepers over time. Now, owners of hired shopkeepers are more restricted in what they can do. And in combination with the new shop expiration feature (see setting hired-player-shop-expiration-days), it is now possible to set up temporarily hired shops that automatically revert back to their for-hire state once they expire.
    • Change: Hired player shops can no longer be deleted by their shop members. Instead, the "delete" button in the editor reverts the shop to the for-hire state.
      • This also applies to admins, so that they do not unknowingly observe a behavior that differs from what other players get, and to also allow them to revert the shop to the for-hire state via the editor. Players with the shopkeeper.setforhire permission additionally receive a hint that they can use the new /shopkeeper setNotForHire command first in order to then fully delete the shop afterwards.
    • Command: /shopkeeper remove and /shopkeeper removeAll only deletes hired shopkeepers if the command executor has the shopkeeper.bypass permission.
    • Change: Members of a hired player shop can access the shop containers, but are otherwise affected by the same restrictions as other players. I.e. they cannot break or build near the containers of the hired shop. Players with the shopkeeper.bypass permission are exempt from these restrictions, as before.
    • Change: Hired player shops can no longer be moved via the editor, except by players with the shopkeeper.setforhire permission.
    • Change: The containers of hired player shops can no longer be added or removed via the editor, except by players with the shopkeeper.setforhire permission.
    • Change: Hiring a player shop clears its previous trade offers, unless the current owner re-hires the shop.
    • Change: Shops that are currently for hire no longer count towards the max-shops-per-player limit (and the shopkeeper.maxshops.<count> permissions) of the current/previous owner. Without this change, players would not be able to re-hire their expired shopkeepers, or create or hire other shopkeepers after their previously hired shopkeeper(s) expired.
    • Manual migration: Setting shops for hire requires the shopkeeper.setforhire permission, which is only granted to admins by default. If you assigned this permission to normal players in the past, it is recommended that you remove this permission from them again, because with these for-hire shops no longer counting towards the per-player shop limit, players with this permission can now create an unlimited number of shopkeepers on the server.
    • Command: Add command /shopkeeper setNotForHire (permission shopkeeper.setforhire, same as for the setForHire command) to stop offering one of your shops for hire again and clearing its previously set hire cost item.
    • Fix: Shops that are currently for hire can also no longer be traded with when the UI is attempted to be opened remotely via command or via the API.
    • Fix: Automatically close any currently open hiring UIs when a shop stops being for hire or its hiring cost item changes. Players were already not able to hire these shops via the stale hiring UI before, but now we immediately close the stale UIs.
    • Change: player-shopkeeper-inactive-days restores hired shops of inactive players to their for-hire state instead of deleting them.
  • Change: Inform players when the container protection prevents them from interacting with a shop container, breaking it, or placing a block next to it.
  • Config: Add enable-left-click-interaction (default: false): If enabled, left clicking (attacking) a shopkeeper mob is handled like a normal mob interaction, i.e. it opens the trading or editor menu.
    • While not officially supported, this may for example be useful for Bedrock players in combination with the Geyser plugin: On Bedrock, not all mobs can be interacted with.
    • This has no effect on block based shop objects such as sign shopkeepers.
    • Metrics: Add the bStats metrics entry enable-left-click-interaction.
  • Config: Add max-player-shop-trades-pages (default: 5) to configure the number of trades pages of player shops separately.
    • The previous max-trades-pages setting now only applies to admin shops and the villager editor.
    • Manual migration: If you previously changed the max-trades-pages setting, you will need to manually adjust the new max-player-shop-trades-pages setting accordingly.
  • Fix: A player shop's members are cleared now whenever its owner changes, for example via /shopkeeper transfer or when another player hires the shop. Member access granted by the previous owner is not meant to carry over. If the current owner re-hires a shop, the previous members are preserved.
    • Fix: This also resolves that transferring or hiring a shop to one of its own members previously left that player listed as both the owner and a member, which made the shop fail to load.
  • Command: /shopkeeper transfer informs the new owner about the received shop now, if they are online.
  • Command: /shopkeeper transfer automatically resets the for-hire state of the transferred shop, but preserves the hire cost item, as if the new owner had just hired the shop.
  • Fix: When a Citizen NPC player shopkeeper is moved to a different world, the shop containers keep working.
    • Shop containers can technically be located in different worlds now.
    • However, we still prevent players from manually moving their shops to a different world (via the max container distance check), because this can affect the performance.
    • Also, if the delete-shopkeeper-on-break-container is enabled, shopkeepers may still get deleted if the world containing their containers is not loaded currently: We cannot differentiate between worlds being gone for good or only temporarily not available.
  • Fix: Trying to create a player shopkeeper in a world different to the world of the selected container resulted in an unhandled exception rather than the intended container distance error message.
  • Fix: Shopkeepers are stored more promptly to storage now when they are deleted because their containers got destroyed. We previously marked the storage "dirty", but did not actually trigger a delayed save.
  • Fix: Non-flying shopkeeper mobs could not be placed on top of reduced-height blocks such as chests, incorrectly reporting the location as midair.
  • Localization: Various messages support hex colors with the &# format now.

Known potential issues: See here.

Donations

If you like this plugin, consider making a donation.

Thanks!