Forum Replies Created

Viewing 15 replies - 16 through 30 (of 32 total)
  • Thread Starter kw11

    (@kw11)

    That being said, the overall crawling, in terms of items crawled, is about 2-3x when phast.php is not blocked from robots. So for example, instead of 2000 documents being crawled a day, 6000 documents are being crawled a day. Googlebot crawls the phast bundler JSON files in very high volume, but is skipping out on crawling the actual page HTML on their smartphone crawler. It also seems to me that the overall crawl budget of real HTML pages is much less in Googlebot smartphone crawler with phast.php not blocked from robots.

    • This reply was modified 3 years, 9 months ago by kw11.
    Thread Starter kw11

    (@kw11)

    Thanks for doing this.

    However, on closer look, it seems that the phast.php bundler files are being crawled as HTML, which ends up significantly lowering the crawl rate for Googlebot/2.1 Smartphone of HTML pages. Desktop crawl rate is ok, which is weird.

    It seems these JSON text/plain files, which are being interpreted as text/html is what’s leading to the drop in crawl rate.

    When phast.php was inadvertently blocked from Googlebot, the overall amount of pages/files crawled was significantly less, but the crawl rate of Googlebot Smartphone was magnitudes higher.

    Whether not this is a “bug” of the Google crawler or the phast bundler, the resulting crawl rates become unacceptable. With phast bundler blocked, Googlebot can crawl the whole site in under a few days. With phast.php not inadvertently blocked from robots, it might be weeks or longer.

    • This reply was modified 3 years, 9 months ago by kw11.

    Generally, I would choose one or the other. Litespeed Cache takes more configuration.

    Thread Starter kw11

    (@kw11)

    Solved. OpenLiteSpeed has a different PHP installation. Was able install the package for PDO SQLite3.

    Thread Starter kw11

    (@kw11)

    The banner shows up. But the install button often doesn’t when clicking on the add to home screen banner.

    If I turn off Phastpress, this functionality consistently works. Different PWA plugins have this same problem and the problem is always resolved by disabling PhastPress.

    If it makes any difference, I am using Varnish caching. But I make sure to clear cache of course.

    Thread Starter kw11

    (@kw11)

    After realizing that the mobile menu depends on JavaScript quite heavily, I was wondering what it would take to load jQuery before any other scripts.

    I successfully applied phast-no-defer attributes to the jQuery and WP Mega Menu scripts but I would get errors in the JavaScript console that jQuery is trying to be called before it’s been loaded/initialized.

    How can I load jQuery before other deferred scripts? And when doing this, does this typically take a big hit in page speed scores?

    I’ll consider sharing the URL with you after I hear back about these specific issues.

    Thank you,
    Kyle

    Do you have many thousands of donors? I noticed this problem. Basically, when you have a lot of donations (typically tens of thousand or more entries), MySQL/MariaDB gets overloaded with queries.

    I think you might be able to fix this by disabling Sequential Ordering and re-importing donations. Sequential Ordering performs a query for each and every donation every time the admin dashboard is loaded.

    If this doesn’t solve it, GiveWP has a much deeper issue that will only get worse with the more donations you receive. An issue that requires code refactoring for more efficient SQL queries. I had this issue with “Pending” donations so I removed them and disabled Sequential Ordering and everything has been ok since.

    Note: I have no connection to GiveWP, just sharing my experience.

    Thread Starter kw11

    (@kw11)

    Thank you. I would like to mention that I modified this code so it’s compatible with both V2 and V3 reCAPTCHA API keys. Right now, I’m using V2 captchas because there are still some technical bugs in my site/code that I have to iron out.

    It’s worth noting that V3 reCAPTCHAs are almost invisible to the user and require no user input. There is just a small unobtrusive reCAPTCHA logo in the corner of the screen. If you weren’t looking for it, you probably wouldn’t notice.

    I can understand not liking V2 as it requires more user input, but V3 creates additional security with no real downsides.

    -Kyle

    Thread Starter kw11

    (@kw11)

    Since this post, I found there is now a link to GitHub with code for implmenting reCAPTCHA v2. I also realized that for my purposes, v2 makes the most sense since the way v3 detects bots is similar to Askimet.

    This is a good solution, but for security of your plugin, I think it makes sense that the plugin should offer reCAPTCHA protection for web and payment security.

    Perhaps by default, reCAPTCHA v2 should come with the free WordPress.org version of the plugin and v3 could be a paid add-on (I’ve seen other plugins do this). I know we aren’t supposed to talk about commercialization at WordPress.org, but my point is that reCAPTCHA should be offered by default to your free plugin to everyone to increase the security of the web. Adding such a feature can be beneficial for commercial endeavors too, if that’s what you want. There are also different implementations of v2 (checkbox and invisible).

    The code at GitHub works with the Legacy forms, but doesn’t work with the new multi-step forms. And the fact that one has to edit PHP makes it a big security problem for those who are less technically-inclined and don’t know anything about programming.

    • This reply was modified 5 years, 9 months ago by kw11.
    • This reply was modified 5 years, 9 months ago by kw11.
    Thread Starter kw11

    (@kw11)

    Also, when the database is like this, queries are extremely inefficient. The queries lock up the server in the backend.

    Queries look like this

    SELECT id FROM wp_give_sequential_ordering WHERE payment_id = '33572' LIMIT 1

    So I tried disabling sequential ordering, but same queries run with the same severe performance issues.

    • This reply was modified 5 years, 10 months ago by kw11.
    Thread Starter kw11

    (@kw11)

    I looked for errors and didn’t see any.

    When both plugins are active, Gutenberg Blocks is completely missing from the user interface. If I disable the other plugin, your plugin works as intended.

    Are you able to replicate this?

    Thread Starter kw11

    (@kw11)

    Thank you. It mostly works. But it’s not working with font awesome on one site.

    It’s either because of this file:

    <link rel="stylesheet" id="myplugin-font-awesome-css" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.11.2/css/all.css?ver=5.3.2" type="text/css" media="all">

    Or this one:

    <style media="all" data-phast-original-src="https://domain.com/wp-content/plugins/wpdiscuz/assets/third-party/font-awesome-5.0.6/css/fontawesome-all.min.css?ver=5.3.5"></style>

    The first stylesheet I programmed into a plugin I created and it conflicts. Something I have to resolve, but icons still work.

    Is it because one of those files is being hosted on CloudFlare?

    • This reply was modified 6 years, 3 months ago by kw11.
    Thread Starter kw11

    (@kw11)

    The plugin is excellent. Definitely will leave a review.

    However, the rate limiting appears to be happening because images are served as text/html instead of image/jpeg as observed in the network logs. Is this intentional?

    Also, are you willing to do create a “custom” plugin for us that removes the Phast branding from the HTML for a fee? It’s something we’re interested in.

    I think a feature some would enjoy is moving specific slugs, page IDs, and post/page types from optimizations. I am pretty technically-minded but I even have trouble figuring out the best place to stick that hook. Users less technically-inclined would have no idea where to even start.

    I know you’re trying to make a plugin that just works and doesn’t need any exclusions. And while it’s genius and 10,000x better than the popular auto-optimize, I think you can still argue that there are use cases where such exclusions are desired.

    Thank you for your reply!

    -Kyle

    • This reply was modified 6 years, 5 months ago by kw11.
    • This reply was modified 6 years, 5 months ago by kw11.
    Thread Starter kw11

    (@kw11)

    The 429 Too Many Requests errors for images looks to be caused by images being served as text/html. Is this intentional?

    Thread Starter kw11

    (@kw11)

    What’s happening is that on the server-side cached version of a products page (using WP Engine as host), your image loading implementation causes a 429 Too Many Requests error.

    On the non-cached requests, this 429 error doesn’t seem to happen.

Viewing 15 replies - 16 through 30 (of 32 total)