Composer access

[irondan]

I've got a site where I'm trying to install the plugin via composer (based on Roots Bedrock). Generally this is pretty straightforward to do from a GitHub repository, which is lovely because that gives me version control on the basis of tagged releases. But in this case there are obstacles, and there seem to be enough that I cannot get around them.

1. Usually you can find WordPress plugins listed in the plugin directory listed as packages on WPackagist. That's the most straightforward way and how I get most plugins. The effort to get this plugin listed on the WordPress Plugin Directory https://github.com/hyperaudio/wordpress-hyperaudio/issues/76 hasn't seen any followup since November 1st, 2023. While this might see some progress, I cannot count on it at present. Bummer.

2. No problem, Composer has by default methods of retrieving packages from VCS, and GitHub specifically. All I have to do is create a definition for the package in the repositories section of my composer.json. Something like:

      "hyperaudio": {
        "type": "package",
        "package": {
          "name": "hyperaudio/wordpress-hyperaudio",
          "version": "1.0.23",
          "type": "wordpress-plugin",
          "source": {
            "url": "https://github.com/hyperaudio/wordpress-hyperaudio",
            "type": "git",
            "reference": "v1.0.23"
          }
        }
      }

Except it doesn't work in this case because the actual plugin is nested inside of the repo's main directory (with a largely duplicated README to boot!). So when composer installs that, WP can't see the plugin in the subdirectory. Bummer.

3. No problem! I think. Composer also can let you use ZIP files as packages, and helpfully the outer README provides a "pre-zipped" version meant for direct installation (though that seems detached from the repo, so I'm not sure how confident I can be about persistent access. Oh well, what can you do?). So I set it up like this in packages:

    "hyperaudio": {
      "type": "package",
      "package": {
        "name": "hyperaudio/wp-hyperaudio",
        "version": "1.0.23",
        "type": "wordpress-plugin",
        "dist": {
          "url": "https://lab.hyperaud.io/wordpress-plugin/v1.0.23/wp-hyperaudio-1.0.23.zip",
          "type": "zip"
        }
      }
    }

Except it doesn't work this time either. Apparently this ZIP file was created on a Mac OSX machine. When composer moves to unzip it instead of condensing into a wp-hyperaudio directory it remains nested, so that the __MACOSX metadata folder can be extracted alongside the contents. Bummer.

I've tried to engage with this plugin using composer in most all the ways I know how. Any one of these issues could be resolved and make this functional. Any chance of any of them being resolved?

[maboa]

Hi @irondan Sorry for the slow reply. I'm not sure why the plugin has not been added to the wp directory, I have received no word from them since I submitted. If the zipped version doesn't work for you, can you create your own zip file with the same contents?

[irondan]

Hello @maboa , thank you for taking a look!

Right now my workaround is to copy the plugin files and put them in place on the site repo, then force commit them into the site's git repo with some .gitignore lines like

web/app/plugins/*
!web/app/plugins/wp-hyperaudio

Totally functional, but obviously not ideal keeping someone else's code in the site repo as if it were a custom plugin.

Ultimately what I'd like to see is maybe a couple changes to this repo to improve it's usability:

• Move the plugin files into the main repo directory. Taking a cue from one of the most popular WP plugins Contact Form 7 you can see that they throw everything in that main directory, even the .github folder and both README.md and readme.txt. Doing this would solve the ZIP issue completely, as then you can pull tagged ZIPs from GitHub.
  • Even if you don't want to do that, the LICENSE file should be renamed to include an extension like license.txt and it should travel in the plugin's folder. Keeping the license with the codebase is a good rule of thumb, but as it stands this license never ends up in the compressed or installed version of the plugin.
• Pick your plugin name and make it consistent. Folks may not think this is a big deal, but if I'm troubleshooting something called "Hyperaudio for Wordpress" in the plugins list and I need to find the folder amongst 100 plugins I'm not immediately going to look for or find "wp-hyperaudio". This isn't strictly necessary, more of something to do to prevent confusion later. Here's all the different "names" this plugin is going by:
  • The repository is called hyperaudio/wordpress-hyperaudio; the latter part would end up the folder name if you installed it in WP from the repo.
  • The folder that contains the plugin in the repo is wp-hyperaudio
  • README.md refers to the plugin as Hyperaudio for Wordpress
  • The main plugin file is known as hyperaudio.php (this should match the folder name IMO)
  • readme.txt similarly lists Hyperaudio as the name of the plugin in the first line
  • The Plugin Name in the main plugin file and therefore as it appears in the Plugin Listing is Hyperaudio Interactive Transcript
• Technically not the repo, but if you're going to continue to create pre-zipped versions of the plugin to install I would do it from the terminal. Doing it that way should avoid adding the __MACOSX folder that can be added, and you can also address other files like .DS_Store as well. Take a look at this Apple Stack Exchange answer for more information.

If you'd like @maboa you can assign this issue to me and I can prepare a Pull Request that tries to clean some of this up. Let me know if you'd be interested in that.

[maboa]

It all sounds sensible to me and sounds like you know a lot more about this than me @irondan, so feel free to create a PR for this – thank you!! Just a heads up that I'm currently making a couple of modifications to the plugin addressing #152 and #153. They should be complete this week.