frontdesk

Thanks for the feedback.

As sterndata suggested I removed the #BEGIN #END comments around my blocks.

And as MarkRH suggested I rearranged the sections according to his example.

So MarkRH’s example is what I have most recently been using:

<IfModule mod_rewrite.c>
RewriteEngine On
## SEO REDIRECTS
Redirect 301 /page1.html https://www.acme.com/page1
Redirect 301 /page2.html https://www.acme.com/page2
Redirect 301 /page3.html https://www.acme.com/page3
</IfModule>

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# remove the .html extension
RewriteCond %{THE_REQUEST} ^GET\ (.*)\.html\ HTTP
RewriteRule (.*)\.html$ $1 [R=301]
</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Still the incoming .HTML is not getting dropped (except for my explicit 301 redirects which ARE dropping the .HTML, so at least that part of the .htaccess is being processed).

Unless there is some obvious incorrect syntax then I am at a loss. Is there some directory permission that I need to do? Or perhaps my RewriteBase is wrong?

And since this is my first Godaddy managed WP site I haven’t completely ruled them out as a suspect yet (but I have nothing to base that on).

Any other suggestions?

Here is my full .htaccess:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
## SEO REDIRECTS
Redirect 301 /page1.html https://www.acme.com/page1
Redirect 301 /page2..html https://www.acme.com/page2
Redirect 301 /page3.html https://www.acme.com/page3
</IfModule>
# END WordPress

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
# remove the .html extension
RewriteCond %{THE_REQUEST} ^GET\ (.*)\.html\ HTTP
RewriteRule (.*)\.html$ $1 [R=301]
</IfModule>
# END WordPress

You can see that I have a few hard-coded individual page redirects in there from earlier which I am leaving in because they are critical. My question here is: how do I get this RewriteRule rule (i.e., to universally change any incoming URL that ends in .HTML by simply dropping the trailing .HTML) to run as expected and change incoming URLs as follows:

https://www.acme.com/blog/anything.html
should be rewritten as
https://www.acme.com/blog/anything

NOTE that I am running for the first time on a Godaddy managed WP host and – although I discussed it with their tech support to confirm that .htaccess should behave the same – I am not 100% sure that the .htaccess is being processed the same as on a non-managed-wp host.

My bottom line question remains: do you see any reason why my .htaccess would not automatically drop any incoming “.HTML” suffixes?

It appears that the “[AIGetTwitterFeeds ai_username= …]” shortcode was added to the page using the WYSIWYG Visual tab rather than the Text tab – so it is not being interpreted as HTML. Try re-entering that shortcode as HTML using the Text tab.

Nevermind. Upon further review I discovered that another plugin that was previously installed called REMOVE DASHBOARD ACCESS (RDA) was disabling access to Dashboard for any user with an EDITOR role. When I had added the user with EDITOR role (the first one for this system) I had neglected to account for EDITOR in the RDA plugin settings, so USER ROLE EDIT OR was not to blame.

I have similar problems on WP 3.9. I installed the plugin and blacklisted all user roles except the EDITOR role.

When I login as EDITOR it shows the black admin tool bar BUT I cannot access the Dashboard. And even if I go directly to /wp-admin/ it simply redirects to my redirect page.

It does not affect (correctly) the ADMIN role since I can still login as ADMIN and access the Dashboard.

In an effort to track down the culprit I temporarily changed the File Permissions of one of the affected images from 0644 to 0444 (thus removing write privileges) in order to force an error message to occur.

I then reloaded my homepage which caused the following error:

<b>Warning</b>: imagejpeg() [<a href='function.imagejpeg'>function.imagejpeg</a>]: Unable to open '/home/myname/public_html/wp-content/uploads/featured_image_100.jpg' for writing: Permission denied in <b>/home/myname/public_html/wp-includes/media.php</b> on line <b>467</b><br />

Since my homepage is merely displaying the featured image as part of a display of recent posts then why is ‘media.php’ attempting to open this image for writing?

Incidently, here is Line 467 of my media.php module:

if ( $post != $_post )
wp_update_post($post);

… and it is in the middle of the section for “function media_upload_form_handler()” which is odd since I am only displaying posts and not updating or adding posts.

I ran into the same WordPress SEO by Yoast conflict on my WP 3.4.1 site.

Since I was running the std version of the calendar plugin then Initially I tried upgrading to “Free 1.8 RC-2.zip” but this did not resolve the conflict, so I then tried “Premium 1.8 RC-2.zip” and this did successfully resolve the SEO plugin conflict.

However, now that I’m running with the Premium 1.8 RC-2 I now notice that when “Hide Google Maps until clicked” is NOT checked then the small Google Maps are no longer visible for each event (although the full Google Map displays OK when I click an event’s “View Full-Size Map” button). But, if I then check the “Hide Google Maps until clicked” then I can no longer click to display even the larger Google Map).

One minor unrelated comment on the calendar plugin is that it would be nice to able to opt to NOT to display the PRINT button on the Agenda page.

