<div class="rss-widget"><ul><li><a class='rsswidget' href='https://ma.tt/2021/02/invest-like-the-best-and-building-worlds/' title='    On a Founder’s Field Guide episode with Patrick O’Shaughnessy we had an interesting conversation that covered a lot new ground, including an idea I’ve been playing around with on, as Patrick put it:    The idea from @photomatt that the best companies are those that build intricate worlds (in the same way that J. R. R. Tolkien came up with the elvish language) will always stick with me.     We also covered the pendulum of centralization and decentralization, current challenges facing the internet, and being a connoisseur of things overlooked. You can check out the episode on Apple, Google, Spotify, Overcast, and Pocket Casts.    I’ve been impressed by the audience of this podcast, a lot of people I admire reached out after this episode.'>Matt: Invest Like the Best and Building Worlds</a></li><li><a class='rsswidget' href='https://wptavern.com/native-lazy-loading-support-for-iframes-coming-to-wordpress-5-7?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=native-lazy-loading-support-for-iframes-coming-to-wordpress-5-7' title='Felix Arntz, a WordPress core committer and developer programs engineer at Google, announced upcoming support for lazy loading iframes. The feature is included in the latest WordPress 5.7 beta and will officially ship next month to the larger community.    WordPress has supported lazy loading for images since version 5.5. However, support for iframes was not included in the initial feature set. Browser support for iframes was widespread at the time. However, it had not yet been formalized as part of the HTML Living Standard. Soon thereafter, it was added to the HTML spec, and discussion began anew for adding support into WordPress.    Unlike images, many users are likely unaware that they are using iframes. The primary use case for iframes is with embed blocks or the auto-embed system for users who are on the classic editor. For example, whenever a user adds a YouTube video to their blog post, the underlying code outputs an iframe.    Source code of YouTube embed shows iframe.    These iframes add weight to the page size and hamper loading time.    The opposite of lazy loading is eager loading. This is the default on the web, which loads all resources in bulk. This also often leads to slow-loading webpages when they contain many images or iframes. Lazy loading only loads the image and iframe sources when they appear in a site visitor’s viewport. This speeds up the initial load time of pages.    WordPress will only add the loading=&quot;lazy&quot; attribute if an explicit width and height are set for the iframe. This is to avoid the page-shifting effect that happens when the iframe comes into view. Arntz wrote about this effect extensively when he announced support for image lazy loading. The same issue applies to iframes.    “A common user experience problem in modern websites is so-called layout shifting, often caused by slow-loading media resources like images,” he wrote. “By default, only after an image is loaded, the browser can layout the page correctly, which results in the content e.g. below the image to shift. This issue can be easily resolved by providing width and height attributes on img tags, as the browser will use them to determine the aspect ratio of the image so that it can infer the page layout ahead of actually loading the image.”    There are cases where WordPress will not add the loading attribute, even for oEmbed providers that it supports. The iframe content is not supplied by WordPress. The third-party providers create the HTML and send it back to the individual WordPress site. It is up to those third parties to follow best practices for adding width and height attributes.    “Since WordPress cannot guess the dimensions of the embedded resource, the loading=&quot;lazy&quot; attribute will only be added if the oEmbed iframe tag comes with both dimension attributes present,” wrote Arntz.    Currently, the filter applies to the post content, excerpt, and text widgets. Perhaps WordPress will extend this to comment text one day.    Potential Problems With Ads    MaAnna Stephenson, the owner of BlogAid, brought up a concern for users who display ads on their site. There may be scenarios where lazy loading is banned in advertising terms or has a technical conflict.    “Has this been tested with folks who run ads on their site using an ad agency like Mediavine and AdThrive?” she asked. “They cannot have iframes lazy loaded, as the ads use iframes and they have their own lazy load mechanism for delivery.”    The problem is that there is no ideal way to exclude every advertising service and to distinguish them from other types of iframes. From a technical standpoint, it needs to be an all-or-nothing feature.    Handling ads falls squarely into plugin territory. Arntz covered such use cases in the post. Developers can disable lazy loading for iframes wholesale or target specific iframes with basic PHP. It would only take a few lines of code to build a plugin for specific ad services.    Jeff Starr also has a plugin for disabling lazy loading altogether named Disable Lazy Load. That could serve as a stopgap solution until something more specific to users’ needs comes along.'>WPTavern: Native Lazy Loading Support for iframes Coming To WordPress 5.7</a></li><li><a class='rsswidget' href='https://wordpress.org/news/2021/02/wordpress-5-6-2-maintenance-release/' title='WordPress 5.6.2 is now available!    This maintenance release includes 5 bug fixes. These bugs affect WordPress version 5.6.1, so you’ll want to upgrade.    You can download WordPress 5.6.2 directly, or visit the Dashboard → Updates screen and click Update Now. If your sites support automatic background updates, they’ve already started the update process.    WordPress 5.6.2 is a small maintenance release focused on fixing user-facing issues discovered in 5.6.1. The next major release will be version 5.7, currently scheduled for release on March 9, 2021.    To see a full list of changes, you can browse the list on Trac, read the 5.6.2 RC1 post, or visit the 5.6.2 documentation page.    Thanks and props!    The 5.6.2 release was led by @desrosj. Special props to @isabel_brison and @talldanwp for helping to prepare the block editor related fixes, and @audrasjb and @sergeybiryukov for helping with other release related tasks.    Props to everyone who helped make WordPress 5.6.2 happen:    aaronrobertshaw, Addie, André Maneiro, archon810, Ari Stathopoulos, bartosz777, Bernhard Reiter, Daniel Richards, David Anderson, dbtedg, glendaviesnz, hmabpera, ibiza69, Isabel Brison, Jason Ryan, Jb Audras, Juliette Reinders Folmer, Kai Hao, Kerry Liu, Konrad Chmielewski, Jorge Costa, magnuswebdesign, Marius L. J., Matt Wiebe, Mukesh Panchal, Paal Joachim Romdahl, Prem Tiwari, Q, Riad Benguella, Robert Anderson, roger995, Sergey Biryukov, Sergey Yakimov, Steven Stern (sterndata), Takashi Kitajima, tonysandwich, worldedu, Yui.'>WordPress.org blog: WordPress 5.6.2 Maintenance Release</a></li><li><a class='rsswidget' href='https://wordpress.org/news/2021/02/reflecting-on-gutenbergs-100th-release/' title='1.0 to 10.0    Gutenberg 10.0 released this week, February 17, 2021, marking the 100th release of the Gutenberg plugin; the 100th release of a journey that started more than four years ago when Matt announced the project at WordCamp US 2016.     Where We Started    The past four years have not always been an easy journey. Shipping something this impactful is not easy, and there was precedent for keeping the editor as it was: WordPress had already tried to replace TinyMCE a couple of times already. What would be different this time around? The worry was “not much” and initially, very few people actively joined the project.    Six months later came WordCamp Europe 2017 and the first release of the plugin. The editor was nowhere close to being usable, but it “clicked” for some. The reactions to the presentation were hopeful, but afterward, there was a lot of pushback.    Gutenberg was (and is) an audacious project. With a project this big it attracted a lot of attention, and it became difficult to discern constructive debate from mere opposition. We each come with our context, and some people had a fixed idea about what they wanted for the project. Some wanted to reuse an existing page builder, others wanted to revive the Fields API project, some wanted it to be front-end-first, others wanted it just to replace the classic editor’s content area, some wanted it to be in Vue.JS, others wanted no change at all. With a product used by 40% of the web, you hope to find consensus, and when compromises have to be made, it can be difficult for those involved to avoid feeling that their voice is being ignored.    We have also made quite a few mistakes: stability wasn’t great in some releases, performance suffered in others, and accessibility as well. But we kept pushing forward, using feedback to improve the editor and the project in all aspects until its first inclusion in WordPress 5.0, and we’re still working to improve it today.    Where We Are    It’s a delight to see some people who strongly disagreed with the initial vision or approach to Gutenberg gradually come to enjoy using the editor and join the project to carry on its vision. Others might still not like it; some won’t ever use it. One thing is certain; we’ll continue doing our best to push forward, improve what’s already shipped, and ship new exciting features. We’ll continue making mistakes and hopefully continue learning from them.    Wednesday marked the 100th release of Gutenberg, and while that looks remarkable on the outside, the release itself holds what all the other releases did. It holds improvements to the existing features, it fixes bugs that users reported, adds new features, and it highlights experiments with new ideas.    What is remarkable about the release is the people. The ones who were with us from the start, the ones who were with us but left, the ones who joined in our journey, everyone who helped along the way, everyone who provided feedback, everyone who got their hands dirty, and everyone who tried to use this editor, extend it and provide ideas.    Thank you all.'>WordPress.org blog: Reflecting on Gutenberg’s 100th Release</a></li><li><a class='rsswidget' href='https://wptavern.com/taking-on-the-major-players-plausible-analytics-offers-an-alternative-privacy-conscious-stats-service?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=taking-on-the-major-players-plausible-analytics-offers-an-alternative-privacy-conscious-stats-service' title='Plausible Analytics is not new on the scene. The two-person, EU-based team behind the company has been trying to carve its slice of the analytics pie against players like Google Analytics and WordPress.com Stats for nearly two years.    The self-funded and bootstrapped company is starting to gain a small foothold. It has been an uphill climb to get to usage on over 10,000 websites. Now, it is reaching out directly to the WordPress community with its Plausible Analytics plugin.    “Plausible Analytics is a simple, open-source, lightweight (&lt; 1 KB), and privacy-friendly alternative to Google Analytics,” said co-founder Marko Saric. “We don’t use cookies or track any personal data, but we still aim to give you as a site owner interesting and useful insights so you can improve your efforts.”    The company’s service is built on an open-source philosophy, possibly making it an ideal partner for WordPress. The source code for the analytics service is licensed under the AGPL version 3.0 and is publicly available on GitHub.    Users have two options for running Plausible Analytics. The first route is to use the company’s cloud-based service, similar to other stats-based services. The other is to self-host the code.    For the cloud service, there is a monthly, tier-based fee. Up to 10,000 pageviews runs $6 per month. Each level increases based on the number of views a site — you can also hook up multiple sites — receives. Users can knock 33% off the price by paying yearly, which puts the starting tier at $4 per month. Plausible also offers a 30-day free trial.    “It’s definitely a challenge to go against free products and a product as dominant as Google Analytics, but it does feel like the times are changing,” said Saric. “An increasing number of people are becoming aware that free means that you may be paying with something else such as the data of your visitors in the case of Google Analytics.    “With Plausible, you own your site data. We don’t share it with any third parties, and we don’t use it for any other purpose. As we don’t make money by selling your data, we need to charge a subscription fee to pay our costs and salaries so we can continue working on the product. We have tried to keep the prices as fair and affordable as possible starting at $4/month. We do have a free as in beer self-hosted version too for those who like to manage their own server infrastructure.”    For the self-hosted version, which might appeal to the DIY crowd in the WordPress world, Plausible is designed to run via Docker. Saric said you should have a basic understanding of the command-line and networking. The server must have a CPU with x86_64 architecture and support for SSE 4.2 instructions.    “Everything else really depends on how popular your site is and how much traffic you get,” said Saric. “But you should be able to run Plausible for a site that gets tens of thousands of monthly visitors even on the lowest Digital Ocean droplet.”    As of the latest plugin release, self-hosted support is built directly into it too.    How Plausible Analytics Works    Realtime stats from Plausible Analytics.    The service is much like any other analytics product. You sign up. The site gives you a JavaScript snippet, which you place in your site’s header. Of course, this is automatically taken care of via the plugin.    The service feels much like a stepping stone between what you might get between WordPress.com Stats and Google Analytics. It is a middle ground that shows promise for a young product. However, the interface feels easier to navigate and make sense of than either service. Plausible has plenty of room for growth, which makes it promising to see what the team has accomplished at this stage.    End-users can enjoy the typical stats they are accustomed to seeing and break them down by time frame. Referrer, page, country, and device data are all there. Users can also set up goals, get email reports, and hook up to the Google Search Console.    The downside to the Plausible Analytics WordPress plugin is that it is a bit bare-bones at the moment. It is merely a settings screen and integration layer between the site and service.    Plugin settings screen.    It is missing the make-or-break feature of a built-in analytics page. Many users are accustomed to accessing their stats directly from within WordPress.    “Yes, that’s the main thing we want to fix with the WordPress plugin,” said Saric. “We’ve introduced several features to make the plugin useful for WordPress sites, such as excluding admin users from being counted by default, the option to track 404 error pages, and clicks on external links. We also have an easy way to run our script as a first-party connection from your subdomain, so you get more accurate stats compared to Google Analytics which is blocked by many browsers and extensions.”    The team is currently working on an API for Plausible and on an embedded mode. Before introducing stats into the WordPress UI, they must complete these features.    Privacy-First Solution    Website owners and visitors are becoming much more privacy-conscious than in years past. In light of the GDPR and related legislation from around the world, companies like Plausible Analytics must navigate this new landscape while still providing the data that users need.    “Plausible was built as a response to GDPR, other privacy regulations, and cultural changes over the last few years,” said Saric. “Our mission is to reduce corporate surveillance by providing an alternative web analytics tool which doesn’t come from the ad-tech world.”    Plausible Analytics does not track individuals, and its data is aggregate-only said Saric. The service also does not rely on cookies or local storage, and there is no cross-site or cross-device tracking.    “We minimize any data collection in general, and whatever we do track is kept fully secured, encrypted, and hosted on a server in the European Union to ensure it is being covered by the strict laws on data privacy,” he said. “We’re very transparent in all the data we collect. We have an in-built feature that we recommend site owners use to open up their stats to the public and share it on their site to be fully transparent so their visitors and anyone else can view the data that they have access to.”    The Future of Plausible Analytics    The team recently introduced UTM tag support and custom events, allowing users to track whatever they want. Saric said that it is now possible to follow the full journey from an ad-click all the way to conversion on users’ sites.    “The next step for the WordPress plugin is to add the default out-of-the-box integration with popular third-party plugins to support event tracking for things such as contact forms and eCommerce,” he said. “This will make it a more convenient experience for WordPress users so they can get started tracking custom events without any manual configuration being required.”    All other features are done in the open on the project’s GitHub repository and its roadmap. The plugin is also open to community involvement on a separate repo. Saric credits community member and WordPress developer Mehul Gohil with help on the plugin.'>WPTavern: Taking on the Major Players, Plausible Analytics Offers an Alternative, Privacy-Conscious Stats Service</a></li></ul></div>