Glad this module exist.

I want to install https://www.drupal.org/project/swiftmailer module.

It seems I put everything right, but Ludwig still says swiftmailer library is missing.

Looking to the code http://cgit.drupalcode.org/ludwig/commit/?id=50ad5b3, it seems no such loading is not supported yet?

In composer.json from https://github.com/swiftmailer/swiftmailer/archive/v5.4.8.tar.gz :

    "autoload": {
        "files": ["lib/swift_required.php"]
    },

Can Ludwig support these libraries that so difficult in to install at the moment?

CommentFileSizeAuthor
#22 2914840-22.patch825 bytesdevad
#20 2914840-20.patch3.73 KBdevad
#17 2914840-17.patch2.01 KBdevad
#15 libraries-all-01.jpg466 KBdevad

Comments

mindaugasd created an issue. See original summary.

devad’s picture

devad commented
Related issues: +#2920496: Swift Mailer - Add Ludwig integration

Linking to related issue from Swiftmailer module.

devad’s picture

devad commented
Priority: Normal » Major

Swiftmailer module is currently the only Drupal "HTML mail oriented" module which has significant D8 release (beta).

Drupal commerce needs such a module to send receipts to customers.

Bumping this issue to Major to inspire more community members to participate.

For all of us who are using Drupal Commerce + Ludwig this issue is definitely major.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
Priority: Major » Normal
Status: Active » Closed (won't fix)

Open an issue and ask them to add a ludwig.json

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
Title: Support more libraries / loading types » Support audoload.file
Status: Closed (won't fix) » Active

Read the parent issue, sorry. Looks like we'd need to support audoload.file

devad’s picture

devad commented
Title: Support audoload.file » Support autoload.file
mindaugasd’s picture

mindaugasd commented
Title: Support autoload.file » Support more libraries / loading types
Related issues: +#3040695: Entity Print - Add Ludwig integration

Changing title to my original one :)

For example, dompdf library autoload code (below), whatever this "classmap" really means - it looks like Ludwig at the moment does not support this neither.

"autoload": {
        "psr-4" : {
            "Dompdf\\" : "src/"
        },
        "classmap" : ["lib/"]
    },

Connecting this to related issue https://www.drupal.org/project/entity_print/issues/3040695
I temporary solved it by manually including additional classes with require_once and it started working.

hockey2112’s picture

hockey2112 commented

@mindaugasd could you please provide a full explanation/code dump of how you got it to work? Thanks!

mindaugasd’s picture

mindaugasd commented

@hockey2112 In swiftmailer I added this line to the front of swiftmailer.module and swiftmailer.install.

  require_once('lib/swiftmailer/swift_required.php');

and created ludwig.json file

{
  "require": {
    "html2text/html2text": {
      "version" : "4.0.1",
      "url": "https://github.com/mtibben/html2text/archive/4.0.1.zip"
    }
  }
}

In entity_print I added this line to entity_print.module 

  require_once('lib/dompdf-dompdf/v0.8.3/autoload.inc.php');

and created ludwig.json file.

{
  "require": {
    "dompdf/dompdf": {
      "version" : "v0.8.3",
      "url": "https://github.com/dompdf/dompdf/releases/download/v0.8.0/dompdf_0-8-3.zip"
    }
  }
}
hockey2112’s picture

hockey2112 commented

mindausasd,

Thanks for that explanation, extremely helpful!

I assume you placed the swiftmailer and html2txt library files in modules/swiftmailer/lib/... is that correct?

mindaugasd’s picture

mindaugasd commented

Yes, it is correct.

devad’s picture

devad commented

Here is a new child issue which among other things is adding more support to PSR-4 and PSR-0 libraries: #3177450: Add warnings about unsupported autoload types and improve PSR types support

devad’s picture

devad commented

A nice basis are established in #3177450: Add warnings about unsupported autoload types and improve PSR types support to support 'classmap' and 'files' autoload types as well.

If someone knows how to add to drupal container new classmap and/or files paths such help would be much appreciated.

devad’s picture

devad commented

Here it is what composer is doing inside it's composer/autoload_static.php file:

public static $classMap = array (
        'Drupal' => __DIR__ . '/../..' . '/core/lib/Drupal.php',
        'Drupal\\Component\\DependencyInjection\\Container' => __DIR__ . '/../..' . '/core/lib/Drupal/Component/DependencyInjection/Container.php',
...
...
        'ValueError' => __DIR__ . '/..' . '/symfony/polyfill-php80/Resources/stubs/ValueError.php',
        'geoPHP' => __DIR__ . '/..' . '/phayes/geophp/geoPHP.inc',
    );

Can we do something similar? Sorry I am not friendly with namespaces etc. :)

