Possible Pinegrow's internal server bug?

General Bug Reports
1

Hi all,

I know PG’s internal server is a mystery one serving pure html/css/js…

This has been hitting me for a long time, really frustrating… but would like to understand if it’s PG’s fault or not. In my code snippet (included at end):

  • both img tags gets literally the same src starting with a / (slash).

  • while PG shows one img correctly, It doesn’t pickup the other image
    image

  • when I open the same page in vscode live server, both images are displayed correctly
    image

WHY this anomoly?

<!DOCTYPE html>
<html lang="en">

<head>
  <title>Is this a bug?</title>
</head>

<body>
  <img id="in-html" src="/image.jpeg" />
  <img id="via-js" src="#" />

  <script type="text/javascript">
    document.getElementById('via-js').src = '/image.jpeg'
  </script>

</body>

</html>

Related stackoverflow discussion here - What does “./” (dot slash) refer to in terms of an HTML file path location?

2

is PG interpreting the # before the js defines it?

what happens if you move the js to above the img?

or am i being too procedural in my thinking…

what happens if you leave the 2nd image src defined as NULL?

3

Tried a lot of combinations @droidgoo, no luck… Something is fundamentally wrong… It even doubt if PG has an internal server at all, looks like it’s just opening local file for edit and renders it, may be hence we see the local file opened when we try to preview any page in the browser.

4

Try using ./ and re / enable Javascript (see below) then both should preview correctly in app.

Pinegrow Preference Settings Enable Javascript

Pinegrow-Pref-Settings-Enable-Javascript
Pinegrow-Pref-Settings-Enable-Javascript844×69 13.1 KB

Pinegrow Toolbar Toggle Javascript

Pinegrow-Toolbar-Toggle-Javascript

Perhaps within the app when you use just / via Javascript it takes you upwards into the internals of Pinegrow itself, someone can correct me on that. But if your image is residing directly beside your html then ./ should work in both instances correctly as long as JS is enabled as seen above. It should then correctly preview in app along with when viewed directly in a browser locally.

I’m not sure where in the Pinegrow Documentation is a good singular reference regarding things related to JS. The below holding page "docs/working-with/javascript/" would definitely be a good spot for general related javascript things for the app. :wink:

https://pinegrow.com/docs/working-with/javascript/

1 Like
5

Thanks @Pinegrow_User… The ./ does work, but I’m after why / doesn’t work as it’s a valid one, especially when the / works in html and not when rendered via javascript (only in PG, other servers renders this fine).

Long story short, I have webpack on my “real” app, that outputs:

  • css & js minified links starting with a / (slash)
  • dynamic elements whose href & src also starts with a / (slash)

The first one, where I want to convert / to ./, I can use pinegrow’s below fix link, which does fix it and the css & js files successfully load.
image

The second one, I can’t fix it in PG as they are dynamic elements.

To summarize, / should work as it’s still valid, PG is anyway rendering it fine for inline html, while it doesn’t when generated by js (while other other servers works fine). Hence, this bug report.

Can one of the pinegrow team help here please, @Emmanuel

6

Yes I agree, using / does not work for me either, thats why I wondered aloud if using it via JS is going a leverl up into Pinegrow itself. Its rather odd I will agree as each are valid.

I saw your other post about JS Frameworks in the Vue thread. Hopefully staff will respond to both.

1 Like
7

@RobM, any luck with this one? Would be great to get some clarity on if this is in fact a bug or not? Thank you!

8

@TechAkayy
Well, / and ./ are actually interpreted differently. The first, a forward slash by itself actually refers to the root, while adding a dot before it refers to the current directory of the file it is in.
To illustrate-
With the following HTML:

<img src="/photo.jpeg" alt="Avatar" style="width:100%">

For output I get:

image
image1930×40 17.9 KB

For:

<img src="./photo.jpeg" alt="Avatar" style="width:100%">

I get:

image
image852×46 9.01 KB

With regards to the server - When you are adding the src by JS it doesn’t have the correct reference for the base file, so when it encounters the naked slash it interprets in as the root of your server without any of the intervening folders

image
image726×44 6.96 KB

I’m not what the right behavior should be for PG. I can see an instance where you have a nested component and in the production environment you want to access root, so I’m thinking that the “fix links” shouldn’t “repair” this. I’m wondering if having the preview interpret the naked slash differently should be the behavior. So in this example, the PG server should interpret it as:
image
image780×44 10.8 KB

prepended to ‘photo.jpg’. This is essentially what the server will do when it sees ./ when it outputs to the preview browser.

I’ll ask about the “correct” behavior"

9

@RobM Are you by chance making a Lottie plugin (regarding this recent Lottie thread) ?

1 Like
10

D-oh!

i knew showing that file structure sting was going to come back on him :slight_smile:

11

:wink: Why do you ask? :rofl:

12

@TechAkayy the page base href in PG is not the same as outside of PG, due to the way of how the internal web server is addressed. PG does some URL mapping behind the scenes for static HTML. That’s why the HTML example works. But it can’t do anything for dynamic JS code.

One workaround is to use relative urls like image.jpeg or ../images/image.jpeg but of course that doesn’t work if the same code is run on pages at different levels of the folder structure.

13

Just found it out and thought it would be useful (myabe cause you probably know this already):

theres an opensource plugin for controling lottie with this script, it scrubs through the frames of the file by scroll or other events.

if you want to try it out you will need to include the main lottiefiles script.

1 Like
14

Thanks, I’ve already had been working with this library for awhile.

15

Hi @RobM, thanks very much for taking the time to explain, clearly PG using my file system as base URL for absolute paths doesn’t make sense at all.

Web servers usually have a baseURL, or at least consider the current location of the index.html file as baseURL. I have already opened my project in PG, not my whole file system. Definitely, there is opportunity for improvement here (it’s really not an improvement, I see it as a fundamental).

Thanks again!

16

Thanks @matjaz for taking the time to explain.

I have sent a follow-up on this issue via email to Pinegrow support with more details and attachments, would appreciate you having a look at it. Cheers!

17

Thanks @TechAkayy, I did some work on that, will reply soon.

Local projects can now be served from the internal server root. That would solve these issues.

The feature will be out soon, we are testing it at the moment.

rooturls
rooturls1786×1106 994 KB

2 Likes
18

Thanks bunch @matjaz for prioritising it, much appreciated :slight_smile: