I’ve also been having problems with our podcast. http://fbcls.church/sermons/feed/ doesn’t validate through https://validator.w3.org/feed/ or https://podba.se/validate/. Validator.org doesn’t seem to like my URLs claiming that they’re not a “full URL.” Could this be because of our .church URL as opposed to a more traditional .com or .org URL? Also, it claims “Image title doesn’t match channel title” for my logo and channel title. Does this mean that I need to change the name of the logo file?
Podbase, on the other hand, validates well except for 2 things. It takes 1.5 seconds to get the feed and my server doesn’t “support HTTP HEAD requests.” I assume that speed and HTTP HEAD requests are the fault of my hosting server.
Note that when I go to https://www.feedvalidator.org/ I get the same error message immediately without any option to test my feed’s URL. @donaldwong You might try some other validators.
Hello @donaldwong,
The issue is not with the Sermon Manager or your website, but with feedvalidator.org itself. Their website is not working at the moment.
The URL that you need to submit to iTunes is: http://www.standrews.org.hk/sermon/feed/
@asmith731,
Could this be because of our .church URL as opposed to a more traditional .com or .org URL?
We took a look at RFC 3986, and .church gTLD is completely valid. We also checked an example path that was reported by W3C as invalid – and it is valid based on RFC 3986. Not sure why W3C reports it as invalid. Anyway, it’s not something to worry about too much.
Also, it claims “Image title doesn’t match channel title” for my logo and channel title. Does this mean that I need to change the name of the logo file?
No, it’s just W3C’s recommendation, there’s no need to do anything.
I assume that speed […] are the fault of my hosting server.
Speed depends on multitude of factors, and hosting server is one of them. But 1.6 seconds is acceptable.
Regarding HTTP HEAD requests, they are the issue why your feed doesn’t work. For some reason, the server returns HTTP 500 Internal Server Error when requesting the mp3 file via HEAD request, and returns HTTP 403 Forbidden when requesting mp3 content. But, the weirdest thing is that they work when requested via browser. There’s some server misconfiguration there, and I would recommend contacting your hosting provider.
-
This reply was modified 8 years, 5 months ago by
Nikola. Reason: formatting
-
This reply was modified 8 years, 5 months ago by
Nikola. Reason: formatting
I’ve contacted my hosting company about the HTTP HEAD requests. Thanks for replying.
-
This reply was modified 8 years, 5 months ago by
asmith731.