Html and php index files randomly being generated

Rapidweaver 7.4.1 has started to generate both html and php index pages rather randomly.

This behaviour started today with an alarm after publishing.

I have re-published the entire site but still the issue remains.

Upon checking my server via Transmit I can see that some pages remain html (the choice enabled in settings) whilst other pages have suddenly changed to php and some others still have both html and php versions.

I realise I can go and delete php index files but that becomes a real pain each and every time I upload so would like to understand what is going on and how to correct it.

Help would be appreciated.

Paul

Even if you have html chosen as a default, some addons may force the use of php as an extension. That’s normal. Without php they won’t function.

Since you use Transmit, my advise would be to delete all files and republish again.

To avoid this kind of situation in the future, I would change permanently default extension from .html to .php in RW Preferences for all kinds of files.

5 Likes

Also interesting is that Foundation usually gives you a heads up if you’ve got a duplicate index.php and index.html file on your server (and lets you say which one you’d like to trash).

I think he is being told. I have my default set to PHP as well, have not noticed any HTML popping up (not yet). Do wish RealMac would make that option and all options something you could set for all new projects.

I also have my .htaccess file set to look for index.php first so if an index.html gets out by mistake it won’t find it.

DirectoryIndex index.php index.html index.cgi

3 Likes

Hi, if you set RW to use .html as default but some stacks automatically use .php (like the Agent stack and many others) this would explain the situation.

Gentlemen

I have asked RM for their official thinking on using php as the default to see if they are aware of any reasons NOT to use php as default and hope this will resolve the duplication issues.

Will advise further once I have that response.

Well, that’s a little advantage of code.

Hi Paul, believe we’ve been corresponding via the help desk, but wanted to update those that are following.

This happens when stacks or plugins force the page to use PHP (as other have mentioned), and if the page was previously an .html page, it’d cause this “duplicate” issue after a fresh publish.

You can log onto your server via cPanel / FTP and remove the oldest “index” file for each page, or simply delete all associated files for your site and do a re-publish [File > Republish All Files].

There’s no real advantage or disadvantage to using .html or .php. PHP is more dynamic, and HTML more static.

Some hosts prefer (prioritize) .php files or .html files, so find out what they prefer and use that file type.

1 Like

Hi Aaron. Any thoughts on Teefers request to set html or php for all new projects as a RW setting?

1 Like

I think all the “site Settings” need to be added to RW preferences.

We can set the default theme to use but have to remember to change all the other settings.

3 Likes

It’s ok if I let RW decide what it should be… html or php, yes? As long as I know to check for dupes? thx

RW prefs and site prefs are different. RW prefs are for the program itself. Site prefs might indeed have a good reason to be different from site to site (or project to project). When the web page is rendered, php pages will process through another process and there is no need for that to happen if they are html only. PHP will actually slow down page loads. You will probably never notice it but it does happen. Just think of PHP as a programming language that actually builds the page when it is shown as opposed to a “static” page that never changes. An html is simply rendered, while php runs a process and builds pages “on the fly.” Hope that helps…

1 Like

You’re missing the point. I’m not suggesting that site preferences get replaced by RW preferences, just asking that defaults are available to be set, just like themes. You have a default theme but can change it for each site. My issue is things like Consolidate CSS, Cache-busting links, etc. should be a user settable default. If you’re a “one site” user of RW, it probably doesn’t make a difference. But the folks that use RW for lots of sites (Website Developers) its a pain.

By the way, I know a bit about PHP, in fact, I have developed and taught classes in PHP for quite a few large-cap companies IT departments. My firm as part of stress testing for clients have tested, and the difference in speed serving an HTML document(has no PHP code) that has a PHP extension is less than a millisecond (that was the smallest unit of measurement our tool used).

1 Like

Doug… sorry if i offended you. Though I quoted you my answer was intended for all, including those who don’t have a clue what php is. Again, sorry. I should not have quoted you.

2 Likes

Aaron

Thanks for your further feedback.

In my case I feel it makes sense to

  1. Change the default extension to php

  2. Delete all existing server files

  3. Republish everything (again !!)

I assume that RW when rebuilding prior to publishing will note the php file extension default and publish accordingly ?

Just want to check this point as it takes hours to republish.

There should be no reason in the future for RW to publish any html files - correct ?

Paul

Hey, Paul, sorry for a huge delay with this response (I presumed the person you’ve addressed the question to will respond).

Once you change your preferred file extension from html to php, that change will take effect in your new pages. For all existing pages you will have to change the extension manually — page-by-page — if you indeed want them to assume the new extension. You do that in each page’s General Settings:

1 Like

This happened recently with my site and the person working on it did not think to mention the warning message from Rapidweaver on publishing. This resulted in us having php and html versions of our home page live for weeks. We have since lost all our rankings for that page (our home page - and most important). It will not even appear in search results for the business name. Even though I have now deleted the php file our site is still not ranking in the SERPS. This is happening in Google and Bing so does that make it unlikely to be a penalty. Does anyone have any advice on this? Our site has not been in SERPS for about a week now and it’s already starting to impact us.

Hey, @GemmaG,

If you have both .html and .php versions of the same page, that most likely means that RW has automatically changed the extension from .html to .php after some sort of addon has been recently included in a previously published page. This is normal behavior.

You should leave the .php version and delete .html version (not the other way around). The reason you have both versions instead of just one is because RW never deletes anything from the site that has been previously published. Google penalizes sites with duplicate pages.

For the future, to avoid situations like this one, you should change the default extension in General Settings/Advanced like in this screenshot (from html to php):

html-php

This won’t have any negative effect on how your website will work. Most of us do it that way.

You may also want to begin publishing manually, using some sort of a FTP application (Transmit, Yummy, CyberDuck, etc.). That way, you will have total control over contents of your website on a server and you will avoid many pains associated with letting RW publish automatically. Just export your website to a local folder (on your computer’s desktop, for example) and then upload manually to your server.

1 Like

Off topic… (RE: “Default Extension”) - Wow… i can’t remember the last time I actually added a new blank page. I honestly don’t think I ever have. :slight_smile: I always start a “new” page by duplicating a similar page and going from there.

On Topic: As a reminder only, changing the default after some pages have been created doesn’t change the existing pages and this is normally where the duplicate problem is going to be when a new stack “forces” a page to go with the php extension. But yes, if all pages are php to begin with then there can be no problem.

@Rovertek… I know you know all that… I’m responding to the issue in general and not your post specifically.

Thanks so much for the info. It’s certainly not a mistake we will be making again. Let’s hope they let us out of jail soon. :frowning: