RadiantFreedom

I appreciate your help, but re-read this part:

up until the last mailing, the newsletter was showing the featured images. In the last newsletter, none of the featured images were displayed,

So, what I’m trying to figure out is why code that was working fine up until 8 days ago is suddenly not working now.

I’d already tried the other methods and they failed to produce any images at all. Feeditem:Content just pulls out the title in all my tests, including one I just did now. Anything that pulls the images just give only alt text. Other methods weren’t giving me the layout my client wanted for these emails, so I had to pull the contents 1 piece at a time so I could get them placed correctly.

Right now I’m trying to figure out where this error is coming from. I already know it’s not from the RSS feed itself, as the feature images, titles and summaries all appear as they should there, when I view it through a feed reader plugin in Firefox.

So the best theory I have at the moment is there’s either a problem with how the feed’s being delivered to Mailchimp for email delivery, which is preventing the image files from being delivered, so that only the alt text can display – or there’s an issue with Mailchimp itself not correctly pulling contents out of the rss feed.

Firefox isn’t choking. My Firefox did the same, because there is no default for that mime-type. Once you tell it what is default, it just shows the file because it does not have a XSL stylesheet and the browser is not set up to do anything special with that type of data. It’s normal.

IF that’s the case then the Firefox developers are regressing the browser pretty badly, since as recent as 6 months ago I have viewed RSS feeds from WordPress in Firefox and it showed the actual feed, properly displayed, NOT the raw XML code. That’s a new development, so either Firefox developers have stripped out XSL functionality, or there’s a bug in the Firefox code. Either way, this behavior is most definitely NOT normal.

Firefox never used to mishandle RSS feeds or XML in general in this way, and should not be doing so now.

I came across this issue myself while attempting to troubleshoot an issue with images not being passed through into a client’s newsletter properly and I need to be able to properly view the feed, with fully rendered XML so I can see what’s actually reaching the feed, which is much harder to do when all I can do is stare at code and not see what I need to visually.

Do you still have access to the original site at your old hosting account? If so, first go to your original WordPress and install the plugin https://www.ads-software.com/plugins/all-in-one-wp-migration/, and use the “Export” option and the plugin will backup your entire website to a single file. Then delete your buggy wordpress install, and do a clean install of wordpress on your new hosting. Next install All In One WP Migration on your new site, and use the “Import” option to import the file you created on your old host and this will automatically import your original site to your new host.

If you do run into any issues here, the most likely would be if you’re new database doesn’t use the same info as your old one and we need to manually fix your connection to your database. You’ll get errors if that happens and we can help you fix that. If not, you should be good to go.

IMPORTANT: DO NOT DELETE ANYTHING UNTIL YOU’RE SURE YOU CAN GET A BACKUP OF YOUR ORIGINAL SITE AT YOUR OLD HOSTING PROVIDER AND HAVE DONE SO.

@dragonslayerjohnson – If you go to the highest level folder with WordPress files in it, that’s where that file should be. Based on what happened when you went to https://www.Yoursite.com/wp-login.php as per t-p’s instructions, that file being missing isn’t the problem. If it was missing, you’d get a 404 not found error page.

To test if your site’s just down for you, or it’s a widespread issue, go to this site and run your website address through this test, which will let you know one way for the other: https://downforeveryoneorjustme.com/

WordPress is normally pretty easy to use, unless you run into technical difficulties.

Technology is great… when it works.

EDIT: I just tested your site and got the white screen of death. BTW, if the down for everyone site shows it is generally down, you should call your hosting provider as that would be a hosting or domain issue and you’d need them to help you get that fixed up.

• This reply was modified 6 years, 6 months ago by RadiantFreedom.

I remember having something similar happen in the GA account of a former client a couple of years ago. As I recall when investigating that, it turned out to be a form of spam, to get a link showing up in your analytic reports to the spammer’s website.

There’s another possible cause as well, which I found in this post in Stack Exchange you should also take a look at: https://webmasters.stackexchange.com/questions/79392/why-analytics-showing-non-existing-pages-in-active-pages

I recommend you follow the advice in the answers to that thread and let us know if that fixes your problem.

First step, try uninstalling wordpress, then check your server’s files, either via GoDaddy’s file manager app, or an FTP/SFTP client to make sure the folder you’re installing WordPress to is indeed empty. Then try re-installing WordPress and see if you still get this error.