In spite of these issues I still like this calendar plugin. When you do finalize the next release of the plugin can you please include upgrade instructions for those of us who are running the Premium 1.8 RC-2 temp release? (if it is different than a standard upgrade)

P.S. I was thinking after-the-fact that since the Yoast SEO conflict was merely a display issue related to the data entry of SEO parameters then instead of upgrading to the calendar’s RC-2 fix I could probably have stayed with the current release of the then.ly plugin and instead simply 1) deactivated the then.ly plugin, 2) entered my Yoast SEO parameters, and 3) re-activated the then.ly plugin and all would have continued to function properly for both the calendar and the Yoast plugins… but this is just a theory as I did not try it.

Problem solved. For the record I used a combination of a cookie script from owt4nowt.ca that I inserted into a child theme override of functions.php.

Here is my child theme override of functions.php

<?php

/*************************** Add Yahoo Media Player to footer ***************************/

function add_this_script_footer(){ ?>

<script type="text/javascript">

// begin cookie code
// ++++++++++++++++++++++++++++++++++++++++++
// Run Once Per Session
//
// Replace the alerts by functions that need to
// be run once per session.
//
// Written by: Michael Regan
// Website   : www.owt4nowt.ca
//
// Released under the GPL.
// ++++++++++++++++++++++++++++++++++++++++++
var key_value = "myTestCookie=true";
var foundCookie = 0;   

// Get all the cookies from this site and store in an array
var cookieArray = document.cookie.split(';');   

    // Walk through the array
    for(var i=0;i < cookieArray.length;i++)
        {
               var checkCookie = cookieArray[i];
        // Remove any leading spaces
               while (checkCookie.charAt(0)==' ')
               {
                 checkCookie = checkCookie.substring(1,checkCookie.length);
               }   

        // Look for cookie set by key_value
                if (checkCookie.indexOf(key_value) == 0)
               {
                  alert("Found Cookie ");
            // The cookie was found so set the variable
                   foundCookie = 1;
               }
    }
    // Check if a cookie has been found
    if ( foundCookie == 0)
    {
        // The key_value cookie was not found so set it now
        document.cookie = key_value;
        alert("Setting Cookie");
//    }    move this to end
// end cookie code

    var YWPParams =
    {
        autoplay: true,
        volume: 0.5
    };

    }   // moved from above
</script>
<script type="text/javascript" src="https://webplayer.yahooapis.com/player.js"></script>
<?php } 

add_action('wp_footer', 'add_this_script_footer', 20); ?>

?>

Maybe I need to rephrase my question.

Does anyone know how I can add

<script type="text/javascript">
    var YWPParams =
    {
        autoplay: true
    };
</script>
<script type="text/javascript" src="https://webplayer.yahooapis.com/player.js"></script>

… to the bottom of my front page only once per session? (once per day would be OK also)

I found a solution (thanks to Moff at stackoverflow.com) whereby I use php output buffering, as in his example:

<?php
// example from php.net
function callback($buffer) {
  // replace all the apples with oranges
  return (str_replace("apples", "oranges", $buffer));
}
ob_start("callback");
?>
<html><body>
<p>It's like comparing apples to oranges.</p>
</body></html>
<?php ob_end_flush(); ?>
/* output:
   <html><body>
   <p>It's like comparing oranges to oranges.</p>
   </body></html>
*/

In my situation the page I was working with was a contact form template, so I added equivalent code and was able to intercept the HTML and use str_replace to manipulate it (changing the culprit http reference to https) before sending it on to the user.

In my instance the “culprit” was the sociable plugin, but I suspect that many plugins could similarly trip the IE warning message.

One drawback to this technique is that the entire page is buffered before it is sent to the user, but in my case the transmission delay is negligible.

I have one page within my WP site that requires HTTPS, so I updated .htaccess to force that page to be HTTPS. This works OK except that some of the generated WP code (either via plugins or whatever) are generated with HTTP rather than HTTPS.

These non-HTTPS references are causing IE browsers to display the warning message:

Do you want to view only the webpage content that was delivered securely?

Here is a partial dump of a VIEW SOURCE of the page in question, and it shows the HTTP references that are causing IE to display the above warning message (note that I changed the references to the live domain in the source view below to ‘somedomain.com’):

SomeDomain.com<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="https://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">

<head profile="https://gmpg.org/xfn/11">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

<title>My HTTPS Contact Form</title>

<link rel="stylesheet" href="https://www.somedomain.com/wp-content/themes/mytheme/style.css" type="text/css" media="screen" />
<link rel="pingback" href="https://www.somedomain.com/xmlrpc.php" />
<link rel="shortcut icon"  href="https://www.somedomain.com/wp-content/themes/mytheme" />

