Unable to use third party library in new plugin

Support Plugins
1

A search in this forum and on the web shows there are several ways to use third party code in a plugin. There seems to be no “that’s the way to do it” and though in theory it is simple in practice it’s not very straightforward. Not for me anyway.

So in theory these are the steps to use a third party library in a plugin:

  1. in the command line go to the root of your plugin
  2. let composer install the desired library
  3. add the library to the plugin by using the use keyword
  4. use the new keyword to create an object from the third party class

Using Grav version 1.7.41.1 I created a new plugin by following the instructions in Step 2 - Create Randomizer plugin

Then from within the new plugin’s root dir I did composer require josantonius/language-code followed by a composer update (not sure whether the second command is needed).

The library is added in the vendor directory and all is well up to this point.

In the main (and only) plugin PHP file I Include the third party library by adding use Josantonius\LanguageCode\LanguageCode;

Finally as a test I try to use the third party code like this:

public function onPluginsInitialized(): void
{
    // Don't proceed if we are in the admin plugin
    if ($this->isAdmin()) {
        return;
    }

    $languageCode = new LanguageCode();

    dump($languageCode->getName('en'));

    // Enable the main events we are interested in
    $this->enable([
        // Put your main events here
    ]);
}

VSC indicates a problem by underlining “LanguageCode” in red and reports: “Undefined type ‘Josantonius\LanguageCode\LanguageCode’”.

What am I missing here?

2

@bleutzinn, I tried your steps, but got some unexpected issue with the library. I’m confused you didn’t mentioned that and are able to use the latest version of the library.

Apart from that, I cannot reproduce your issue.

NB. I’m using WSL on Windows, running Ubuntu 22.04 LTS with PHP 8.2.1

  • $ bin/plugin devtools new-plugin
    I chose ‘blank’ as plugin template

  • $ cd user/plugins/myplugin

  • $ composer update

  • $ composer require josantonius/language-code

  • Open vscode from within root of site:

    • $ cd ../../..
    • $ code .
      When vscode is opened from within root of plugin, Intelephense will not be able to find Grav classes by default.

  • Add use Josantonius\LanguageCode\LanguageCode; on line 6

  • Add the following on line 55

    $languageCode = new LanguageCode();
$languageCode->getName('en');

  • I get a red squiggly below getName('en).

    Did you not get that?

    Apparently, an old version of LanguageCode has been installed, due to the following config in composer.json

    "config": {
  "platform": {
    "php": "7.1.3"
  }
}

    See composer docs: Composer config.platform:

  • After removing the entire config setting and running $ composer require josantonius/language-code again, the latest version got installed.

  • In vscode the red squiggly was still there, because Intelephense needs to index the workspace again before it recognises the new version of the library.
    In vscode run command Intelephense: Index workspace

  • All is well: squigglies are gone and languageCode->getName('en); returns the correct name.

3

Thanks for investigating this.

I didn’t mention the version issue with the josantonius/language-code library because I didn’t notice the difference in version (installed 1.1 and latest release 2.0). Apparently another library I tried ‘suffers’ from the same issue.

This is what the require section in composer.json looks (or rather looked):

  "require": {
    "php": ">=7.1.3",
    "josantonius/language-code": "^1.1"
  },

It took me a while to figure things out based on your answer. I don’t often go into the VSC Command Palette but a Intelephense: Index workspace there did indeed help in removing the red squiggly underline at the class name but appeared at the method. Like you mentioned.

Working on Windows with Xampp here and running PHP 8.1.10. So I changed the config section in the composer.json file to:

"config": {
  "platform": {
    "php": "8.1"
  }
}

Then I uninstalled the 1.1 version of the library (composer remove josantonius/language-code) and did another install (composer require josantonius/language-code).
After that the require section shows:

"require": {
    "php": ">=7.1.3",
    "josantonius/language-code": "^2.0"
  },

And, again as you described, all is well.

Thanks for helping me out on this. It really isn’t complicated but there are some things to watch out for mainly checking the PHP version being used.

4

@bleutzinn , I’ve created an issue at the repo of DevTools

5

Good point, thanks.

Just for my understanding (sorry), if I understand correctly the composer config.platform.php setting sets an upperbound on library versions. But actually a minimum version level is appropriate or even required. Am I correct?

6

@bleutzinn, I’ve only encountered config.platform.php during this post for the first time. So I have no prior knowledge either…

Yes, it seems it sets an upper bound for PHP.

A reason for this setting I can think of is that a local dev machine will probably have a more recent PHP version, or can more easily be upgraded to a more recent PHP version, than a production machine. This way, you can mimic and test a production environment on the dev machine.

Just guessing though…

7

An educated guess I would say. That’s what the composer documentation (the link you mentioned) is about.

Such a setting may be handy but it should not be in the config of the DevTools Plugin by default.

8

I would suggest that you turn the GitHub-issue into a Pull Request to remove the platform configuration, @pamtbaau. The platform-config is often paired with the required PHP-version, but as you’ve both experienced, it also unnecessarily constrains the installation of dependencies.

9

A pull request is waiting to be merged.

Thank you all for your help on this matter.

1 Like
10

Today the PR was merged so the platform-config is no longer part of the default config of the DevTools Plugin.

Thanks to @pamtbaau and @OleVik on this.