If you do, then next I’d recommend calling GoDaddy support and see if they can walk you through some steps to check for any issues with your server settings that may be blocking normal WordPress operations. Also make sure you don’t have any issues with your database as well, as a database error could also be a problem, though I’d expect that to cause a different error.

Check your files in either FTP/SFTP or your host’s file manager app, and see where the images are physically located on your server if you can. If they’re in the correct locations on your server, then that means it’s probably a permalink setting by one of your image manager plugins and you may need to search for a way to fix your image permalinks.

There’s probably a plugin that could do that, but you’d have to do a little digging to find it.

That is a very unusual path for images. the path should look something like this:

https://www.mywebsite.com/wp-content/uploads/yyyy/mm/imagename.filetype

where “yyyy” is the year the image was uploaded and “mm” is the month.

It is possible one of your image plugins may be doing this, and to test that, try disabling all of them and see if your site handles images normally after that. If so, try enabling each of them 1 at a time (keeping the ones you’re not testing disabled), and check for this behaviour. If you can’t reproduce with just 1 of them active, then try with each combination of 2 active at the same time, then go back to all 3.

If, at any point, some combination of these plugins being active at the same time re-creates this behaviour take not of it and let us know what you tested and the results here.

WOW, that’s a huge menu. If you don’t get any help on that here, I recommend you try the Stack Exchange, probably either the Stack WordPress or Stack Overflow communities could give you more detailed help, as there are likely to be more php programmers there who could help you.

• This reply was modified 6 years, 6 months ago by RadiantFreedom.

“It’s nothing that would be affected by changing from http to https” Actually, that change CAN affect how a website is displayed as WordPress uses external CSS stylesheets for all themes I’m aware of. If those stylesheets are not loading correctly, it can cause the site to display incorrectly, which will cause it to display anything controlled by external CSS as browser defaults, which means black text on white background, in vertical order as presented in the HTML source code. If there is any in-line CSS or CSS embedded in the header section, for example, changing the text color to white, then this could have that affect of making parts of the site disappear as you’d have white text on a white background. I’ve had this happen before on another website due to a change from http to https. WordPress did not handle that change gracefully.

@andyj18 – I recommend you try adding the plugin https://en-ca.www.ads-software.com/plugins/really-simple-ssl/ and run it to see if that fixes this issue.

Can you try creating a new main menu and re-create your original menu manually? Shouldn’t take as much work as troubleshooting this problem and re-migrating would if that’s possible. If not, try commenting out the portion of your code that handles the menus and re-import your joomla site, then create your menu by hand, using the original site as a guide.

Fortunately, Divi should have their own customer support system you can contact for help on this issue, which I highly recommend you do, so you can explore with them if Divi (either the theme or plugin) has anything to do with your issue and get it solved if so, or rule that out.

Do you see an error page when you try to login, and if so, what error page do you see and when (before logging in or after)?

Also, while you’re in your file manage/FTP/SFTP look in the root WordPress folder of the effected website for the file “wp-login.php” if this file is missing or corrupted, it will disable all login forms and prevent access to your wordpress admin panels. If that file is missing or corrupted, you will need to re-install WordPress to get a clean copy.

Have you tried checking your server files to see if any files named after those “Junk” pages exists? It’s possible you might have some non wordpress files creating those pages, which would not show up in wordpress pages or posts listings as they’d not be in the database. Follow the paths you see in the URL in your server, using an FTP client or your host’s file manager.

If those files are non-wordpress, a standard wordfence scan would not detect them as it’s set by default to only scan wordpress files. You can also try changing the settings for your wordfence scans to scan all files and folders on your server, including non-wordpress ones, to see if it detects anything unusual that way.

EDIT: It’s possible those pages are being indexed due to that extra sitemap, which Googlebots may be using to index what pages are on your site. Try deleting the one with the erroneous data and see if that fixes the problem. It may take some time for the fix to propagate through Google as they won’t scan your site right away. You can speed this process up by creating an account with Google Webmaster Tools and choose an option in there to get Google to index your site again sooner.

If you’re using a plugin to create your sitemaps, you may want to also try disabling it and let us know which one it is so we can give you more tips on that part of it.

• This reply was modified 6 years, 6 months ago by RadiantFreedom.

I wrote the topic heading as “Bannarize” by mistake, spelling isn’t my strong suit, but I can’t find any edit buttons to fix that.