Changes to 8.1 php server?

Ok, I’m not going to tell you how to do support but your first question really should be “What version are you using?”. Especially knowing there’s a beta in the wild.

Nope, neither of those. We had no idea it would impact plugins and we didn’t mess up. We’ve altered the preview system and updated the parameters accordingly. If plugins were using the the right parameters there wouldn’t be a problem.

I wouldn’t actually call this a major change because plugins shouldn’t have been impacted. And I’d estimate the number of plugins / stacks impacted to be less than 10%. Big changes to the API would be a major change.

If we did run a private beta, how long do we run it for? Like I said before, there’s no guarantee this bug would have been found. It took at least 5 days for the problem to surface and that was only because a customer reported it.

The same happens for all software, including official releases. I’ve seen many posts from users saying they’re waiting for 8 to stabilise before upgrading from 7. The same thing happened with 7.1, same with 7, same with 6…

I like this idea! I’ll have a chat to the guys about it.

i’m in a similar situation: managing an API and the end-user experience.

in most cases i usually throw caution to the wind and release a public beta. i mean, beta means bugs, right?

but occasionally i change something that might impact the API (or how it’s being abused :stuck_out_tongue_winking_eye:). in those cases i give devs the direct download link before i send things out via auto-update.

that gives devs one more chance to pull the emergency brake before end users see it. mostly everyone ignores it, but every now and then it saves our butts.

it’s not perfect, but it’s super easy for me, makes the dev’s job a bit easier …

and makes things better for customers

…which is what really matters.

i’m not suggesting you do this, i know your situation is different. i just thought i’d let you know what’s been working OK over here in stacks-land. :slightly_smiling_face:

3 Likes

Thanks Isaiah, I appreciate that.

I totally get where you guys are coming from. It’s really frustrating when you waste time trying to figure out what’s gone wrong instead of working on new stuff.

“Better for the customers” is always a good thing, but I must stress that the number of users affected by this is minimal.

From the stats, I can tell that < 0.023% of users have this beta and even less have been affected - that’s pretty good going :wink:

The important thing is that we know how to get this problem solved. If anyone needs any more info regarding the export params mentioned in the fix above, let me know!

We’d like to get RW8.1 launched in time for Mojave.

Mojave ships Monday. I am not sure that I can get all of my products patched in time. This affects more than just one of my products. Had I known 3 weeks ago when beta 1 shipped, chances would have been better.

I still don’t know why this change was even made. How does this benefit us?

It’s also not as simple as changing the paths in my code. I now have to support both possible locations. I can drop all of my customers and only support 8.1

@joeworkman I don’t think you need to do anything because you’re using a path variable that gets replaced by stacks diring export.

@isaiah can you confirm this please, will an update to Stacks solve this?

Bug Report

Summary:

Preview of resource macros only works on some pages. On other pages it may preview an incorrect path. The macro works as expected in RW 8.0.

Here’s a video demonstration of the steps below:

To repeat:

  1. New Project
  2. Create 2 Styled Text pages.
  3. Open the resources window
  4. Drag in an image.
  5. Right-Click the image in the resources window and choose Copy Macro.
  6. Go to the 2nd Styled Text page (not the homepage).
  7. Paste the macro and add the macro to an img tag.
    Here’s what I have:
%resource(flower.jpg)%
<img src='%resource(flower.jpg)%'>
  1. Preview the 2nd page.

Expected results:

To see the image and have a path to a directory where the resource was published for the preview web server.

Actual results:

The resources folder and the image is published to ./resources/flower.jpg (in the same directory as the 2nd page’s index.html), but the path provided by the macro is ../resources/flower.jpg (a path to the root directory – where there is no resources folder currently published.

Notes:

  • If the above experiment is repeated with the Home folder it works fine.

  • If the above experiment is repeated and the same resource is used in the home folder then the experiment above will work so long as the home page is previewed first. In other words: it works accidentally.

  • Stack’s usually tries to just do whatever Styled Text pages do. But in this case I can’t tell which way is correct. The behavior of the exported content is a lot like RW v8.0 Preview – but the macro is behaving like publish mode – and you kind of said that’s how all things are heading. So, kind of seems like you could go either way here – and there’s no documented API to fall back on – so ¯_(ツ)_/¯ – whichever way you choose, i’ll try to patch stacks as soon as i can afterwards.

Thanks @Isaiah, that’s definitely a bug in RW!

The resources folder should be at the root of the preview directory just like it is in a published site. The path provided by the macro is correct, we just need to export resources to the right place instead of in a subdirectory of the page.

Cheers!

As I’ve reported, this affects RapidCart as well. We’ve come up with a fix, basically looking at RW build number. We keep using existing behaviour for builds < 20217 (RW 8.1b1), while start providing the same path for preview / export for newer builds.

Does it sound safe? @tpbradley

You’ve still not answered why this change was made. Is there any good reason for all of us to put in work for something that wasn’t broken.

@joeworkman We’ve been moving at an extremely rapid pace with RW8, I’ve re-written a bunch of antiquated underlying systems and changed entirely how site resources are handled, how publishing works, addons are located/migrated and rebuilt a tonne of the main UI. The result, RW is faster and more stable than ever. The changes to preview will become more apparent in the future, and you know what - I don’t need your permission to change things.

If you’re using the standard path variables that Isaiah mentioned you don’t need to make any changes, right?

@gibo Please don’t check for version numbers, just use the path supplied in the plugincommonpath param that gets passed to your plugin. Is there a reason you can’t use it?

We use this parameter in our built in Blog plugin for the smileys feature and had to make no changes at all for it to work in RW8.1

In RW6/RW7/RW8 the plugincommonpath contains files and the plugin’s extra files end up in

RWDocumentPagePreview/blog/files

in RW8.1 the plugincommonpath contains ../rw_common/plugins/blog/ and the plugin’s extra files end up in

RWDocumentPagePreview/rw_common/plugins/blog/

RW8.1’s preview content is now identical to the published output, which is infinitely better than exporting to two wildly different directory structures. @joeworkman, Not sure how that does not compute.

No. You don’t need my permission. However, it is common professional courtesy when you are developing in the same ecosystem to explain architectural changes like this. It’s sort of like working as a team (God forbid) instead of a dictatorship.

Probably best if I just close this thread and back away slowly…

3 Likes