New OBTUSE Publishing Feature v.2

RapidWeaver Classic
1

Politically-correct version, reposted to cater to THE FORUM RULES regarding my use of language.

Dear Realmac,

What have you been thinking?

With the latest iteration of Rapidweaver 7 updates, 7.3.1, you introduced what is one of the most useless features ever: A nonsensical message box at the end of the publishing process, that is not only totally useless, but a productivity killer as well. Have you thought long and hard over this?

Let me bypass the poor grammar (…files can causes…) as if it’s written by a dyslexic 3rd grader, and concentrate of the 2 serious issues:

  1. I know multiple index files may cause issues. In my case, however, it does not detect both a .php and a .html file. Rather, it detects a .php and a TOTALLY HARMLESS .bak file, which is my .html file renamed. I have my reasons for doing that, and wish to keep it this way.

You claim lots of users flood the forum and support queue with “my pages aren’t publishing” messages when what they have is both an index.html and and index.php page in their directory. Well, I do not have both a .php and a.html file. I have a .php and a .bak index file, and am experiencing no problems, nor do I expect to experience any problems because of the presence of an index.bak file, ever. Your “feature” should be smart enough to realize this, but it is not. And it’s destroying my workflow. I know what I am doing, and do not need to be reminded by you, each and every time I publish a project, for heaven’s sake!

  1. Because it takes time to publish a website, after I issue the command to publish, I take the opportunity to get up from my desk to stretch, use the bathroom, pour myself a cup of tea or what have you, catch up with some news, and wait for the audible signal that my site has been published to return to my desk. With this new feature, however, this “beep” never gets heard, because that nonsensical message box halts the process and waits for someone to click “OK” BEFORE it lets the “beep” sound.

As a result, it’s been just a few days already, but I’ve lost several hours of productivity. What the heck! Have you really thought this over?

Please make this obtuse feature optional (I can guarantee you I will always have it turned OFF) or better yet, remove that FEATURE altogether. Or, at the very least, you can have that productivity-killing message show up AFTER the site has been published, and the end-of-publishing-process sound has been heard. Thanks.

Andreas

1 Like
2

He’s not sensitive. You can make a feature request without being a d*ick / condescending / insulting.

6 Likes
3

Except that I am not asking for a new feature in this case. I want to ask Realmac not to destroy my workflow with the arbitrary introduction of an abysmally obtuse feature that caused me several wasted hours already in the few days I’ve been using the latest update of Rapidweaver 7.

It’s been a feature request for awhile and we’ve implemented it <<

Well, the implementation is flawed. In my case, it does not detect both a .php and a .html file. Rather, it detects a .php and a TOTALLY HARMLESS .bak file, which is my .html file renamed. I have my reasons for doing that, and wish to keep it this way.

Of course this feature is patronizing! And Brian seems to take exception to my language, but he doesn’t give a dime for the fact they’ve wasted several hours of my productivity already with this “feature”.

1 Like
4

You’re shouting at Realmac because they’re not catering their changes to your specific, relatively unique, use case. A feature request would be to have the option to not check for duplicate index files. You can do that without name calling. I just did it in that last sentence, in fact.

4 Likes
5

I do not believe I did any name calling. I called a feature “obtuse” and “stupid”, not a person. And I was certainly not yelling.

And it’s not about my unique case. It’s about the flawed implementation. I was fine before they introduced this “feature”.

Realmac claim a lot of users flooded their support queue with “my pages are not publishing” requests. They are welcome to solve this issue, of course, for all the people who are having these kinds of issues, but their implementation was deeply flawed. They created a big problem. I have always been relying on the audible notification of the “website publishing completed” sound to know when to return to my desk, and now I can’t!

All they had to do is present this stupid message box after the publishing process ends, and the sound is heard. Then, all I had to do is click on OK, and go on with my life. I could live with that. They could also do even better, by adding a “Do not show this message again in the future” check box. In other words, they could have made it optional. But no, they had to halt the publishing process with that stupid message box and prevent the sound from being heard, destroying my workflow.

And because they did all that, I am compelled to, all of a sudden, issue a feature request. It’s not a feature request. It’s a damn bug report!

6

And just to be clear, I do want Realmac to check for duplicate index files. If lots of users are having trouble with this, then, by all means, check for it, and warn users. Who can argue against it?

In fact, I could have used that feature myself several years ago when I was a novice and did not know that .html index files take precedence over .php ones. Heck, I could use a reminder about this issue just in case, even today that I am somewhat experienced.

