I’ve got a single-page site built with Source that seems to work just fine when it’s out in the world, but… Although the default extension is set to html in the RW project file, the index page shows as index.php and stubbornly resists all attempts to change it to html. This in itself would not be a problem, but I’m hosting it on AWS S3, which doesn’t support php and displays the raw source code if I upload the site as published by RW. But everything works OK if I manually change the file suffix to .html after publishing. (I also edit the index page contents to change internal references to “index.php” to “index.html”) Other than Source stacks, the page also uses a 1LD Horizon Parallax stack and a Joe Workman Impact stack inside a BWD Limelight. I’m guessing that one of these stacks is enforcing the use of the php page suffix, but doesn’t actually require it. Does anybody have a better idea? The site is here: <www.kiritoshi.com>
Limelight does not use PHP
Sounds like there’s definitely a stack on the page that has PHP turned on.
The best bet would be a process of elimination.
Remove each stack on the page and try and change the extension to HTML. When you can change it then you know what stack needs PHP.
True, but the baffling part is that — as long as I change the name of the index page to “index.html” after publishing it from RW — the page and all of the stacks on it are fully functional when hosted on AWS S3, which does not support any form of php. So other than a serious case of embafflement over why things work when they shouldn’t, my problem isn’t really a problem. In a related thread, Joe Workman suggested that gremlins were the probable cause of a similar problem, and at the moment, that’s the only explanation that seems to fit. 
Joe was just being facetious. I think he was getting exasperated dealing with a stubborn user.
If in fact the stacks are fully functional, then one of them has the Php File Extension Enable attribute set to on in the stack plist, when it isn’t needed.
But more than likely, one stack on the page requires php, at least for some of its functions. Even if you had a thousand stacks on the page, it wouldn’t take long to figure out which one is the culprit.
How to find the problem
First things first – before we start making radical changes or running tests – make a backup of your important work – and then just work on a dummy copy of your file – one that you can throw out when you’ve managed to find the issue
If the page is not too big or complex the easiest way to find the problem is to delete each stack, and test after each. If the scrolling problem goes away then you know it was in the stack you’ve just deleted.
If the page is very large (as is often the case in these scenarios) you can use divide and conquer to find the culprit.
I know what you’re thinking, “my page is too big for this,” but let me assure you that it isn’t. In just 10 tests (about 2-3 minutes of effort) you can isolate a culprit in 2^10 stacks using divide and conquer. That means, in a very short amount of time you can find a problem among 1024 stacks…
Remove half of the stacks on the page.
- Retest to see if the scrolling problem remains
- If the problem is gone then you know that it was in the stacks you remove. So choose Undo to bring them back and delete the other half instead.
- If the problem remains and there are still lots of stacks on the page, repeat the process.
- Continue until you’re left with only the culprit.
Uh, er…OK. Except I don’t have any scrolling problems (or any other problems other than a sense of bafflement). But the page isn’t that big, and since I enjoy getting to the bottom of Unexplained Mysteries, I’ll give it a try and report back.
Wasn’t meant to say that you are having scrolling problems. That was a quote from the stacks knowledge base, the steps of cutting in half to find the culprit will work with any problem. You just would try to change the extension to HTML between each round.
Found it! I didn’t actually use the ‘divide and conquer’ method because the page is mostly plain-vanilla header, markdown and image stacks. I just went through and deleted the very few ‘advanced functionality’ stacks I was using one by one. It turned out to be a Scribe Floating Image child stack. Not sure why that stack requires php, but I’m sure Tav made it that way for a reason. In any case, it seems to work just fine using my ‘change the index file suffix after publishing’ workaround. Mystery solved!
It is because it supports the loading of CMS images directly via PHP.
Unfortunately, the way stacks work, they have to either require PHP or not, we cannot turn that requirement on or off dependent on user settings and whether or not it is actually using PHP (which yours is not of course).
Thanks, Tav. It’s always nice to know the ‘why’ of something. I’m a big fan of Scribe, and until I learn another way to achieve the tight text wraparound (at side and bottom) that the Scribe Floating Image stack offers, I’m perfectly happy to do a little post-publishing tweaking. And it’s reassuring to know that I’m not breaking some fundamental rule of the stack’s use by doing so.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.