Changes to 8.1 php server?

What changes were made to the local preview PHP server in RW8.1? My Email stacks have a small PHP service that is used within Preview in order to generate the final email that users need to get the email code for their clients. With 8.1, this now returns the raw PHP code instead of what I have expected.

I have also had many users start to complain about PHP code showing in preview with other stacks once updating to 8.1.

I should add that reverting back to 8.0.3 has resolved these issues 100% of the time.

@joeworkman Can you send me a test project (and relevant stacks) that show this issue, it will be much easier/faster for us to fix if we can get a test case!


Sent you an email with a download to everything that you will need to see the issue.

1 Like

We’ve been reported with issues between RapidCart and RW 8.1b PHP server as well. Tomorrow I’ll have a look at this specific issue, but thought it’s worth mentioning it here as well.

@dan @simon I’ve forwarded to you a sample RCP project which reproduce a similar issue.

Anything in the Web Server logs of RW?

Thanks we’re looking into it.

Okay, we’ve looked into this, and it’s a different issues to Joe’s.

Basically the location for extra files has changed in preview mode. We now put the files in the same place as when they are published.

So a page could end up in say ‘MyPage/index.php’ and plugin files would be stuffed in ‘MyPage/files’. Now it’s the same as publish so that plugin files end up in ‘/rw_common/plugins/blah’

So, in short, preview is now the same as publish.

Hope that all makes sense. Ping us if you need more info.

1 Like

wow, that’s a pretty big change. :scream:
i think i’ll go do some testing now. :grimacing:

also: hey everyone, please keep in mind that Stacks Runs in RW 6-8, that means the path to site-assets is going to have different values in:

  • edit
  • preview
  • publish
  • and vary whether the user has change the folder name
  • and vary depending on RW version

please use the stacks path variables and don’t hard code these paths:

if you notice any issues related to this new change, please report them ASAP

Yeah, that’s why we though it best to do a public beta :+1:

@joeworkman okay, we’ve looked into your issue some more and it’s actually the same issue. You’re special casing “Preview” just like @gibo, so, advice from above applies…

The location for extra files has changed in preview mode. We now put the files in the same place as when they are published.

So a page could end up in say ‘MyPage/index.php’ and plugin files would be stuffed in ‘MyPage/files’. Now it’s the same as publish so that plugin files end up in ‘/rw_common/plugins/blah’

So, in short, preview is now the same as publish.

Hope that helps.

So how do we have a product that works in both RW7 and 8.1? I guess I’ll have to work with @isaiah on it

It would be nice to know the reason for this change as well. Obviously it’s a breaking change that will cause a bit of headache on our end.

a private beta or two, or even just a heads-up email, might have made it a bit easier to make thoughtful changes without the pressure of live customer problems

i know that’s not always possible, but i think it would probably be nicer for users when the option is available

the path variables should be able to help. and if all else fails you can use the version info to inform your php/backend/whatever what version of RW the page was created in - so that it can change behavior accordingly

Erm, this is beta software. It absolutely will contain bugs and there’s a big fat warning if you try and enable the updates for it.

I think this could actually be bug in Stacks, substituting the wrong path for the siteAssetPath variable. I did a little digging and found this in Joe’s Email Inliner stack


In RW8.1 we’ve changed the directory structure of preview so it’s now identical to publish. To be honest, I’ve no idea why there was any distinction in the first place, but these things happen.

So, in RW8.0.3 the exported path to inliner.php looks like this


and in RW8.1 the new location is this (which is the same as publish in RW6+)


I’ve checked the export params that get sent to each plugin and plugincommonpath has changed from




So I think the problem is that Stacks isn’t using plugincommonpath, rather doing a special case using the mode parameter

1 Like

When you release beta software to the public, they still mostly expect things to work. No matter how much you warn them, they don’t understand that things like this can completely break. This is just a fact of life. Some advance notice or warning would have been appreciated.

It doesn’t make any of us look good when we tell customers to roll back off 8.1.

1 Like

That’s just it, RW8.1 does mostly work and it’s pretty stable. During our testing we experienced no show stopping bugs and had no concerns about the export process. We could have released a private beta to developers but even then there’s no guarantee that this problem would have been found.

I honestly don’t think it’s our place to decide if a customer should or shouldn’t install a beta, and I don’t for a second think it looks bad on us. I’ve never seen bug free beta software before. Hell, I’ve never seen bug free software! LOL

If customers need to get their sites published, it’s simple to grab an official release and disable the beta updates. That way they’ll get RW8.1 when it’s ready to go.

1 Like

That is why you do private betas when big things have changed.

You obviously have the luxury of not doing customer support. Here is how things roll in real life…

Customer: My site is broken, it was working fine last week.
Me: What changed? Can you send me your project file?
Customer: Nothing. (finally sends project file after 5 attempts and me teaching him how to zip a file)
Me: Works perfect on my end. (spends 2 more hours debugging)
Me: Are you using the RW8.1 beta?
Customer: Yeah. It auto-updated yesterday.
Me: :man_facepalming:

Customers and developers telling other customers not to use 8.1 because its currently broken does not look good. It makes people think twice when the release version comes out. Not sure how that does not compute.

That is completely logical to everyone in this group. Again… obviously you don’t spend much time doing customer support. :smile:

This change either went down two ways…

  1. You made this change knowing that it could impact some add-ons. If this is the case, someone should have let us know before hand. And in my opinion, given us a private beta. This was not in the release notes at all. Its wasted many hours of my time with customers just like the one I outlined above. Hopefully in the future, you will alert us about changes like this before hand.
  2. You made this change not thinking that this would have any affect on anything. If this was the case, all you need to say is… “Sorry guys! We messed up on that one. We made this change because XYZ. What can we do to help get this fixed for everyone?”

We could go on forever, wasting both of our time, but there is no use crying over spilled milk. Let’s fix just get it fixed and hopefully do better in the future.

I had a couple of ideas while writing this…

  • What if there was a RWBeta app? Similar to web browser development versions?
  • What if after every official release, the beta updates box got unticked? This means that customers have to explicitly want to get the beta update again. This would stop users from updating to a beta that they did not know was a beta. (news flash: most users don’t read release notes in update windows).
1 Like