But the warning feature should be real, not a bogus one. It should warn me of the presence of both an .html and a .php index file, not of a harmless .bak file.

And it certainly shouldn’t disrupt my work flow by preventing the “publishing-completed” notification sound from playing.

And it should be made optional, by adding a “Do not show this message again in the future” check box.

2 Likes
7

Most users would freak out if they saw that warning and not know what to do anyway. The checker is a good idea but only needs to throw a warning if RW is about to Publish a PHP version to a folder that has an HTML version and vice versa. If the error condition is found then why doesn’t RW offer to remove the html version as an option. What is the purpose of the OK button and what happens if you press OK?

This does not appear to have been thought through very well.

3 Likes
8

Typically what tends to happen is that people start with a page named index.html. Then a few months or years down the line, they add a stack to the page which automatically changes the page name to index.php and they don’t notice the change. Then after they publish their website, the older index.html continues to take precedence over the newer index.php version. And so we start getting reports of “publishing not working” or “new stacks not showing”. It’s a common problem - one which I’m seeing almost weekly. I can see that RMS want to eradicate this issue - because it is probably costing them a lot in extra support too.

I have not seen the error that @andreasfmpro reports. But I appreciate the point he is making and would agree that this new ‘feature’ in its infancy is perhaps not implemented as best as it could be.

Of note, some stacks include a ‘requiresPHP’ string in their Info.plist file that tells RapidWeaver that the page needs a .php extension. This change is done automatically, with no knowledge to the user. Perhaps if there was an alert thrown (to the user) when a stack or other addon tries to automatically change the page extension, that could be a good compromise for all?

EG: user adds a contact form stack to a page. RapidWeaver flags up a message ‘the stack you are adding to this page requires a .php extension. We can change this for you, but you need to manually delete older versions of this page from your server. Do you wish to continue [yes / no / help]’.

There are genuine reasons for needing both a index.html and index.php file in the same directory. You might be using one as a utilitarian page or for redundancy / backups. So I think it would be wrong for RW to automatically nuke conflicting pages. And how would it work if the conflicting page was not originally created by RW, but a CMS, file manager or something else? This could actually cause far more problems than it solves.

I think alerting the user to an automatic change in the page extension would be a more proactive approach. And the alert needs to be thrown long before publishing commences - at the point when an addon tries to modify the page extension.

5 Likes
10

Steve, it was Brian, because in my first, non-politically-correct version of the original post, I described that “feature” using colorful metaphors such as obtuse, stupid, and a PoS.
:smiley:

Good thing I exercised restraint, or it could have been a lot worse, lol!

1 Like
11

Even with restraint, you’re still obnoxious.

4 Likes
12

What can I say? Love me or hate me, that’s me. Deal with it.
:slight_smile:

1 Like
13

You might be using one as a utilitarian page or for redundancy / backups.

And that’s exactly my primary use of a “duplicate” index file.

The funny thing is, mine is a backup, or .bak file, not an .html file, so the warning should not even be triggered.

2 Likes
14

My two cents. Rapidweaver is an amazing product. To express your opinion about a feature or request a feature be added or taken away is one thing, but to act like a spoiled child who can’t have a lollipop is just not cool. Poor you, you don’t know when to return to your desk.

I don’t have a problem with it and a lot of others don’t either. It’s not a bug when it is an intended feature.

Good luck to you.

5 Likes
15

Point taken. I disagree with you completely, but you are entitled to your opinion.
:slight_smile:

Except for the fact Rapidweaver is an amazing product. Here I agree with you 100%.
:slight_smile:

To be precise, I am perhaps acting like a spoiled child that has had his lollipop taken away, not that I can’t have one.

And yes, poor me, I do not know when to return to my desk. And you know why? Because I can no longer hear that @#$%^&*! website-published sound!

1 Like
16

Hold on are you not the person who posted here an alert to the community that you are done with rapidcart which basically started a thread where people just bad mouth his product? and then criticized yuzool because you didn’t like his new business model? You really think alot of yourself don’t you…perhaps you should not throw stones

1 Like
17

I didn’t say anything mean, nor did I bitch or use bad language. I just said I wasn’t getting support.
As far as @yuzool, I am on good terms with them and only posted my opinion on another post that I didn’t like the way their website was set up. I wasn’t the only one.

There is a difference… and that is all I will say.

1 Like
18

No difference yeah Ok…look up the word hypocrisy

1 Like
19

