Broken resources path with sub-pages in latest RW8 versions

Since RW7, when previewing a sub-page, we have been stripping out all ../ occurrences in resources path because page file and resources were published in the same folder level (i.e. root).

We have noticed that now with the release of RW 8.1.x actual subfolders structure is preserved in Preview and we need to treat Preview like Publishing.

Is this change expected?
Maybe I’ve missed it, but if it’s expected, when did you notice us?
What RW version do we need to check to handle different behaviours?

1 Like

AFAIK, this was already introduced in 8.1.0

So I don’t know exactly if there was an additional change between 8.1.0 and 8.1.4.

I wonder why this issue is coming up for you / RCP now and not earlier

Thank you, @instacks.
The problem seemed to have been fixed in some beta, but it reappeared in latest releases.

Checking for RW version has been discouraged but it seems the only practice to handle different RW behaviours.

I’d like to know when this change has been introduced and if we can trust it won’t change in future releases.

1 Like

@rob Stacks had to make changes to resource paths for Preview mode too. I think there might be a couple more of these that are still un-found. It seems like it could affect any plugin that uses Php.

So, just so we’re on the same page: the paths that changed are the ones we get from the “params” passed to in the API export methods. Notably filesFolderName and resourcesFolderName (also assetsFolderName for really really old version of RW).

Prior to v8.1 Preview mode exporting put everything into one folder. v8.1 makes Preview mode a lot more like Publish mode (identical??? maybe??? i’m not certain in the corner cases). This means that there is now a full site hierarchy and the resources folder is now in the Published location at the root of the site – potentially several .../../../ up from your other page assets.

This had two impacts on Stacks code…

  1. Pre v8.1 filesFolderName and resourcesFolderName pointed to the same place (usually files) when in Preview mode.
    When generating paths for the Stacks API I had mistakenly used filesFolderName instead of resourceFolderName. Oops. My bad.
    So the solution here is to double check that all your resources paths really use the correct resources param and not the files folder param. And of course avoid hard coding, but we’re all professionals here and so none of us ever hard code anything. :stuck_out_tongue_closed_eyes:

  2. Prior to v8.1 Preview mode was all in one folder – so there was never any hierarchy to worry about. Pages published 3 layers deep used files and pages 10 layers deep used files too. This is important if you need to generate absolute paths for Php. Prior to v8.1 I did just like you and stripped the ../ to generate an absolute path for Php scripts. Now this works sometimes, but not others – because Preview mode is hierarchical. So watch out – I see that you saw it was …/ sometimes but not others – maybe you’re just testing on the homepage vs. on a hierarchically nested page. I don’t think this is knowable just from the API. We just had to find out when it got released and users started reporting the problems. Oops. Some else’s bad.
    But the solution is easy enough: just to make your Preview paths the same as your published paths whenever you can.

Hope that helps. Let me know if you have any questions. :smiley:

3 Likes

Oh, one more cool thing:

I made a test stack that I use along with some scripting to do automated testing of a bunch of the paths the Stacks API can generate. I made it open source and public on GitHub, mostly so that Stack devs and I can have a common reference when trying to find bugs in this stuff – because it can be insanely hard to track through two APIs.

If you want to see what some of the expected paths are at any specific point you can grab it here: https://github.com/yourhead/PathsTestStack

You just drop it into a stacks page and it displays a whole bunch of paths. You can see how they change between thee different modes, different project settings (like in the Advanced tab), and different versions of RW.

Let me know if you need a Stacks license.

Isaiah

2 Likes

Thank you, @isaiah, for your kind support.

I’d like to get a word by @dan.
We rely on this functionality to link product images in RapidCart Pro.

Hey Rob,

As far as I know nothing has changed that would affect this since 8.1

Thanks
Dan

1 Like

@rob oh, and if you think it is RapidWeaver, just send me a project showing the issue and steps to re-create it :+1:

Are broken images in Foundation image stack related to the same problem, @joeworkman?
I cannot see images in Edit mode.

39

@rob

  1. Is that just with foundation? or with all images inside Stacks?
  2. If you create a new image stack does the problem happen again?
  3. If you create a new page…
  4. If you create a new project file…
  5. Can you give me a complete rundown of any version numbers you’re using: macOS/RW/Stacks/Foundation.

If the problem persists and but isn’t easy to re-create can you share the project file with me?

thanks

1 Like

Foundation using warehouse images.

Yes (with Foundation).

Yes.

Yes.

macOS 10.14.3, RW 8.1.4, Stacks 3.6.5, Foundation 1.8.6.

  1. New project
  2. New Stacks page
  3. Add a Foundation Image stack
  4. Enable Warehouse Images?
  5. Select image from Resources

thanks @rob. i can repeat that too. i’ll look into it.

1 Like

oh. wait.

sorry. yeah, i see.
i don’t think that’s unexpected.

i don’t think RW assets aren’t available until preview/publish. i didn’t test, but i would guess that’s not really new behavior.

OK, yeah… tested and confirmed.

I think the best we could do there is to try to recognize on the fly that the selected link is not to a remote site, but to a local resource – and then try to hunt down the resource info.

That’s a little dicy right now – I happen to be working on that for Stacks 4 right now actually – the API for resources changed pretty radically between RW7 and RW8. Trying to support both versions of RW with resources is non-trivial.

As much as I hate to do it, because I think it really limits sales – I’m likely going to have a few features in Stacks 4 that are just “RW8 only” because there isn’t an easy way to provide similar features in both versions.

Isaiah

2 Likes

Interesting. I don’t think that I have ever env tried to link to a resource using the warehouse feature…

1 Like