Is anyone else having the issue of changes not showing up in the first Preview of the change made, or the first Publish Page made?
I can make a change and Preview the changes but the changes do not appear, until I toggle back to Edit and back to Preview again (with no further changes made).
The same applies to publishing. I can make a change, and publish the change, either with “Publish Page” in the page’s menu, or using Command K, but until I publish the change a second time, the change does not appear.
This is exasperating! Is anyone else having his problem? I am using RW Version 6.3.7 (15153) and Yosemite 10.10.5 (14F1509).
I believe it started to happen for me one incremental update sooner and I just lived with it hoping it would be resolved in the next update, but it was not. I’d say it’s been going on for well over a month for me, but it’s been a fairly slow month - I’m starting to pick up again so I sure hope it gets addressed soon.! Thanks for your input. Both of you…
I first noticed it when I went back to a project which I hadn’t opened in about ten days. It’s possible that the 6.3.7 update had been released and applied in the meantime.
I was using the Clean Accordion Stack; but that may be irrelevant if others who’ve noticed this weren’t.
In Edit Mode: Select the page > Stack > Stack element. Make a change… edit text, add a new paragraph etc
Switch to Preview Mode to see the changes. They do not appear. The page is as before. I have no doubt about this
select Edit Mode again; *click on an edit)
switch back to Preview Mode one or more times to see the changes.
Are changes kept in a buffer or scratch file somewhere, perhaps, which is not being tracked/flushed etc?
My most recent incident was while using CosCulture’s Collapsible Stack.
Yesterday I edited text by underlining it, use command R to preview, the change did not appear, used Command R to go back to edit mode, and immediately used Command R again to preview it, and the change was there.
Hmmm - a ‘common’ denominator is the collapsible type stack. I just tested this in a Styled Text page and it did not happen in the styled text page.
I just tried it in a FormLoom page and a rapidFlickr page and the problem was not present in either of those pages either.
I then tried it in a Text stack in a Stacks page and the problem was there. I use Stacks for so much of my work that it seemed ubiquitous, but now that I look at it, with just those few tests it does appear to be linked to Stacks pages.
In addition to the Styled Text, the FormLoom, and the RapidFlickr pages mentioned above, I now tested it on an HTML page, a Blocks page, a Text page, and a File Upload page and none of them display the problem, only Stacks pages.
But … I did try it on a Stacks page in a Plain Text box in an HTML stack and it did not occur. This particular project was made on RW5 and upgraded to a RW6 file. So then I added a Text stack to that same page [in a 2 Columns (Stacks 2) stack] and the problem also did not occur then.
So again, from my limited testing, it does appear to be Stacks related, but not the older Stacks, or at least not in a project built in RW5 and then saved in RW6 format.
Hey, @nikf, I was intending to write about this problem a long time ago (at least, when RW was in its v.5.x), but I was always putting it off, thinking that was only my experience. Now I see it is wide spread.
The problem of changes in settings not taking effect is definitely not just a Stacks problem, because I see the same thing happening when I try to change colors in themes’ stylings. It just so happens, that most people experience this phenomenon editing stacks.
Apart from stubborn color settings, sometimes I can not change numerical settings – for example: paddings, margins, etc. BTW, in my experience, changes are not taking effect not only on first try, but persistently. Sometimes, even after several restarts of RW and/or OS X.
When RW6 launched it did most of the exports without hanging up the user interface. Which is awesome. But this mandated a few changes from us plugin devs. One of them was not “finishing edits” (nerd explanation: QuickLook previews blocked the main thread. Finishing edits requires the main thread. When both happen, you get deadlock. Ouch). This means that since then you’ve been required to click “Done” or click outside of a text view to lock down those text changes – before – you click Preview.
This was a pain, but there was simply no alternative for a plugin like stacks that has text-views that need to come and go (simpler plugins don’t have this issue). Blocks has similar (but different because of more technical reasons) issues with previewing while still editing.
However the change here is a single character edit (a change from “async” to “sync”). So, I figured I’d test it just to see. And what do you know, it works fine now.
So… I’ve put in a query to @nikf to find out what changed and when. Perhaps we can (for recent versions of RapidWeaver) get the desired behavior back again.
BTW: I’m going to release a beta with some updates for image naming (bummer – looks like i’m not allowed to post about the betas here – but they’re where they always are and open to everyone) and I’ll sneak in this change too if you’d like to test it out. Look for that version to drop in a few hours (Monday the 8th around noon pacific).