chuckda4th

Okay thanks. Was hoping the breadcrumbs would be fixed. We’re not having issues, so no point in upgrading yet.

Actually, as a follow-up, how would I do the same thing to the header text that appears on all of the other pages. I looked at the source trying to find the article id, as I assumed it would be the same code, however the other pages don’t appear to use the same methodology to display the text.

An example is the “WHAT WE DO” page.

Thanks!

Exactly what we were looking for. Thank you!

Thanks for your time, Bojan!

We’re close, as the verbiage has moved to the bottom of the image, however the image itself appears to be chopped, such that only the middle ~60% of it is visible. Thoughts?

Please do not post the actual URL of the website or the domain on this forum, as that is our company name and we do not want this thread to appear in search results for our name.

It is a dot com.

The last letters of the domain backwards are “snoitulos”

The first 3 letters are CFO.

I’m not comfortable posting the site’s URL to this public forum, as the URL is our company name and this could easily be anti-advertising.

Is there a way to PM you with it?

If I were to write it backwards, would search engines be smart enough to pick it up?

We did the following few steps to accomplish this:

Settings…general… uncheck “Anyone can register.”

Settings…Discussion… uncheck everything in the “Default article settings” section.

In the “Pages” screen that lists your pages, if you hover over an individual page, one option should be “quick edit”. Do that and uncheck the “Allow comments” box. Do this for every page (I think there’s a way to bulk edit this, but not sure).

Our pages do not show anything relating to comments any longer.

Actually, I just stumbled on the solution.

For whatever reason, omitting the www. in the URLs in the wordpress settings fixed the issue. Not sure if this is Network Solutions-specific or what.

So, for both the Site URL and Home URL, I used:

https://x.com

Thanks for everyone’s time!

I think I transcribed that slightly incorrectly… I’ve fixed it here and put in more details…

https://y.netsolhost.com directs to: /htdocs/ – Default

Is completely un-editable. There’s no way to delete it, change it from the Default setting, or do anything at all to it. It’s like it’s just stuck there for good.

https://x.com directs to: /htdocs/wordpress1 – Private

I can click a button to edit this, but all it lets me do is change the directory it’s pointing at. There is also an “Unassign” button. This is listed as “Private” with no link or button to change if it’s private (this is what I transcribed incorrectly – the non-www. one is Private, not the www. one).

https://www.x.com directs to: /htdocs/wordpress1

I can click a button to edit this, but again, all it lets me do is change the directory it’s pointing at. There is also an “Unassign” button. This one isn’t listed as Private, nor is there even a link to make it private. I’m not sure where that link disappeared to.

Thank you for your time…would love to get this working correctly.

What would correct URLs do for you if you don’t have the usernames and passwords anyway?

I used an x and a y in my original post consistently, so the particular URLs should not matter.

I’m not comfortable effectively posing on an open forum “We’re having issues with our website,” such that the whole world can see that a firm that does some enterprise software web development on the side is having issues. It would be anti-advertising.

I just noticed that this is marked as resolved, however the breadcrumbs are still not functioning.

Have you heard anything relating to them?

Thanks!

Also, we’re seeing strange behavior in that based on the above settings that we have, i’d expect going to:

https://www.x.com/careers/

Should still work. It does not though.

Using the following:

https://y.netsolhost.com/careers/

Does work.

I would have thought considering our domain settings that these two URLs would take the users to an identical place.

Great. Thanks for your responsiveness!

I’m actually talking about IE 10 and 11. When they are set to “compatibility mode,” the site looks horrible.

In the enterprise software world, people are stuck using IE in a way that it supports their various very expensive and typically older software products. So, let’s say a client is on a 5 year old ERP version. This is entirely possible because ERP upgrades can very easily be $1mm+. I’ve seen them be over $40mm. Then they have an Enterprise Performance Management tool that’s 3 years old that hasn’t been upgraded because that would be $300k. Then there’s some analysis tool that hasn’t been upgraded in 3 years just because people don’t realize its that old and it’s working. Then there’s a data warehouse that was built 9 years ago that was only supposed to be running for 3 years, but they don’t have the capital budget to update it, and frankly it’s still working, too. Typically a client will have many other enterprise applications in the same boat ranging from operational dashboards to HR systems to payroll systems to document imaging systems, etc…

This happens at literally every client I’ve ever had, as it’s simply impossible to keep all enterprise software up to the latest release at all times. You’d need near-infinite IT resources and capital budgets.

IE 10 and 11 certainly may work with all of those older applications, but usually only in “compatibility mode.” Once someone has their browser in that setting, it stays there for all websites they go to, which then breaks the out of the box Goran theme.

This one simple line of code that simply says “hey…this website is compatible with these versions of IE, so if you have it set to compatibility mode, don’t use it” fixes all of that:

<meta http-equiv=”X-UA-Compatible” content=”IE=10,IE=9,IE=8″ />

I realize most Goran users probably aren’t businesses, let alone B2B ones, but I’m just surprised it’s not a web programming Best Practice to always include that line if you know your code is compatible just in case any user ever goes to the website and is in “compatibility mode.”

Thanks for the info!

The only “customization” we’ve made outside of Jetpack’s css editor is a meta tag in our header.php file such that if someone goes to open our site in IE with “compatibility mode” turned on the site still looks as it should. Compatibility mode otherwise makes the site look really bad. I’m frankly surprised such a common setting (many older enterprise software packages our clients use explicitly require this setting to be on) can completely blow up the website, especially considering how easy the fix is. Would something like this be considered a bug as well?

Thank you again!