js Files not loaded

Hi, I am trying to get your plugin running, but haven't succeeded so far.

I installed it and added the [editable] shortcut to one page for testing. What works:

• I see that the div tag is adjusted, i.e.
• I see that depending on whether I am logged in as a user, that additional files are loaded in the source code (mainly 2 CSS files)
• However the Javascript files are not added to the source code Here I am puzzled why this is not the case. I could try to add them manually, but I'm not sure if this is feasible since at least the editor.js seems to be created dynamically. And of course something is not running as expected, as the .js files should be added automatically as well :)

[bleutzinn]

I can not replicate this.

As can be seen in line https://github.com/bleutzinn/grav-plugin-editable-contenttools/blob/8965544681807a99e19f5445e873a1d0cc2788ab/editable-contenttools.php#L23 all assets, being the 2 CSS and 4 JS files, are added in one go. So when the CSS files are in the page source code but the JS files are not the cause must be elsewhere.

[alangner]

You are right, I had an issue with the js pipeline. I now see that all the .js files are added to the html source. However I cannot open the editor.js, I get a 404 error

So for example this relative link works: /user/plugins/editable-contenttools/css/editor.css But this one gives a 404: /editable-contenttools-api/editor.js

On your demo page the paths look similar for these two files. Is the editor.js really outside the /user path? And can I somehow check if/where this file exists?

[bleutzinn]

Yes, these URL's are relative to the webroot of your site. It appears you've installed Grav in the webroot. The demo is installed in a subdirectory (demo-grav-plugin-editable-contenttools) and thus the URL's start with the name of that directory starting from the webroot (/demo-grav-plugin-editable-contenttools).

When the page has been created and is sent to the browser the file editor.js does not exist. When the browser parses the page it encounters the <script> request for the file editor.js and sends that request to the server. On the server every URL which includes editable-contenttools-api is handled by the plugin and when the URL endpoint is editor.js the Javascript is generated and send back to the browser. The browser then executes that script.

Being in a subdirectory or not does not make a difference to the plugin. You can check it's working by visiting https://omgevingsverkenner.nl/typography. I've temporarily copied the entire demo into the root of that domain.

Since you mentioned you had an issue with the JS pipeline I wonder what special setup you're using or building. With Grav's out of the box JS pipeline it simply works.

[alangner]

Thanks a lot for the explanations. My JS pipeline is acutally not that special. In the grav settings there is an option to merge all JS files into one file, which i had used before. And I think this does not work together with your plugin. But even if I uncheck this option, it still does not work (The server returns a 404 for the editor.js file) In the end there still must be something special about my setup anyway, since as you said, your plugin works with a new grav setup out of the box :)

I will try to debug this further. Somehow the editable-contenttools-api URL is not handled properly, or maybe not intercepted by the plugin.

[bleutzinn]

When enabling the JavaScript pipeline Grav will try to include the file editor.js as well. But will fail to do so because there is no such physical file at that moment. There seems no way to exclude an internal JS file from being included in the pipeline.

[alangner]

For a quick&dirty debug, in the php file inside the function onPagesInitialized() https://github.com/bleutzinn/grav-plugin-editable-contenttools/blob/8fd48397115d75176fb645dfab29aca57b90ffc7/editable-contenttools.php#L191 I have added this line: $this->grav['log']->debug('Paths: ' . json_encode($paths) . json_encode($this->grav['uri']));

Now, if I open my page in the browser, the only log entry i get is: DEBUG Paths: []{"url":"https://myDomain.com/„} I would have expected also a second log entry for editor.js (where the paths variable includes the path to editor.js)

If I open directly https://myDomain.com/editable-contenttools-api/editor.js I get a 404 in the browser, and no log entry from the php file.

I also do get this log entry from the php file every minute: DEBUG Paths: []{"url":"http://localhost/"} (not sure if relevant)

[bleutzinn]

Are you having this with the JavaScript pipeline enabled or disabled?

[alangner]

I disabled it, since otherwise I wouldn't have the editor.js in the html page.

[bleutzinn]

As a test, could you please change addJs in line #144 to addJsModule and let me know your findings with the JS pipeline enabled and disabled.

The function addJsModule was added to Grav version v1.7.27 so make sure you're using that version or above.

[alangner]

If I use addJsModule for the editor.js, then I always have this file in the html source no matter if I turn on the JS pipeline or disable it. But the main problem remains, the server returns a 404 for the editor.js

[bleutzinn]

Can you look in your PHP access log file? It's interesting to see what on the PHP level is requested and results in the 404 error response.

[alangner]

I am using nginx. Here is what I see in its log:

2022/04/22 18:12:16 [error] 18479#18479: *8 open() "/var/www/grav/editable-contenttools-api/editor.js" failed (2: No such file or directory), client: 172.17.26.9, server: 02ab642c8c9d, request: "GET /editable-contenttools-api/editor.js HTTP/1.1", host: "myDomain.com", referrer: "https://myDomain.com/"

[bleutzinn]

Perhaps NGINX expects a physical file while it actually is a virtual one. I have no experience with NGINX what so ever.

[bleutzinn]

One last thing that crossed my mind: are you using the Grav nginx configuration? See the section about nginx in the Grav documentation.

In the default Grav .htaccess file there is this redirect which redirects any request for a file or folder which does not physically exist to Grav. In this case this command ensures that the request for editor.js gets handled by Grav and then by the plugin.

I don't know whether or not this helps. Perhaps you could try with Apache?

[alangner]

Thanks, I will investigate this further end of next week.

[grahamIT]

Any update on this bug? It doesn't work for me and I see the following message when I look into the console.

[bleutzinn]

No. I was waiting for @alangner for results of his investigations.

[alangner]

Unfortunately I gave up at some point and didn't continue to use this plugin.

[grahamIT]

I guess I'll keep looking to see if I can figure out whats wrong. I was really hoping to use this plugin

[grahamIT]

Is there any process figuring out why this wasn't working?

[bleutzinn]

Today I have installed the plugin on localhost (Windows + XAMPP) running PHP 8.1.10 and on a Debian GNU/Linux 10 (buster) Linux system running PHP 8.1.12 as well. Both systems use Apache and have Grav v1.7.42.3 installed.

After installation the plugin runs fine without any other configuration.

So I am sorry but I simply can't reproduce your issue.

[grahamIT]

This issues seems to be very odd. I am running the Linuxserver container image with the following docker compose:

---
version: "2.1"
services:
  grav:
    image: lscr.io/linuxserver/grav:latest
    container_name: grav
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/Denver
    volumes:
      - ./config:/config
    ports:
      - 80:80
    restart: unless-stopped

I don't see anything in the logs but it seems that that script doesn't exist. Perhaps I need to try running it on bare metal to see if that fixes the issue.

Update: The linuxserver image uses PHP 8.2.9 which is newer that the version you tested. Maybe something has changed that causes the script not to be generated correctly.

[grahamIT]

So I got Grav and this plugin working in a Debian VM with PHP 8.2.7 and nginx 1.22.1. This makes me think it is either the container breaking things or the newer php version

[bleutzinn]

This weekend I tried to install nginx on localhost which went OK. However I couldn't get Grav running on it.

Regarding the PHP version, I've just tried the plugin using PHP 8.2.7 and 8.2.10 on my Debian GNU/Linux 10 server without any problems.

[grahamIT]

I am going to test setting it up on an Alpine Install to see if I can reproduce the issue outside of the container. This may be related to the linux server container config

[grahamIT]

I couldn't get grav to run on Alpine linux and I am unfortunately giving up on this plugin. If someone is reading this in the future feel free to jump in.

[bleutzinn]

I understand. To be honest I have no idea how many people actually use this plugin or even whether or not it is used at all. It does work as far as I am able to test it on localhost on Windows and a shared hosting account (at Alwaysdata) using Debian Linux.

[grahamIT]

Couldn't you just leave this issue open without activity? I don't see any problem with letting it go stale.

[bleutzinn]

I am reopening this issue to make it more visible though I suspect the cause lies in the server hosting Grav. So one might say it is some kind of incompatibility. Grav is more focussed on Apache than Nginx and in most cases the plugin runs fine though I don't have any data to back that up.

More information is needed before I can try again to replicate and look for a solution.