<meta name='robots' content='noindex,nofollow' />
<link rel="alternate" type="application/rss+xml" title="SomeDomain.com &raquo; Feed" href="https://www.somedomain.com/feed/" />
<link rel="alternate" type="application/rss+xml" title="SomeDomain.com &raquo; Comments Feed" href="https://www.somedomain.com/comments/feed/" />
<link rel="alternate" type="application/rss+xml" title="SomeDomain.com &raquo; Contact Comments Feed" href="https://www.somedomain.com/contact/feed/" />
<link rel='stylesheet' id='sociable-front-css-css'  href='https://www.somedomain.com/wp-content/plugins/sociable/sociable.css?ver=2.9.1' type='text/css' media='' />
<link rel='stylesheet' id='wp-pagenavi-css'  href='https://www.somedomain.com/wp-content/plugins/wp-pagenavi/pagenavi-css.css?ver=2.50' type='text/css' media='all' />
<script type='text/javascript' src='https://www.somedomain.com/wp-includes/js/jquery/jquery.js?ver=1.3.2'></script>
<script type='text/javascript' src='https://www.somedomain.com/wp-content/themes/mytheme/includes/mytheme.js?ver=2.9.1'></script>
<script type='text/javascript' src='https://www.somedomain.com/wp-includes/js/comment-reply.js?ver=20090102'></script>
<script type='text/javascript' src='https://www.somedomain.com/wp-content/themes/mytheme/scripts/contact-form.js?ver=1.0'></script>
<link rel="EditURI" type="application/rsd+xml" title="RSD" href="https://www.somedomain.com/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="https://www.somedomain.com/wp-includes/wlwmanifest.xml" />
<link rel='index' title='SomeDomain.com' href='https://www.somedomain.com' />
<meta name="generator" content="WordPress 2.9.1" />

<!-- All in One SEO Pack 1.6.10 by Michael Torbert of Semper Fi Web Design[311,346] -->
<link rel="canonical" href="https://www.somedomain.com/contact/" />
<!-- /all in one seo pack -->

</head>
<body class="page page-id-38 page-template page-template-contact-form-php logged-in">
<div id="page">

	<div id="header">
		<div id="header_inner">
			<h1><a href="https://www.somedomain.com/">SomeDomain.com</a></h1>
			<div class="description">&quot;My Title&quot;</div>
			<div id="header_links"><a href="../">home</a>&nbsp;&nbsp;|&nbsp;&nbsp;<a href="https://www.somedomain.com/about">about</a>&nbsp;&nbsp;|&nbsp;&nbsp;<a href="https://www.somedomain.com/contact">contact</a>&nbsp;&nbsp;

			</div>
		</div>
	</div>

...remainder of code truncated for convenience

My thought was that if I could intercept the generated HTML before it is sent to the browser then I could change the problematic HTTP to HTTPS.

Any suggestions as to how I can get rid of the HTML that is causing the IE warning message?

bump

Thanks, but let me rephrase the question:

– I am in page.php
– I do “get_header()” so that header.php can generate its html
– I now am back in page.php at the line immediately after the “get_header()” statement

My question is: how do I access the output that was generated by the “get_header()” funtion?

Is there some global variable like “$page_output” that contains all the HTML that was generated so far?

TIA

DOH moment on my part. t3los_ you were correct and it was simply the URL settings in my dashboard. Thanks

Gretchen, I visited your site and I see that you resolved the issue. I have a similar situation.

I have a single page (“contact”) that I want to be HTTPS, so I configured my .htaccess as follows:

NOTE: I am running on a shared host ISP

[BEGIN .HTACCESS SNIPPET]

Options +FollowSymLinks -MultiViews
RewriteEngine on
#
# Redirect to force SSL and trailing slash on bad links to donate-now page
RewriteCond %{SERVER_PORT} !=443 [OR]
RewriteCond %{REQUEST_URI} !/$
RewriteRule ^contact/?$ https://www.mydomain.net/contact/ [R=301,L]
#
# Redirect to add missing trailing slash unless URL ends with a "filetype"
RewriteRule ^(([^/]+/)*[^./]*[^/])$ https://www.mydomain.net/$1/ [R=301,L]
#
# Redirect all non-canonical hostname requests to canonical domain, preserving SSL/non-SSL
RewriteCond %{HTTP_HOST} !^www\.mydomain\.net$
RewriteCond %{SERVER_PORT}s ^(443(s)|[0-9]+)$
RewriteRule ^(.*)$ http%2://www.mydomain.net/$1 [R=301,L] 

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

[END .HTACCESS SNIPPET]

My goal was that whenever a user goes to https://www.mydomain.net/contact then that page should be HTTPS, and the above .htaccess does that by forcing the HTTP to become HTTPS. However, I still get the ‘nonsecure items’ warning in IE when going to this page.

If I do a VIEW SOURCE of my /contact page I can see that the WP-generated links to my theme/stylesheet/javascript files only have HTTP, so that is probably why I am getting the ‘nonsecure items’ message.

I noticed on your site that you successfully not only force your /donate page to be HTTPS but that you no longer cause the ‘nonsecure items’ warning to be displayed in IE, and if I do a VIEW SOURCE or your /donate page I can see that your WP-generated links to theme, stylesheet, etc., have a HTTPS prefix.

How can I similarly get my non-HTTPS WP links to be generated by WP as HTTPS for this single /contact page within my WP site?

All suggestions appreciated