Budsy

Followup… The install I’m using is on GoDaddy’s WP hosting, and they put in a plugin of their own called CoBlocks. It is unclear if these editing blocks are involved in this issue. No branding or identification of what block object is being used while editing on the WP back end. I don’t want to implicate Sinatra directly, but maybe someone has a comment on this.

Ok, thanks for the information. Yes, I see what it’s doing now.

Ok, some improvement after re-installing. Settings now work, but not always as expected. If the featured image is set to show, the ‘Read More’ feature does not show a link, unless the character limit for the excerpt is set to zero.

Follow up again: I fixed it by setting the banner class width:100% !important; That worked around whatever issue in the Calendar. I suspect there was a naming conflict. Problem solved. Or at least worked-around.

Followup: Actually what is happening is that the banner image is being shifted slightly to the left. I measured the image and it is not resized, but simply shifted. But by comparing pages by navigating, the container is size for the page box is exactly the same. So, it is not the calendar pushing out the box, rather some Css that is shifting the banner image. Css class naming conflict??

I should mention, I am using the Savona theme.

If you copied the database from a remote server, you’ll need to change some URLs in table wp_options. Set column option_value to your local app’s URL where option_name= ‘siteurl’ and ‘home’ respectively.

Update: I just confirmed that the /wp-content/web.config file is re-written without a file existence check. So, my workaround fails. The site becomes corrupted repeatedly.

Bob

I thought I’d follow up on my experience with my Windows 7/PHP 7 and WP 4.7 install issue. On my Windows machine, I had to fall back to PHP 5.6 in order to get WP 4.7 to install successfully. I proceeded to install a theme and plugins and content, completing a full site using PHP 5.6. But when I moved the project over to a Linux/Apache production server and setting it to run PHP 5.6, I discovered that it wouldn’t run successfully under PHP 5.6. So, I set the server to use PHP 7 and voila, it worked fine. So, although I have not investigated this fully, I think it might have had something to do with my installing a 64-bit version of PHP 7 — just a guess. My Windows 7 setup worked fine running PHP 7 with some general test PHP scripts, but balked at the WordPress 4.7 install, as described in my first post. If I figure out the problem, I’ll follow up again.

I think I found the problem. It may have been introduced in a c. November 2015(?) update to the ALO EasyMail plugin. There is a function to parse the outgoing HTML and manipulate URLs for making TrackBacks. This seems to not be working correctly, because some hyperlink tags are completely stripped. Others simply don’t redirect to the intended target, but do point back to the originating WP application. I stubbed out the function code so that no filtering occurs and the HTML is simply passed through. This should fix the problem.

OH, I should have mentioned these failed hyperlinks are in EMAILed (published) newsletters from the ALO EasyMail Newsleteter pluggin. The newsletter as displayed in a WP page is fine– all the hyperlinks work as intended. Somewhere in the email chain the hyperlinks get fiddled in some way.