Can't upload course presentation to WordPress on Pantheon

WP 5.1

htp 1.11.3

host: pantheon

Getting a 504 time out when trying to upload attached file.

Works fine on host wpengine.

Pantheon has a system where you can't write to folders outside of wp-content/uploads.

Does h5p create tmp directories for uploading? This won't work on pantheon.

How can I control the tmp directories for file uploading?

Thanks for your time,

-Andre Gagnon

H5P file: 
icc's picture

No, all files should be within the wp-content/upload/h5p folder.

It sounds like PHP might be hanging on some sort of operation. You may have to add some debugging in order to determine what's happening.

I'm using Drupal/Opigno at Pantheon. Just ran into same problem. 2 years same issue? Any ideas on what can be done?

ctli's picture

How can I support a new feature?   Pantheon will not change its infrastructure.    There is also memory issues when adding H5P content.  I've tried upgrading the hosting package to the max and it did not eliminate the issue.  

Php-slow.log

[19-Jul-2024 16:50:41]  [pool www] pid 47

script_filename = /code//wp-admin/admin.php

[0x00007d847b415cb0] copy() /code/wp-content/plugins/h5p/h5p-php-library/h5p-default-storage.class.php:522

[0x00007d847b415be0] copyFileTree() /code/wp-content/plugins/h5p/h5p-php-library/h5p-default-storage.class.php:519

[0x00007d847b415b10] copyFileTree() /code/wp-content/plugins/h5p/h5p-php-library/h5p-default-storage.class.php:138

[0x00007d847b415a40] exportLibrary() /code/wp-content/plugins/h5p/h5p-php-library/h5p.classes.php:1843

[0x00007d847b415890] createExportFile() /code/wp-content/plugins/h5p/h5p-php-library/h5p.classes.php:2230

[0x00007d847b415780] filterParameters() /code/wp-content/plugins/h5p/public/class-h5p-plugin.php:939

[0x00007d847b415610] get_content_settings() /code/wp-content/plugins/h5p/public/class-h5p-plugin.php:1033

[0x00007d847b415500] add_assets() /code/wp-content/plugins/h5p/admin/class-h5p-content-admin.php:250

[0x00007d847b415410] display_contents_page() /code/wp-includes/class-wp-hook.php:324

[0x00007d847b415330] apply_filters() /code/wp-includes/class-wp-hook.php:348

[0x00007d847b4152c0] do_action() /code/wp-includes/plugin.php:517

[0x00007d847b4151e0] do_action() /code/wp-admin/admin.php:259



[25-Jul-2024 18:45:20] NOTICE: child 22 stopped for tracing

[25-Jul-2024 18:45:20] NOTICE: about to trace 22

[25-Jul-2024 18:45:20] NOTICE: finished trace of 22

[25-Jul-2024 18:46:23] WARNING: [pool www] child 24, script '/code//wp-admin/admin.php' (request: "GET /wp-admin/admin.php?page=h5p&task=show&id=11") executing too slow (5.998271 sec), logging

 

Exact same error in our php-slow logs on Pantheon as well - be happy to encourage a fix or assist in updating this as the module is rendered useless (it is triggered on the Create/Update step, the creation of the H5P modile or uploading one works fine).

Please help!

Used Claude to build an mu-plugin to work around this, if you want to read the details below and give it a try. It has worked for us so far.

https://gist.github.com/bartmann-arizona/d8115d67191de9ccb477c7305db6425e (also attached as test to this)

Title: H5P content save times out on Pantheon (and other network-filesystem hosts): cause and a working workaround

Summary

On Pantheon, saving or editing H5P content was taking 45-49 seconds and could time out against Pantheon's 59-second web request limit. The same plugin works fine on hosts with local disks. I saw identical behavior with the Drupal H5P module on Pantheon, so the cause is in the shared H5P PHP library, not the CMS plugin. After the workaround below, saves take about 10 seconds on the same items.

Environment

WordPress multisite, H5P plugin 1.17.9, Pantheon (wp-content/uploads is a symlink to the network-mounted /files).

Cause

The php-slow.log trace shows the time in copy() inside copyFileTree(), called from exportLibrary(), createExportFile() and filterParameters(). On every save, H5P rebuilds the downloadable .h5p export. To do that it copies every file of every dependent library into a temp folder under the H5P directory, zips it, and deletes the tree. On a network filesystem, each small-file operation has real latency, and a Course Presentation or Interactive Video pulls in about 75 libraries and thousands of files.

Timing around exportLibrary() on a heavy item showed:

  • About 40 of the 45-49 seconds went to copying libraries (0.05-1.4s each).
  • About 16 libraries were copied twice into the same export.

Workaround (a must-use plugin; no changes to the H5P plugin)

It replaces $core->fs with a subclass of H5PDefaultStorage that does three things:

  1. Builds export temp folders in local /tmp (getTmpPath()), so the thousands of small writes and the final deletes don't hit the network mount.
  2. Skips libraries already copied into the same export.
  3. Caches each library as a single zip under {h5p path}/libcache/, keyed by the library folder name and the modification time of its library.json. After the first export, a library costs one network read plus a local extract instead of hundreds of small reads. The zip is built locally and then renamed into place, so concurrent saves never read a half-written file.

A WP-CLI script primes the cache for every installed library, in time-boxed runs so it doesn't hit remote-command limits.

Code: [link to Gist with the mu-plugin and the priming script]

Results (same items, same multidev/dev environment)

  • Save time: about 45-49s before, about 10s after.
  • Library phase of a save: about 40s before, about 2s after.
  • Exports downloaded from cached saves import cleanly on h5p.org.

Caveats

  • It overrides internals (H5PCore::$fs, H5PDefaultStorage::getTmpPath() and exportLibrary()), so re-test after H5P plugin updates. The mu-plugin only swaps the stock H5PDefaultStorage. If the plugin ever changes its storage class, it does nothing.
  • Each Pantheon environment has its own /files, so each needs its own priming run. Re-prime after content-type updates from the H5P Hub, or the first save that uses an updated library pays a one-time rebuild.
  • Tested on one multisite install with H5P 1.17.9. [Add: running on live since 9/29/2026.]

Suggestions for the H5P maintainers

This has been reported since 2019. Either of these would remove the problem at the source:

  • Generate the .h5p export lazily, when someone downloads it, instead of on every content save.
  • Make the temp folder location configurable, so hosts with network-mounted storage can point it at local disk.

 

I diagnosed this with Claude (Anthropic's AI assistant), working from the slow-log traces, the plugin's storage class, and timing logs I added on a multidev. Everything above was measured and tested on my own environments, and I'd recommend testing on a non-production copy first.