devad’s picture

devad commented
Title: Support more libraries / loading types » Support 'classmap' and 'files' autoload types
StatusFileSize
new libraries-all-01.jpg466 KB

With #3177450: Add warnings about unsupported autoload types and improve PSR types support committed and new ver. 8.x-1.1 released today, all PSR-4 and PSR-0 libraries are supported in full now.

1. Previous problem with multiple-path libraries (such as html2text/html2text) is solved by iterating through all paths and adding them as individual namespace records.

2. Previous problem with multiple-resource libraries (such as brightcove/apiand maxmind/web-service-common) is solved as well by iterating through all resources and adding them as individual namespace records.

3. All 'Classmap' and 'Files' libraries are giving proper warnings now that Ludwig is not supporting these autoload types yet.

Here are some of them:

Classmap autoload type

  • dompdf/dompdf ('lib' part only)
  • phayes/geophp
  • aodto/phasher

Files autoload type

  • brynj-digital/social-feed
  • swiftmailer/swiftmailer

Ludwig is not reporting these libraries as 'missing' any more (even after they are properly downloaded and unpacked). It is properly reporting them as installed but 'unsupported' now by adding a bold warning inside library's description.

Screenshot is attached with all said above visible inside the new Reports / Packages page.

@TODO

All "Classmap" and "Files" data are parsed properly now by src/PackageManager.php and are available to src/LudwigServiceProvider.php. We just need some coding expert to use these data properly and fill currently empty # @todo: Add Classmap and Files autoload types support section inside new src/LudwigServiceProvider.php with proper coding. If you know somebody... please ping him/her here. :)

P.S. Renaming the title of this issue to reflect the remaining need.

devad’s picture

devad commented
Title: Support 'classmap' and 'files' autoload types » Add support for 'classmap' and 'files' autoload types
devad’s picture

devad commented
Status: Active » Needs review
Related issues: +#3182058: FeedsEP - Ludwig integration improvement
StatusFileSize
new 2914840-17.patch2.01 KB

The automatic support for 'classmap' and 'files' autoload types is not easy to implement due to the lack of such support inside Drupal and Symphony. Both Drupal and Symphony are relying fully on Composer in this regard.

One thing we can add is a Ludwig service which can be used as a helper service by contributed modules to manually require files needed by 'classmap' and 'files' autoload libraries.

Patch attached.

Please, see "Related issues" for new service usage examples.

  • devad committed ce6a196 on 8.x-1.x 
    Issue #2914840 by devad, mindaugasd: Add support for 'classmap' and '...
devad’s picture

devad commented
Status: Needs review » Fixed

Committed.

If somebody will figure out in the future how we can add support for 'classmap' and 'files' library types more directly - without the need from contrib modules to use new ludwig.require_once service inside their .module and/or .install files - please feel free to reopen this issue or create a new one.

devad’s picture

devad commented
Status: Fixed » Needs review
StatusFileSize
new 2914840-20.patch3.73 KB

Digging the caller module directory name with debug_backtrace() might not have been the best idea.

I have noticed some issues with new Ludwig service when more than one contrib modules managed with Ludwig have dependencies on 'classmap' and/or 'files' library types.

1. So, let's make it simple and require the directory name from caller module as a third argument for our requireOnce() function.

2. And let's remove "Ludwig" from the beginning of the class name and method name and from the beginning of the file name - since it is not a best coding practice as suggested by @bojanz here.

3. And let's throw some exceptions if something is not structured well regarding ludwig.json file or service calls at caller module's side.

All together... quite a big patch.

  • devad committed 66cc62e on 8.x-1.x 
    Issue #2914840 by devad: Add support for classmap and files autoload...
devad’s picture

devad commented
Related issues: +#3119331: Geofield - Add Ludwig integration, +#3195238: Geocoder - Add Ludwig Integration
StatusFileSize
new 2914840-22.patch825 bytes

Throwing an exception if the file is not found is a bit extreme and can lead to problems with site availability.

Lets log an error here instead of throwing the exception.

  • devad committed 6addd66 on 8.x-1.x 
    Issue #2914840 by devad: Add support for classmap and files autoload...
devad’s picture

devad commented
Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.