⚑️ Live updates comments, jobs, and issues, tagged with #h5p will update issues and activities on this page.

Issues

The last 100 updated issues.

Activities

The last 7 days of comments and CI jobs.

  • πŸ‡ͺπŸ‡ͺEstonia pjotr.savitski

    @abhinavk Using legacy/deprecated aggregator class was a quick and rather low effort solution to library code not working with the new aggregator class. I don't remember the inner details as I last looked at it more or less a year or so ago, but the methods aggregatedAssets and createCachedPublicFiles are the ones that are causing the issues.

    H5P is not using libraries as Drupal generally does, but content type libraries specify static assets that are determined at runtime. Getting that to work with new cache system could boil down to a simple change, but I vaguely remember that it does make a new request to an endpoint and that one does no have the files that have to be optimized.

    Here is an example of how it works taken from the field formatter:

    • It determines H5P internal dependencies for the content
    • Runs the alter hooks to allow modifying the resulting list
    • Then aggregates the core assets and additional scripts and styles

    Aggregates are overwritten on each save or content view and removed on each cache rebuild (probably not rebuilt until the content is accessed or updated). If I remember it correctly, new aggregation system works based on libraries and those are specified as a query string. That means that most of the files are not present as those have no libraries and thus are not added to the aggregator.

    Maybe there is a way to define a library for each content type with some kind of hook allowing that library to be filled with assets using content type identifier as a basis. This means that the code determining the assets would be removed from the formatter and moved to that hook (most probably hook alter) that would deal with determining the assets and creating the resulting aggregates. One example would be h5p-content-123 where 123 is the unique identifier of the entity.

    I have not dived deep into aggregate handler inner workings and know how deprecated one maps to the currently active solution. Thus I'm making several guesses and drawn conclusions could be totally wrong. One thing is certain - not using aggregation would mean that a lot of files are loaded at once as H5P uses internal dependency system that allows higher level content libraries to use lower level ones as building blocks. Content types like Course Presentation would probably be loading tens of scripts and several styles. Core also consists of several static asset files.

Production build 0.71.5 2024