Forum Replies Created

Viewing 15 replies - 1 through 15 (of 17 total)
  • Forum: Fixing WordPress
    In reply to: Publishing Failed
    bink19th

    (@bink19th)

    Also a possible solution (as the issue cropped up again in Firefox, later), is disable Cloudflare caching if your site uses that. Making this change may not be an instant fix either, as it requires DNS propagation to take place first. You may need to come back to WordPress the next day, for example.

    Forum: Fixing WordPress
    In reply to: Publishing Failed
    bink19th

    (@bink19th)

    For me, this issue seems to be the browser.

    I normally use the Brave browser, but when I started getting the “Update Failed” and “Publishing Failed” error, I tried Firefox and I didn’t get these errors anymore.

    I’m also experiencing the same issue. Accessing sermons via the archive (/sermons) works fine, but accessing them when placed on a Page as a shortcode, I get exactly the same result as @beckythomas46.

    I couldn’t find a way around this. For now, I’ve reverted back to SermonBrowser, hopefully temporarily.

    Thanks for your response @modernnerd.

    This is a fresh install of WordPress. The only other active plugin was Gutenberg, the new native WordPress text editor. I’ve tried disabling that, but no change.

    I need to keep moving on this project so I’ll be seeking alternative options.

    For others coming here for the solution, it’s actually detailed in the PDF Embedder plugin knowledgebase here:

    https://wp-pdf.com/kb/

    You will usually see this error in your browser because your PDF does not sit on the same domain as the current page on your site.

    For example, if you access the page http://www.mycompany.com/ and see the error message:
    Failed to Fetch while retrieving PDF “http://mycompany.com/wp-content/uploads/mydoc.pdf”
    this is because the shortcode for the embedded document references the URL on mycompany.com whereas the page is sitting on http://www.mycompany.com.

    The “www” is important – it references a different domain to the PDF’s URL that does not contain “www”.

    For security reasons, browsers are not allowed to load the PDF from a different domain. This error will also occur if you try to embed a PDF from another 3rd party site.

    You will need to ensure all your [pdf-embedder] shortcodes refer to the PDF’s URL in the new preferred manner.

    Sometimes, the problem might be that WordPress is configured to upload PDFs to media.mycompany.com, or something similar, perhaps due to a content-delivery plugin that is attempting to speed up your site. It may still be possible to load PDFs hosted on a different domain, at least if you have the ability to set up the configuration of that domain – see Hosting PDFs on other services such as Amazon S3.

    It is also possible that a PDF URL is being prevented from loading by a browser Ad Blocker. In the browser console, this shows up as an error net::ERR_BLOCKED_BY_CLIENT. To fix this, be sure that the PDF file name does not contain any words such as advertisement, advert, ad, click, doubleclick which are trigger words for Ad Blockers.

    For others coming here for the solution, it’s actually detailed in the PDF Embedder plugin knowledgebase here:

    https://wp-pdf.com/kb/

    You will usually see this error in your browser because your PDF does not sit on the same domain as the current page on your site.

    For example, if you access the page http://www.mycompany.com/ and see the error message:
    Failed to Fetch while retrieving PDF “http://mycompany.com/wp-content/uploads/mydoc.pdf”
    this is because the shortcode for the embedded document references the URL on mycompany.com whereas the page is sitting on http://www.mycompany.com.

    The “www” is important – it references a different domain to the PDF’s URL that does not contain “www”.

    For security reasons, browsers are not allowed to load the PDF from a different domain. This error will also occur if you try to embed a PDF from another 3rd party site.

    You will need to ensure all your [pdf-embedder] shortcodes refer to the PDF’s URL in the new preferred manner.

    Sometimes, the problem might be that WordPress is configured to upload PDFs to media.mycompany.com, or something similar, perhaps due to a content-delivery plugin that is attempting to speed up your site. It may still be possible to load PDFs hosted on a different domain, at least if you have the ability to set up the configuration of that domain – see Hosting PDFs on other services such as Amazon S3.

    It is also possible that a PDF URL is being prevented from loading by a browser Ad Blocker. In the browser console, this shows up as an error net::ERR_BLOCKED_BY_CLIENT. To fix this, be sure that the PDF file name does not contain any words such as advertisement, advert, ad, click, doubleclick which are trigger words for Ad Blockers.

    @dalecameronlowry, I see this issue was resolved. I too am now having this issue.

    Are you able to provide the solution?

    @sock2me, I see this issue was resolved. I too am now having this issue.

    Are you able to provide the solution?

    Thanks Mark, much appreciated 🙂

    Perhaps the default delete time should be one?

    A person, or a bot, could quickly establish that Backup Scheduler is installed as a plugin on a website. For example:

    http://www.[insertdomainhere].com/wp-content/plugins/backup-scheduler/readme.txt

    If I can read that file or one of the many other .txt, .png, .nfo, .css, .js files that exist in every Backup Scheduler installation, it’s a sure sign the site is using Backup Scheduler.

    The first 22 characters of the backup filename are easily predictable to the month:
    BackupScheduler_20160201021729_abcde12345.zip

    It’s not uncommon for backups to occur on the first of the month, but the date range is presumably 01 – 31:
    BackupScheduler_20160201021729_abcde12345.zip

    By default they start at midnight, but the range is presumably 00 – 23.
    BackupScheduler_20160201021729_abcde12345.zip

    May take a few minutes for a backup, so probably a low number. Range is presumably 00 – 59.
    BackupScheduler_20160201021729_abcde12345.zip

    Seconds. The range is presumably 00 – 59 also.
    BackupScheduler_20160201021729_abcde12345.zip

    Predictable underscore.
    BackupScheduler_20160201021729_abcde12345.zip

    It would not be hard for a bot to very quickly establish the filename up to this point, through a relatively small brute force test. At a rough estimate, approx 300 to 9300 attempts if defaults are used. Best case scenario for us with more random backup times and dates, up to 2678400 attempts, a figure that’s not unrealistic with bot attacks.

    So I’m not sure I feel confident considering the characters up to this point part of the random password. Certainly not the first 22. That leaves now only 10.

    The random string, vastly improves our odds. However, it too is to some extent, predictable. It’s always 10 lowercase/numerical characters. It’d take time and luck for a bot to brute force it, but I would not say it’s especially difficult. By default it has 42 days to find the file before it’s removed, or if one misunderstands the meaning of that setting like I did, they may change it to a higher number, like 365. (I thought it represented the length of time the file would stay on my FTP server.)
    BackupScheduler_20160201021729_abcde12345.zip

    I contacted Crossway support for this plugin via email, and the response I received Feb 21 2015, was that they will be working on using only HTTPS in a future update.

    For the time being, I’ve left this plugin installed but disabled, hopeful of the HTTPS update.

    With the guidance of this article, I was able to successfully display English posts by default.

    This method will supply a translated version of the post, if it exists.

    I was able to integrate this into X-Theme by copying theme-folder/framework/views/global/_index.php to the child theme and applying just some of the necesarry customisations. I’d imagine it’s fairly theme specific so I won’t post my exact code here.

    Baswazz, you’re not the only one. I too would like this feature.

    The website I’m looking after caters to 7 languages, all manually translated by teams around the world. It presently has 105 blog posts all in English and it’s not feasible to translate all of those into the 6 other languages.

    I don’t think duplicating those posts to each language and leaving it in English is a reasonable option either. That’s 630 posts, duplicates, that wouldn’t need to exist if there was a simple way to always present posts for the default language, perhaps in addition to any translated versions that may or may not exist for the active language.

    I needed to set the PHP version on the server to PHP 5.4. Higher versions than that resulted in issues with SermonBrowser.

    Source of solution:

    My apologies w9hdg. I turned on debugging in my WordPress install to try and figure out an issue I’m experiencing, and I’ve got the same error as you now.

    So it’s not an issue with the database details.

Viewing 15 replies - 1 through 15 (of 17 total)