Hi @andreasfmpro, thanks for sharing your feedback on our recent publishing feature. We’re all about making RapidWeaver perfect for our users - this why we introduced this option, in fact.

We realize there is an advanced user group base in RW - many of our users ARE advanced. However, we do have a good percentage of users that aren’t well versed on aspects of a server that can cause issues with their website. It so happens, as Brian mentioned, that 60%+ of issues submitted regarding “publishing” are caused by THIS exact scenario. This led us to believe it was a common issue that needed a remedy - here’s our first attempt at a remedy.

Thanks to your insight (and others), we’re able to look into ways for improving this error - making it more meaningful, directional, etc.

I’d always recommend submitting your feedback to support@realmacsoftware.com - unless your intent was to crowdsource backing for your opinion! :slight_smile:

ALSO - Yes, we are all grown ups, and we can take big grown up talk, but grown ups know how to talk nice too. Let’s be nice - your point will come across with much more weight.

4 Likes
20

Thank you, Aaron,

I believe we all here consider Rapidweaver to be an insanely great product. Please, let’s not have any misconceptions of what my message was on this thread.

This is not about a feature for advanced vs. not-advanced users. In fact, I do not consider myself an advanced user. Rather, I believe I am an intermediate, or “know-enough-to-be-dangerous” user. And compared to the brilliant volunteers in this forum, I am indeed a novice.

Regardless of user level, this is about a very, very poor implementation of a feature. No matter how well-intended it was, it causes inexcusable problems. Even users who claim it does not affect them, well, if they had a similar workflow as mine, such as heavy reliance on the sound at the end of the publishing process, they’d be screaming mad, as well.

This reminds me of a very similar feature introduced by Yabdab in Formloom 2, that made it a very poor product in my opinion (Thankfully, Formloom 3 is fantastic!) In Edit mode, every time a user created a field and/or tried to move it up or down, a very annoying message would pop-up, warning the user to check and reset the fields corresponding to Name, E-mail and Subject in Settings. Every. Single. Time. There was no option to make this extremely annoying message not appear again. It was pure madness!

To summarize:

  1. Poor grammar in the message text (The least important issue).

  2. False problem identification (My .bak index file is harmless; does not and would not create any problems).

  3. Does not do much about the identified problem (This is where there is room for future improvement, but it is NOT what I originally wrote this message for. I really do not care about this that much. I also understand this may change in future versions of this particular feature. Not a concern for me, however.)

  4. Does not give the option to dismiss without seeing it again. (Check box: Do not see this message again)

  5. Abruptly halts the publishing process at the very end, not allowing the “website-published” sound to be heard.

From the 5 issues above, the most important BY FAR are no. 5 and then 4 and 2 in order of importance.

You are welcome to introduce all the well-intended features you want, for all kinds of user levels. The more the merrier. Just please make sure you do not disrupt a user’s workflow, and for heaven’s sake, make everything optional, including making message boxes dismissible with the option of not seeing them again.

Andreas

21

@andreasfmpro, thanks for the follow up message. As mentioned in my previous message, we are aware it may be an imperfect implementation of a solution - and we take your feedback and consider it. I can’t make any promises but I imagine this will be addressed, at minimum, a ‘check to not show…’, etc.

Again, this is mainly to solve an issue that perplexes many users. This pop-up wouldn’t appear if you didn’t have multiple index files. If you were publishing a site without multiple index files on the server, this issue would never appear and you’d get the soothing sound. What I’m trying to say is, this isn’t an issue that affects many users to a point where it’s an inconvenience - if there is multiple index files, we want that message to appear so users know it’s the root or branch of a problem. Simply said, I’d wager there are very few who use .bak index files and encounter this as a problem for them.

I’m not intending to cause a debate on the use of .bak files, all I’m saying is that you have a VERY special case scenario here - and I do see how this specific feature inconveniences you, but that doesn’t mean it inconveniences many others.

Example: we warn against using multiple index files, as they cause issues 95% of the time - but you intentionally place multiple index files (you have a specific purpose). We’re trying to solve a specific issue, but you are backing your site up a specific way / using multiple index files.

As noted above, we will see what we can do to improve this - I just wanted to clear up any misconceptions noted above.

P.S. - I’d also recommend our built-in backup feature for your website. Many hosts like Chillidog Hosting also have outstanding backup services as well.

Closing this thread for now, will contact you directly if we require any further input on improving this feature. Thanks for sharing/pointing out! :slight_smile:

2 Likes