[22.11] nixos/wordpress: component directories should match name #210689
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
urandom2
changed the title
13 tasks
In an effort to better encode version strings and use descriptive pnames
that do not conflict with top level pkgs, we currently use
wordpress-${type}-${pname} for pname. This is good for the nix store,
but when we synthesize the wordpress derivation in our module, we reuse
this pname for the output directory.
Internally wordpress can handle this fine, since plugins must register
via php, not directory. Unfortunately, many plugins like civicrm and
wpforms-lite are designed to rely upon the name of their install
directory for homing or discovery.
As such, we should follow both the upstream convention and
services.nextcloud.extraApps and use an attribute set for these options.
This allows us to not have to deal with the implementation details of
plugins and themes, which differ from official and third party, but also
give users the option to override the install location. The only issue
is that it breaks the current api.
(cherry picked from commit 66e0e5a)
Unfortunately, we cannot always make backwards compatible changes, so
instead we can consume wpName from official components, and fallback to
the current behaviour if that field is missing, currently just third
party components.
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review/3032/1770 |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review/3032/1816 |
|
Unfortunately NixOS 22.11 has reached its end-of-life status on 2023-06-30, one month after the release of NixOS 23.05. I'm closing this pull request, since we do not accept any changes to its branches anymore. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of changes
In an effort to better encode version strings and use descriptive pnames that do not conflict with top level pkgs, we currently use wordpress-${type}-${pname} for pname. This is good for the nix store, but when we synthesize the wordpress derivation in our module, we reuse this pname for the output directory.
Internally wordpress can handle this fine, since plugins must register via php, not directory. Unfortunately, many plugins like civicrm and wpforms-lite are designed to rely upon the name of their install directory for homing or discovery.
As such, we should follow both the upstream convention and services.nextcloud.extraApps and use an attribute set for these options. This allows us to not have to deal with the implementation details of plugins and themes, which differ from official and third party, but also give users the option to override the install location. The only issue is that it breaks the current api.
(cherry picked from #210686)
Unfortunately, we cannot always make backwards compatible changes, so instead we can consume wpName from official components, and fallback to the current behaviour if that field is missing, currently just third party components.
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)nixos/doc/manual/md-to-db.shto update generated release notes