Recent Activities

This page shows what are we working on.

swissup / module-argento-hyva

2 weeks ago success

breezefront / module-breeze-magewire-example

2 weeks ago success

breezefront / module-breeze-magewire

2 weeks ago success

swissup / floriteshop-chic-custom

2 weeks ago error

swissup / module-navigationpro

3 weeks ago success
  • head
    • Do not build the tree in prepareLayout 52e1ba

  • 1.19.3
    • Version 1.19.3 421267

    • Do not use `is_active` from remote entity when creating new item
      Since we have new option `use_remote_include_in_menu`, use it instead
      of syncing `is_active` on item creation. 7c215a

    • Fixed not working ribbon for vertical menu 8fdb50

    • LESS 5.3.0 compatibility 922d05

swissup / module-search-mysql-legacy

3 weeks ago success
  • head
    • docs: correct the consequences of patching the version list (#27)

      The previous wording blamed getMariaDbSuffixKey(). That was wrong: every
      MariaDB branch there except 10.4 already returns the 10.6.11 key, so an
      unmatched version falling back to the same default is harmless.

      The actual damage from adding a pattern is elsewhere. getSqlVersion()
      returns the matched prefix, and two consumers key off it with entries for
      10.4./10.6./11.4. only: Dto\Factories\Table falls through to the 'default'
      charset, so declarative schema starts creating utf8mb3/utf8_general_ci
      tables alongside the existing utf8mb4 ones, and
      DbSchemaWriter::isNeedToSplitSql() returns false, dropping the ALTER
      splitting MariaDB relies on.

      Also state that the check lives entirely in Setup\Declaration\Schema, so
      it cannot break storefront rendering — broken pages after the abort come
      from the half-applied upgrade — and add a collation query for stores that
      already applied the patch.

      Co-authored-by: Claude Opus 5 <noreply@anthropic.com> b03bee

    • docs: correct the consequences of patching the version list

      The previous wording blamed getMariaDbSuffixKey(). That was wrong: every
      MariaDB branch there except 10.4 already returns the 10.6.11 key, so an
      unmatched version falling back to the same default is harmless.

      The actual damage from adding a pattern is elsewhere. getSqlVersion()
      returns the matched prefix, and two consumers key off it with entries for
      10.4./10.6./11.4. only: Dto\Factories\Table falls through to the 'default'
      charset, so declarative schema starts creating utf8mb3/utf8_general_ci
      tables alongside the existing utf8mb4 ones, and
      DbSchemaWriter::isNeedToSplitSql() returns false, dropping the ALTER
      splitting MariaDB relies on.

      Also state that the check lives entirely in Setup\Declaration\Schema, so
      it cannot break storefront rendering — broken pages after the abort come
      from the half-applied upgrade — and add a collation query for stores that
      already applied the patch.

      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> af98dc

    • docs: document supported DB versions and the MariaDB 10.11 gap (#26)

      Magento 2.4.8's SqlVersionProvider accepts only MySQL 5.7/8.0/8.4 and
      MariaDB 10.2-10.6/11.4, so a hosting-side upgrade from MariaDB 10.6 to
      10.11 aborts setup:upgrade with "Current version of RDBMS is not
      supported" while the storefront keeps running. That reaches us as an
      extension-compatibility report, because this module is popular exactly
      on hostings with older, hosting-managed stacks.

      Add a F.A.Q. entry with the accepted version list, state that the module
      imposes no database requirement of its own, and warn against patching
      di.xml as a workaround (getMariaDbSuffixKey() has no branch for those
      releases and falls back to its 10.6 profile, so declarative schema emits
      DDL against the wrong engine profile).

      Co-authored-by: Claude Opus 5 <noreply@anthropic.com> 52f8c3

    • docs: document supported DB versions and the MariaDB 10.11 gap

      Magento 2.4.8's SqlVersionProvider accepts only MySQL 5.7/8.0/8.4 and
      MariaDB 10.2-10.6/11.4, so a hosting-side upgrade from MariaDB 10.6 to
      10.11 aborts setup:upgrade with "Current version of RDBMS is not
      supported" while the storefront keeps running. That reaches us as an
      extension-compatibility report, because this module is popular exactly
      on hostings with older, hosting-managed stacks.

      Add a F.A.Q. entry with the accepted version list, state that the module
      imposes no database requirement of its own, and warn against patching
      di.xml as a workaround (getMariaDbSuffixKey() has no branch for those
      releases and falls back to its 10.6 profile, so declarative schema emits
      DDL against the wrong engine profile).

      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 32e9ef

breezefront / theme-frontend-breeze-enterprise-blank

3 weeks ago success

breezefront / breeze-content-builder

3 weeks ago success

swissup / module-marketplace

3 weeks ago success
  • 1.12.0
    • Version 1.12.0 346881

    • Typo fix 50a7b6

    • Cleanup CSS ea255a

    • Fix grid styles 4d48e9

    • Stop running composer from the backend (#17)

      Running composer through the web server is not reliable, so the backend no
      longer dispatches composer operations. Install, Update, Remove, Enable and
      Disable now open a modal with the command to copy and run in a terminal, both
      for a single row and for a massaction. Run Installer stays a real backend
      operation - the one-click installer does not use composer.

      Enable and Disable had no console equivalent, so marketplace:package:enable and
      marketplace:package:disable were added (aliases marketplace:enable and
      marketplace:disable).

      Channel configuration and Tasks History are removed from the backend as well.
      Channels are managed with the marketplace:channel:* and marketplace:auth:*
      commands. With the settings form gone, ChannelsSave was the last job producer,
      so the whole queue is removed: JobDispatcher, QueueDispatcher, Validator, the
      Job entity, the activity widget, the queue crons and the job table.

      The SettingsDataProvider modifiers are kept as empty stubs so that the channel
      modules registering them in the pool keep compiling.

      BREAKING: the swissup_marketplace_job table is dropped on setup:upgrade, and
      HandlerInterface::validateBeforeDispatch() is removed - it had no callers left.

      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> cccd99

    • Ignore the packages with an invalid name

      The channel metadata is not validated, and the package name ends up in
      the command we suggest to copy and run. A name containing ;, $() or a
      whitespace turns that command into something else.

      Filtered where the channel data is read, so that such a package never
      reaches the grid, the suggested command, or the installer request. The
      pattern is the one composer validates the names with, so nothing that
      composer is able to install is dropped.

      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 956e42

    • Improve package disable/enable operations cc8491

    • Address review comments

      - Massaction: require the row to expose the action before offering a
      command. Local.php marks every downloaded package as enabled and only
      overrides it for the modules, so a downloaded theme passed the shared
      disable check even though Links.php never adds Enable/Disable to a
      non-module row - marketplace:disable would then write a derived, bogus
      module name to config.php.
      - Copy button: writeText() is asynchronous and rejects when the clipboard
      is blocked. Copy now returns a deferred, falls back to execCommand on
      rejection, and the Copied label is shown only once a copy succeeded.
      - README grammar.

      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> f2fdaf

    • Stop running composer from the backend

      Running composer through the web server was never reliable, so the backend no
      longer dispatches composer operations. Install, Update, Remove, Enable and
      Disable now open a modal with the command to copy and run in a terminal, both
      for a single row and for a massaction. Run Installer stays a real backend
      operation - the one-click installer does not use composer.

      Enable and Disable had no console equivalent, so marketplace:package:enable and
      marketplace:package:disable were added (aliases marketplace:enable and
      marketplace:disable).

      Channel configuration and Tasks History are removed from the backend as well.
      Channels are managed with the marketplace:channel:* and marketplace:auth:*
      commands. With the settings form gone, ChannelsSave was the last job producer,
      so the whole queue is removed: JobDispatcher, QueueDispatcher, Validator, the
      Job entity, the activity widget, the queue crons and the job table.

      The SettingsDataProvider modifiers are kept as empty stubs so that the channel
      modules registering them in the pool keep compiling.

      BREAKING: the swissup_marketplace_job table is dropped on setup:upgrade, and
      HandlerInterface::validateBeforeDispatch() is removed - it had no callers left.

      Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> d70a96

    • Forward command output strings to terminal c17318

    • Allow using dry-run option 2d329d

    • Reuse composer_cache from user's directory if possible 9cc10a

    • Command shortcuts 2cfa4c

  • 1.11.0
    • Version 1.11.0 e5e9b8

    • Fixed PHP stan return type errors 49ac60

    • Allow to run installer for themes missing in composer.lock 7bb9ca

breezefront / breeze-blank

3 weeks ago success