Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • wp-6.8.1
  • renovate/roots-wordpress-6.x
  • theme-link-folio
  • footnotes-made-easy
  • wordpress-full
  • creativecommons
  • debug
  • back-to-hyperdb
  • 23theme-child
  • responsive-twentyten
  • wpgancio
  • logo-login
  • twentytwentytwochild
  • noblogs-5.6.1c
15 results

noblogs-composer

  • Clone with SSH
  • Clone with HTTPS
  • lucha's avatar
    lucha authored
    I have excluded the commits that added/removed entire
    plugins/themes/languages, since we really want to only keep *actural*
    patches to upstream code here.
    14c0ceca
    History

    This is an attempt to re-structure the ai/noblogs-wp> repository using Composer (e.g)

    Some rough ideas on how the situation could be improved:

    • the upstream branch should disappear. We should not have to care ourselves on keeping a sync of Wordpress source code
    • we should really just keep the patches and our contributions
    • we need to be able to build a docker container in the end
    • How do we generate the patches? We need to keep the source code of wordpress in the git repo after all, to be able to use git diff.

    About mu-plugins and drop-in plugins

    Drop-in plugins, such as Hyperdb, do not have to be installed in the plugins directory, but we have instead to place files directly into wp-content. Similarly, mu-plugins are distributed as regular plugins (wpackagist does not have a nice way to select stuff as mu-plugins), but they cannot be dropped in the mu-plugins directory: instead, a single file from their source has to be moved there.

    In order to solve this two problems, we install these plugins outside of the app sub-directory (since we do not need to distribute them in production), and we manually specify which file we need to move where, using dropin-paths.

    Gitlab as Composer registry/repository

    It might happen soon, in Gitlab version 13.1.