text:
Tag: Editor

Reconciling Editor Experience and Developer Experience in the CMS

Components are great, aren’t they? They are these reusable sources of truth that you can use to build rock-solid front-ends without duplicating code.

You know what else is super cool? Headless content management! Headless content management system (CMS) products offer a content editing experience while freeing that content in the form of data that can be ported, well, to any API-consuming front-end UI. You can structure your content however you’d like (depending on the product), and pull that content into your front-end applications.

Using these two things together — a distributed CMS solution with component-based front-end applications — is a core tenet of the Jamstack.

But, while components and headless CMSs are great on their own, it can be difficult to get them to play nicely together. I‘m not saying it‘s difficult to hook one up to the other. In a lot of cases, it’s actually quite painless. But, to craft a system of components that is reusable and consistent, and to have that system maintain parity with a well-designed CMS experience is a difficult thing to achieve. It’s that win-win combo of being able to freely write content and then have that content structured into predictable components that makes headless content management so appealing.

Achieving parity between a CMS and front-end components

My favorite demonstrating this complexity is a simple component: a button. Let‘s say we’re working with React to build components and our button looks like this:

<Button to="/">Go Home</Button>

In the lovely land of React, that means the <Button> component has two props (i.e. properties, attributes, arguments, etc.) — to and children. children is a React thing that holds all the content within the opening and closing tags, which is “Go Home” in this case.)

If we’re going to enable users in the content editor to add buttons to the site, we want a system for them that makes it easy to understand how their actions in the CMS affect what appears on screen in the front-end app. But we also want our developer(s) to work productively with component properties that make sense to them and within the framework they’re working (i.e. React in our example).

How do we do that?

We could…

…use fields in the CMS that match the components’ properties, though I’ve had little success with this approach. to and children don‘t make much sense to content editors trying to build a button. Believe me, I‘ve tried. I‘ve tried with beginners and experienced editors alike. I‘ve tried helper text. It doesn’t matter. It’s confusing.

What makes more sense is using words editors are more likely to understand, like label or text for children and url for to.

Showing a mockup of CMS text input fields for a button component, one for a to field with https as a placeholder, and another for children with Buy Now as a placeholder.

Showing a mockup of CMS text input  fields for a button component, one for a URL field with https as a placeholder, and another for Button Label with Buy Now as a placeholder.

But then we’d be out of sync with our code.

Or what if we…

masked attributes in the CMS. Most headless CMS solutions enable you to have a different value for the label of the field than the name that is used when delivering content via an API.

We could label our fields Label and URL, but use children and to as the names. We could. But we probably shouldn’t. Remember what Ian Malcolm said?

On the surface, masking attributes makes sense. It’s a separation of concerns. The editors see something that makes them happy and productive, and the developers work with the names that make sense to them. I like it, but only in theory. In practice, it confuses developers. Debugging a content editor issue often requires digging through extra layers (i.e. time) to find the relationship between labels and field names.

Or why not …

…change the properties. Wouldn’t it be easier for developers to be flexible? They’re the ones designing the system, after all.

Yes, that’s true. But if you follow that rule exclusively, it’s inevitable that you’re going to run into some issue along the way. You’ll likely end up fighting against the framework, or props will just feel goofy.

In our example, using label and url as props for a button works totally fine for data that originates from the CMS. But that also means that any time our developers want to use a button within the code, it looks like this:

<Button label="Go Home" url="/" />

That may seem okay on the surface, but it significantly limits the power of the button. Let’s say I want to support some other feature, like adding an icon within the label. I’m going to need some additional logic or another property for it. If I would have used React’s children approach instead, it would have just worked (likely after some custom styling support).

Okay, so… what do we do?

Introducing transformers

The best approach I’ve found is to separately optimize the editor and developer experiences. Craft a CMS experience that is catered to the editors. Build a codebase that is easy for developers to navigate, understand, and enhance.

The result is that the two experiences will not be in parity with one another. We need some set of utilities to transform the data from the CMS structure into something that can be used by the front-end, regardless of the framework and tooling you’re using.

I call these utilities transformers. (Aren’t I so good at naming things!?) Transformers are responsible for consuming data from your CMS and transforming it into a shape that can be easily consumed by your components.

Illustration showing a rounded square that says Data Source pointing to a yellow box that says transformer, pointing to another rounded square that says component. There is a small code snippet on both sides of the yellow square showing how it transforms the Label and URL fields to Children and To, respectively.

While I‘ve found that transforming data is the smoothest means to get great experiences in both the CMS and the codebase, I don‘t have an obvious solution for how (or perhaps where) those transformations should happen. I‘ve used three different approaches, all of which have their pros and cons. Let’s take a look at them.

1. Alongside components

One approach is to put transformers right alongside the components they are serving. This is the approach I typically take in organizing component-based projects — to keep related files close to one another.

The same illustrated diagram, but the yellow box is now the button index.js file that points to a transformer.js file that then points to a button component.js file.

That means that I often have a directory for every component with a predictable set of files. The index.js acts as the controller for the component. It is responsible for importing and exporting all other relevant files. That makes it trivial to wrap the component with some logic-based behavior. In other words, it could transform properties of the component before rendering it. Here’s what that might look like for our button example:

import React from "react"  import Component from "./component" import transform from "./transformer"  const Button = props => <Component {...transform(props)} />  export default Button

The transform.js file might look like this:

export default input => {   return {     ...input,     children: input.children || input.label,     to: input.to || input.url   } }

In this example, if to and children were properties sent to the component, it works just fine! But if label and url were used instead, they are transformed to children and to. That means the <Button> component (component.js) only has to worry about using children and to.

const Button = ({ children, to }) => {children}

I personally love this approach. It keeps the logic tightly coupled with the component. The biggest downside I‘ve found thus far is that it’s a large number of files and transforms, when the entire dataset for any given page could be transformed earlier in the stack, which would be…

2. At the top of the funnel

The data has to be pulled into the application via some mechanism. Developers use this mechanism to retrieve as much data for the current page or view as possible. Often, the fewer number of queries/requests a page is required to make, the better its performance.

In other words, that mechanism often exists near the top of the funnel (or stack), as opposed to each component pulling its own data in dynamically. (When that’s necessary, I use adapters.)

Another illustration, this time where the yellow box is labeled import mechanism, and it has three arrows, each pointing to a white square, labeled, component 1, component 2, and component 3, respectively.

The mechanism that retrieves the page data could also be responsible for transforming all the data for the given page before it renders any of its components.

In theory, this is a better approach than the first one. It decreases the amount of work the browser has to do, which should improve the front-end performance. That means the server has to do more work, but that’s often a better choice.

In practice, though, this is a lot of work. Data structures can be big, complex, and interwoven. It can take a heck of a lot of work to transform everything into the right format at the top of the funnel, and then pass the transformed data down to components. It’s also more difficult to test because of the potential complexity and variation of the giant data blob retrieved at the top of the stack. With the first approach, testing the transformer logic for the button is trivial. With this approach, you’d want to account for transforming button data anywhere that it might appear in the retrieved data object.

But, if you can pull it off, this is generally the better approach.

3. The middleman engine

The third and final (and magical) approach is to do all this work somewhere else. In this case, we could build an engine (i.e. a small application) that would do the transformations for us, and then make the content available for the application to consume.

Another illustration, this time where the yellow box is the abstracted data source, which points to a white box labeled import mechanism, which then points to the same three white squares representing components that are outlined in the previous illustration.

This is likely even more work than the second approach. And it has added cost and maintenance in running an additional application, which takes more effort to ensure it is rock solid.

The major upside to this approach is that we could build this as an abstracted engine. In other words, any time we bring in data to any front-end application, it goes through this middleman engine. That means if we have two projects that use the same CMS or data source, our work is cut down significantly for the second project.

If you aren‘t doing any of this today and want to start, my advice is to treat these approaches like stepping stones. They grow in complexity and maintenance and power as the application grows. Start with the first approach and see how far that gets you. Then, if you feel like you could benefit from a jump to the second, do it! And if you’re feeling like living dangerously, go for the third!

In the end, what matters most is crafting an experience that both your editors and your developers understand and enjoy. If you can do that, you win!

The post Reconciling Editor Experience and Developer Experience in the CMS appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

, , ,

Getting the WordPress Block Editor to Look Like the Front End Design

I’m a WordPress user and, if you’re anything like me, you always have two tabs open when you edit a post: one with the new fancy pants block editor, aka Gutenberg, and another with a preview of the post so you know it won’t look wonky on the front end.

It’s no surprise that a WordPress theme’s styles only affect the front end of your website. The back end posy editor generally looks nothing like the front end result. We’re used to it. But what if I said it’s totally possible for the WordPress editor nearly mirror the front end appearance?

All it takes is a custom stylesheet.

Mind. Blown. Right? Well, maybe it’s not that mind blowing, but it may save you some time if nothing else. 🙂

WordPress gives us a hint of what’s possible here. Fire up the default Twenty Twenty theme that’s packaged with WordPress, fire up the editor, and it sports some light styling.

This whole thing consists of two pretty basic changes:

  1. A few lines of PHP in your theme’s functions.php file that tell the editor you wish to load a custom stylesheet for editor styles
  2. Said custom stylesheet

Right then, enough pre-waffle! Let’s get on with making the WordPress editor look like the front end, shall we?

Step 1: Crack open the functions.php file

OK I was lying, just a little more waffling. If you’re using a WordPress theme that you don’t develop yourself, it’s probably best that you setup a child theme before making any changes to your main theme.

Fire up your favorite text editor and open up the theme’s functions.php file that’s usually located in the root of the theme folder. Let’s drop in the following lines at the end of the file:

// Gutenberg custom stylesheet add_theme_support('editor-styles'); add_editor_style( 'style-editor.css' ); // make sure path reflects where the file is located

What this little snippet of code does is tell WordPress to add support for a custom stylesheet to be used with Gutenberg, then points to where that stylesheet (that we’re calling editor-style.css) is located. WordPress has solid documentation for the add_theme_support function if you want to dig into it a little more.

Step 2: CSS tricks (see what I did there?!)

Now we’re getting right into our wheelhouse: writing CSS!

We’ve added editor-styles support to our theme, so the next thing to do is to add the CSS goodness to the stylesheet we defined in functions.php so our styles correctly load up in Gutenberg.

There are thousands of WordPress themes out there, so I couldn’t possibly write a stylesheet that makes the editor exactly like each one. Instead, I will show you an example based off of the theme I use on my website. This should give you an idea of how to build the stylesheet for your site. I’ll also include a template at the end, which should get you started.

OK let’s create a new file called style-editor.css and place it in the root directory of the theme (or again, the child theme if you’re customizing a third-party theme).

Writing CSS for the block editor isn’t quite as simple as using standard CSS elements. For example, if we were to use the following in our editor stylesheet it wouldn’t apply the text size to
 elements in the post.

h2 {   font-size: 1.75em; }

Instead of elements, our stylesheet needs to target Block Editor blocks. This way, we know the formatting should be as accurate as possible. That means
 elements needs to be scoped to the .rich-text.block-editor-rich-text__editable class to style things up.

Showing the block editor with a light yellow background, a heading that reads Holly Dolly, and a heading 2 with DevTools open to the left in dark mode and a block-editor-rich-text-__editor class highlighted in red.
It just takes a little peek at DevTools to find a class we can latch onto.
h2.rich-text.block-editor-rich-text__editable {   font-size: 1.75em; }

I just so happened to make a baseline CSS file that styles common block editor elements following this pattern. Feel free to snag it over at GitHub and swap out the styles so they complement your theme.

I could go on building the stylesheet here, but I think the template gives you an idea of what you need to populate within your own stylesheet. A good starting point is to go through the stylesheet for your front-end and copy the elements from there, but you will likely need to change some of the element classes so that they apply to the Block Editor window.

If in doubt, play around with elements in your browser’s DevTools to work out what classes apply to which elements. The template linked above should capture most of the elements though.

The results

First of all, let’s take a look at what the WordPress editor looks like without a custom stylesheet:

Showing the WordPress block editor without any custom styling, which is a plain white screen with black text including a heading one paragraph, a blockquote and a black rounded button.
The block editor sports a clean, stark UI in its default appearance. It’s pulling in Noto Serif from Google Fonts but everything else is pretty bare bones.

Let’s compare that to the front end of my test site:

Showing a webpage with the same heading, paragraph, blockquote and button, but with styles that include a red-to-orange gradient that goes left-to-right as a background behind the white heading, a typewriter-like font, the same gradient to style the blockquote borders and text, and to style the button.

Things are pretty different, right? Here we still have a simple design, but I’m using gradients all over, to the max! There’s also a custom font, button styling, and a blockquote. Even the containers aren’t exactly square edges.

Love it or hate it, I think you will agree this is a big departure from the default Gutenberg editor UI. See why I have to have a separate tab open to preview my posts?

Now let’s load up our custom styles and check things out:

The same look as the custom styles on the front end but now displayed in the WordPress block editor.

Well would you look at that! The editor UI now looks pretty much exactly the same as the front end of my website. The content width, fonts, colors and various elements are all the same as the front end. I even have the fancy background against the post title!

Ipso facto — no more previews in another tab. Cool, huh?

Making the WordPress editor look like your front end is a nice convenience. When I’m editing a post, flipping between tabs to see what the posts looks like on the front end ruins my mojo, so I prefer not to do it.

These couple of quick steps should be able to do the same for you, too!

The post Getting the WordPress Block Editor to Look Like the Front End Design appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

, , , , , , ,

Using Markdown and Localization in the WordPress Block Editor

If we need to show documentation to the user directly in the WordPress editor, what is the best way to do it?

Since the block editor is based on React, we may be tempted to use React components and HTML code for the documentation. That is the approach I followed in my previous article, which demonstrated a way to show documentation in a modal window.

But this solution is not flawless, because adding documentation through React components and HTML code could become very verbose, not to mention difficult to maintain. For instance, the modal from the image above contains the documentation in a React component like this:

const CacheControlDescription = () => {   return (
The Cache-Control header will contain the minimum max-age value from all fields/directives involved in the request, or no-store if the max-age is 0
   ) }

Using Markdown instead of HTML can make the job easier. For instance, the documentation above could be moved out of the React component, and into a Markdown file like /docs/cache-control.md:

The Cache-Control header will contain the minimum max-age value from all fields/directives involved in the request, or `no-store` if the max-age is 0

What are the benefits and drawbacks of using Markdown compared to pure HTML?

Advantages Disadvantages
✅ Writing Markdown is easier and faster than HTML ❌ The documentation cannot contain React components
✅ The documentation can be kept separate from the block’s source code (even on a separate repo) ❌ We cannot use the __ function (which helps localize the content through .po files) to output text
✅ Copy editors can modify the documentation with no fear of breaking the code
✅ The documentation code isn’t added to the block’s JavaScript asset, which can then load faster

Concerning the drawbacks, not being able to use React components may not be a problem, at least for simple documentation. The lack of localization, however, is a major issue. Text in the React component added through the JavaScript __ function can be extracted and replaced using translations from POT files. Content in Markdown cannot access this functionality.

Supporting localization for documentation is mandatory, so we will need to make up for it. In this article we will pursue two goals:

  • Using Markdown to write documentation (displayed by a block of the WordPress editor)
  • Translating the documentation to the user’s language

Let’s start!

Loading Markdown content

Having created a Markdown file /docs/cache-control.md, we can import its content (already rendered as HTML) and inject it into the React component like this:

import CacheControlDocumentation from '../docs/cache-control.md';
 const CacheControlDescription = () => {   return (
   ); }

This solution relies on webpack, the module bundler sitting at the core of the WordPress editor.

Please notice that the WordPress editor currently uses webpack 4.42, However, the documentation shown upfront on webpack’s site corresponds to version 5 (which is still in beta). The documentation for version 4 is located at a subsite.

The content is transformed from Markdown to HTML via webpack’s loaders, for which the block needs to customize its webpack configuration, adding the rules to use markdown-loader and html-loader.

To do this, add a file, webpack.config.js, at the root of the block with this code:

// This is the default webpack configuration from Gutenberg const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
 // Customize adding the required rules for the block module.exports = {   ...defaultConfig,   module: {     ...defaultConfig.module,     rules: [       ...defaultConfig.module.rules,       {         test: /.md$ /,         use: [           {             loader: "html-loader"           },           {             loader: "markdown-loader"           }         ]       }     ],   }, };

And install the corresponding packages:

npm install --save-dev markdown-loader html-loader

Let’s apply one tiny enhancement while we’re at it. The docs folder could contain the documentation for components located anywhere in the project. To skip having to calculate the relative path from each component to that folder, we can add an alias, @docs, in webpack.config.js to resolve to folder /docs:

const path = require( 'path' ); config.resolve.alias[ '@docs' ] = path.resolve( process.cwd(), 'docs/' )

Now, the imports are simplified:

import CacheControlDocumentation from '@docs/cache-control.md';

That’s it! We can now inject documentation from external Markdown files into the React component.

Translating the documentation to the user’s language

We can’t translate strings through .po files for Markdown content, but there is an alternative: produce different Markdown files for different languages. Then, instead of having a single file (/docs/cache-control.md), we can have one file per language, each stored under the corresponding language code:

  • /docs/en/cache-control.md
  • /docs/fr/cache-control.md
  • /docs/zh/cache-control.md
  • etc.

We could also support translations for both language and region, so that American and British English can have different versions, and default to the language-only version when a translation for a region is not provided (e.g. "en_CA" is handled by "en"):

  • /docs/en_US/cache-control.md
  • /docs/en_GB/cache-control.md
  • /docs/en/cache-control.md

To simplify matters, I’ll only explain how to support different languages, without regions. But the code is pretty much the same.

The code demonstrated in this article can also be seen in the source code of a WordPress plugin I made.

Feeding the user’s language to the block

The user’s language in WordPress can be retrieved from get_locale(). Since the locale includes the language code and the region (such as "en_US"), we parse it to extract the language code by itself:

function get_locale_language(): string  {   $ localeParts = explode( '_', get_locale() );   return $ localeParts[0]; }

Through wp_localize_script(), we provide the language code to the block, as the userLang property under a global variable (which, in this case, is graphqlApiCacheControl):

// The block was registered as $ blockScriptRegistrationName wp_localize_script(   $ blockScriptRegistrationName,   'graphqlApiCacheControl',   [     'userLang' => get_locale_language(),   ] );

Now the user’s language code is available on the block:

const lang = window.graphqlApiCacheControl.userLang;

Dynamic imports

We can only know the user’s language at runtime. However, the import statement is static, not dynamic. Hence, we cannot do this:

// `lang` contains the user's language import CacheControlDocumentation from '@docs/$ { lang }/cache-control.md';

That said, webpack allows us to dynamically load modules through the import function which, by default, splits out the requested module into a separate chunk (i.e. it is not included within the main compiled build/index.js file) to be loaded lazily.

This behavior is suitable for showing documentation on a modal window, which is triggered by a user action and not loaded up front. import must receive some information on where the module is located, so this code works:

import( `@docs/$ { lang }/cache-control.md` ).then( module => {   // ... });

But this seemingly similar code does not:

const dynamicModule = `@docs/$ { lang }/cache-control.md` import( dynamicModule ).then( module => {   // ... });

The content from the file is accessible under key default of the imported object:

const cacheControlContent = import( `@docs/$ { lang }/cache-control.md` ).then( obj => obj.default )

We can generalize this logic into a function called getMarkdownContent, passing the name of the Markdown file alongside the language:

const getMarkdownContent = ( fileName, lang ) => {   return import( `@docs/$ { lang }/$ { fileName }.md` )     .then( obj => obj.default ) }

Managing the chunks

To keep the block assets organized, let’s keep the documentation chunks grouped in the /docs subfolder (to be created inside the build/ folder), and give them descriptive file names.

Then, having two docs (cache-control.md and cache-purging.md) in three languages (English, French and Mandarin Chinese), the following chunks will be produced:

  • build/docs/en-cache-control-md.js
  • build/docs/fr-cache-control-md.js
  • build/docs/zh-cache-control-md.js
  • build/docs/en-cache-purging-md.js
  • build/docs/fr-cache-purging-md.js
  • build/docs/zh-cache-purging-md.js

This is accomplished by using the magic comment /* webpackChunkName: "docs/[request]" */ just before the import argument:

const getMarkdownContent = ( fileName, lang ) => {   return import( /* webpackChunkName: "docs/[request]" */ `@docs/$ { lang }/$ { fileName }.md` )     .then(obj => obj.default) }

Setting the public path for the chunks

webpack knows where to fetch the chunks, thanks to the publicPath configuration option. If it’s not provided, the current URL from the WordPress editor, /wp-admin/, is used, producing a 404 since the chunks are located somewhere else. For my block, they are under /wp-content/plugins/graphql-api/blocks/cache-control/build/.

If the block is for our own use, we can hardcode publicPath in webpack.config.js, or provide it through an ASSET_PATH environment variable. Otherwise, we need to pass the public path to the block at runtime. To do so, we calculate the URL for the block’s build/ folder:

$ blockPublicPath = plugin_dir_url( __FILE__ ) . '/blocks/cache-control/build/';

Then we inject it to the JavaScript side by localizing the block:

// The block was registered as $ blockScriptRegistrationName wp_localize_script(     $ blockScriptRegistrationName,     'graphqlApiCacheControl',     [       //...       'publicPath' => $ blockPublicPath,     ] );

And then we provide the public path to the __webpack_public_path__ JavaScript variable:

__webpack_public_path__ = window.graphqlApiCacheControl.publicPath;

Falling back to a default language

What would happen if there is no translation for the user’s language? In that case, calling getMarkdownContent will throw an error.

For instance, when the language is set to German, the browser console will display this:

Uncaught (in promise) Error: Cannot find module './de/cache-control.md'

The solution is to catch the error and then return the content in a default language, which is always satisfied by the block:

const getMarkdownContentOrUseDefault = ( fileName, defaultLang, lang ) => {   return getMarkdownContent( fileName, lang )     .catch( err => getMarkdownContent( fileName, defaultLang ) ) }

Please notice the different behavior from coding documentation as HTML inside the React component, and as an external Markdown file, when the translation is incomplete. In the first case, if a string has been translated but another one has not (in the .po file), then the React component will end up displaying mixed languages. It’s all or nothing in the second case: either the documentation is fully translated, or it is not.

Setting the documentation into the modal

By now, we can retrieve the documentation from the Markdown file. Let’s see how to display it in the modal.

We first wrap Gutenberg’s Modal component, to inject the content as HTML:

import { Modal } from '@wordpress/components';
 const ContentModal = ( props ) => {   const { content } = props;   return (     <Modal        { ...props }     >
     </Modal>   ); };

Then we retrieve the content from the Markdown file, and pass it to the modal as a prop using a state hook called page. Dynamically loading content is an async operation, so we must also use an effect hook to perform a side effect in the component. We need to read the content from the Markdown file only once, so we pass an empty array as a second argument to useEffect (or the hook would keep getting triggered):

import { useState, useEffect } from '@wordpress/element';
 const CacheControlContentModal = ( props ) => {   const fileName = 'cache-control'   const lang = window.graphqlApiCacheControl.userLang   const defaultLang = 'en'
   const [ page, setPage ] = useState( [] );
   useEffect(() => {     getMarkdownContentOrUseDefault( fileName, defaultLang, lang ).then( value => {       setPage( value )     });   }, [] );
   return (     <ContentModal       { ...props }       content={ page }     />   ); };

Let’s see it working. Please notice how the chunk containing the documentation is loaded lazily (i.e. it’s triggered when the block is edited):

Tadaaaaaaaa 🎉

Writing documentation may not be your favorite thing in the world, but making it easy to write and maintain can help take the pain out of it.

Using Markdown instead of pure HTML is certainly one way to do that. I hope the approach we just covered not only improves your workflow, but also gives you a nice enhancement for your WordPress users.

The post Using Markdown and Localization in the WordPress Block Editor appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.

, , , , ,

Adding a Custom Welcome Guide to the WordPress Block Editor

I am creating a WordPress plugin and there is a slight learning curve when it comes to using it. I’d like to give users a primer on how to use the plugin, but I want to avoid diverting users to documentation on the plugin’s website since that takes them out of the experience.

What would be great is for users to immediately start using the plugin once it’s installed but have access to helpful tips while they are actively using it. There’s no native feature for something like this in WordPress but we can make something because WordPress is super flexible like that.

So here’s the idea. We’re going to bake documentation directly into the plugin and make it easily accessible in the block editor. This way, users get to use the plugin right away while having answers to common questions directly where they’re working.

My plugin operates through several Custom Post Types (CPT). What we’re going to build is essentially a popup modal that users get when they go to these CPTs.

The WordPress block editor is built in React, which utilizes components that can be customized to and reused for different situations.  That is the case with what we’re making — let’s call it the <Guide> component — which behaves like a modal, but is composed of several pages that the user can paginate through.

WordPress itself has a <Guide> component that displays a welcome guide when opening the block editor for the first time:

Screenshot showing a modal on top of the WordPress block editor welcoming users to the editor for the first time.
WordPress displays a modal with instructions for using the block editor when a user loads the editor for the first time.

The guide is a container filled with content that’s broken up into individual pages. In other words, it’s pretty much what we want. That means we don’t have to re-invent the wheel with this project; we can reuse this same concept for our own plugin.

Let’s do exactly that.

What we want to achieve

Before we get to the solution, let’s talk about the end goal.

The design satisfies the requirements of the plugin, which is a GraphQL server for WordPress. The plugin offers a variety of CPTs that are edited through custom blocks which, in turn, are defined through templates. There’s a grand total of two blocks: one called “GraphiQL client” to input the GraphQL query, and one called “Persisted query options” to customize the behavior of the execution.

Since creating a query for GraphQL is not a trivial task, I decided to add the guide component to the editor screen for that CPT. It’s available in the Document settings as a panel called “Welcome Guide.”

Screenshot showing the WordPress editor with the document settings panel open in the right column. a welcome guide tab is highlighted in the settings.

Crack that panel open and the user gets a link. That link is what will trigger the modal.

Close-up screenshot of the welcome guide tab opened, revealing a link that says "Open Guide: Creating Persisted Queries."

For the modal itself, I decided to display a tutorial video on using the CPT on the first page, and then describe in detail all the options available in the CPT on subsequent pages.

Screenshot showing the custom modal open in the block editor and containing an embedded video on how to use the plugin.

I believe this layout is an effective way to show documentation to the user. It is out of the way, but still conveniently close to the action. Sure, we can use a different design or even place the modal trigger somewhere else using a different component instead of repurposing <Guide>, but this is perfectly good.

Planning the implementation

The implementation comprises the following steps:

  1. Scaffolding a new script to register the custom sidebar panel
  2. Displaying the custom sidebar panel on the editor for our Custom Post Type only
  3. Creating the guide
  4. Adding content to the guide

Let’s start!

Step 1: Scaffolding the script

Starting in WordPress 5.4, we can use a component called <PluginDocumentSettingPanel> to add a panel on the editor’s Document settings like this:

const { registerPlugin } = wp.plugins; const { PluginDocumentSettingPanel } = wp.editPost;   const PluginDocumentSettingPanelDemo = () => (   <PluginDocumentSettingPanel     name="custom-panel"     title="Custom Panel"     className="custom-panel"   >     Custom Panel Contents   </PluginDocumentSettingPanel> ); registerPlugin( 'plugin-document-setting-panel-demo', {   render: PluginDocumentSettingPanelDemo,   icon: 'palmtree', } );

If you’re experienced with the block editor and already know how to execute this code, then you can skip ahead. I’ve been coding with the block editor for less than three months, and using React/npm/webpack is a new world for me — this plugin is my first project using them! I’ve found that the docs in the Gutenberg repo are not always adequate for beginners like me, and sometimes the documentation is missing altogether, so I’ve had to dig into the source code to find answers.

When the documentation for the component indicates to use that piece of code above, I don’t know what to do next, because <PluginDocumentSettingPanel> is not a block and I am unable to scaffold a new block or add the code there. Plus, we’re working with JSX, which means we need to have a JavaScript build step to compile the code.

I did, however, find the equivalent ES5 code:

var el = wp.element.createElement; var __ = wp.i18n.__; var registerPlugin = wp.plugins.registerPlugin; var PluginDocumentSettingPanel = wp.editPost.PluginDocumentSettingPanel;
 function MyDocumentSettingPlugin() {   return el(     PluginDocumentSettingPanel,     {       className: 'my-document-setting-plugin',       title: 'My Panel',     },     __( 'My Document Setting Panel' )   ); }
 registerPlugin( 'my-document-setting-plugin', {   render: MyDocumentSettingPlugin } );

ES5 code does not need be compiled, so we can load it like any other script in WordPress. But I don’t want to use that. I want the full, modern experience of ESNext and JSX.

So my thinking goes like this: I can’t use the block scaffolding tools since it’s not a block, and I don’t know how to compile the script (I’m certainly not going to set-up webpack all by myself). That means I’m stuck.

But wait! The only difference between a block and a regular script is just how they are registered in WordPress. A block is registered like this:

wp_register_script($ blockScriptName, $ blockScriptURL, $ dependencies, $ version); register_block_type('my-namespace/my-block', [   'editor_script' => $ blockScriptName, ]);

And a regular script is registered like this:

wp_register_script($ scriptName, $ scriptURL, $ dependencies, $ version); wp_enqueue_script($ scriptName);

We can use any of the block scaffolding tools to modify things then register a regular script instead of a block, which gains us access to the webpack configuration to compile the ESNext code. Those available tools are:

I chose to use the @wordpress/create-block package because it is maintained by the team developing Gutenberg.

To scaffold the block, we execute this in the command line:

npm init @wordpress/block

After completing all the prompts for information — including the block’s name, title and description — the tool will generate a single-block plugin, with an entry PHP file containing code similar to this:

/**  * Registers all block assets so that they can be enqueued through the block editor  * in the corresponding context.  *  * @see https://developer.wordpress.org/block-editor/tutorials/block-tutorial/applying-styles-with-stylesheets/  */ function my_namespace_my_block_block_init() {   $ dir = dirname( __FILE__ );
   $ script_asset_path = "$ dir/build/index.asset.php";   if ( ! file_exists( $ script_asset_path ) ) {     throw new Error(       'You need to run `npm start` or `npm run build` for the "my-namespace/my-block" block first.'     );   }   $ index_js     = 'build/index.js';   $ script_asset = require( $ script_asset_path );   wp_register_script(     'my-namespace-my-block-block-editor',     plugins_url( $ index_js, __FILE__ ),     $ script_asset['dependencies'],     $ script_asset['version']   );
   $ editor_css = 'editor.css';   wp_register_style(     'my-namespace-my-block-block-editor',     plugins_url( $ editor_css, __FILE__ ),     array(),     filemtime( "$ dir/$ editor_css" )   );
   $ style_css = 'style.css';   wp_register_style(     'my-namespace-my-block-block',     plugins_url( $ style_css, __FILE__ ),     array(),     filemtime( "$ dir/$ style_css" )   );
   register_block_type( 'my-namespace/my-block', array(     'editor_script' => 'my-namespace-my-block-block-editor',     'editor_style'  => 'my-namespace-my-block-block-editor',     'style'         => 'my-namespace-my-block-block',   ) ); } add_action( 'init', 'my_namespace_my_block_block_init' );

We can copy this code into the plugin, and modify it appropriately, converting the block into a regular script. (Note that I’m also removing the CSS files along the way, but could keep them, if needed.)

function my_script_init() {   $ dir = dirname( __FILE__ );
   $ script_asset_path = "$ dir/build/index.asset.php";   if ( ! file_exists( $ script_asset_path ) ) {     throw new Error(       'You need to run `npm start` or `npm run build` for the "my-script" script first.'     );   }   $ index_js     = 'build/index.js';   $ script_asset = require( $ script_asset_path );   wp_register_script(     'my-script',     plugins_url( $ index_js, __FILE__ ),     $ script_asset['dependencies'],     $ script_asset['version']   );   wp_enqueue_script(     'my-script'   ); } add_action( 'init', 'my_script_init' );

Let’s copy the package.json file over:

{   "name": "my-block",   "version": "0.1.0",   "description": "This is my block",   "author": "The WordPress Contributors",   "license": "GPL-2.0-or-later",   "main": "build/index.js",   "scripts": {     "build": "wp-scripts build",     "format:js": "wp-scripts format-js",     "lint:css": "wp-scripts lint-style",     "lint:js": "wp-scripts lint-js",     "start": "wp-scripts start",     "packages-update": "wp-scripts packages-update"   },   "devDependencies": {     "@wordpress/scripts": "^9.1.0"   } }

Now, we can replace the contents of file src/index.js with the ESNext code from above to register the <PluginDocumentSettingPanel> component. Upon running npm start (or npm run build for production) the code will be compiled into build/index.js.

There is a last problem to solve: the <PluginDocumentSettingPanel> component is not statically imported, but instead obtained from wp.editPost, and since wp is a global variable loaded by WordPress on runtime, this dependency is not present in index.asset.php (which is auto-generated during build). We must manually add a dependency to the wp-edit-post script when registering the script to make sure it loads before ours:

$ dependencies = array_merge(   $ script_asset['dependencies'],   [     'wp-edit-post',   ] ); wp_register_script(   'my-script',   plugins_url( $ index_js, __FILE__ ),   $ dependencies,   $ script_asset['version'] );

Now the script setup is ready!

The plugin can be updated with Gutenberg’s relentless development cycles. Run npm run packages-update to update the npm dependencies (and, consequently, the webpack configuration, which is defined on package "@wordpress/scripts") to their latest supported versions.

At this point, you might be wondering how I knew to add a dependency to the "wp-edit-post" script before our script. Well, I had to dig into Gutenberg’s source code. The documentation for <PluginDocumentSettingPanel> is somewhat incomplete, which is a perfect example of how Gutenberg’s documentation is lacking in certain places.

While digging in code and browsing documentation, I discovered a few enlightening things. For example, there are two ways to code our scripts: using either the ES5 or the ESNext syntax. ES5 doesn’t require a build process, and it references instances of code from the runtime environment, most likely through the global wp variable. For instance, the code to create an icon goes like this:

var moreIcon = wp.element.createElement( 'svg' );

ESNext relies on webpack to resolve all dependencies, which enables us to import static components. For instance, the code to create an icon would be:

import { more } from '@wordpress/icons';

This applies pretty much everywhere. However, that’s not the case for the <PluginDocumentSettingPanel> component, which references the runtime environment for ESNext:

const { PluginDocumentSettingPanel } = wp.editPost;

That’s why we have to add a dependency to the “wp-edit-post” script. That’s where the wp.editPost variable is defined.

If <PluginDocumentSettingPanel> could be directly imported, then the dependency to “wp-edit-post” would be automatically handled by the block editor through the Dependency Extraction Webpack Plugin. This plugin builds the bridge from static to runtime by creating a index.asset.php file containing all the dependencies for the runtime environment scripts, which are obtained by replacing "@wordpress/" from the package name with "wp-". Hence, the "@wordpress/edit-post" package  becomes the "wp-edit-post" runtime script. That’s how I figured out which script to add the dependency.

Step 2: Blacklisting the custom sidebar panel on all other CPTs

The panel will display documentation for a specific CPT, so it must be registered only to that CPT. That means we need to blacklist it from appearing on any other post types.

Ryan Welcher (who created the <PluginDocumentSettingPanel> component) describes this process when registering the panel:

const { registerPlugin } = wp.plugins; const { PluginDocumentSettingPanel } = wp.editPost const { withSelect } = wp.data;
 const MyCustomSideBarPanel = ( { postType } ) => {
   if ( 'post-type-name' !== postType ) {     return null;   }
   return(     <PluginDocumentSettingPanel       name="my-custom-panel"       title="My Custom Panel"     >       Hello, World!     </PluginDocumentSettingPanel>   ); }
 const CustomSideBarPanelwithSelect = withSelect( select => {   return {     postType: select( 'core/editor' ).getCurrentPostType(),   }; } )( MyCustomSideBarPanel);

 registerPlugin( 'my-custom-panel', { render: CustomSideBarPanelwithSelect } );

He also suggests an alternative solution, using useSelect instead of withSelect.

That said, I’m not totally convinced by this solution, because the JavaScript file must still be loaded, even if it isn’t needed, forcing the website to take a performance hit. Doesn’t it make more sense to not register the JavaScript file than it does to run JavaScript just to disable JavaScript?

I have created a PHP solution. I’ll admit that it feels a bit hacky, but it works well. First, we find out which post type is related to the object being created or edited:

function get_editing_post_type(): ?string {   if (!is_admin()) {     return null;   }
   global $ pagenow;   $ typenow = '';   if ( 'post-new.php' === $ pagenow ) {     if ( isset( $ _REQUEST['post_type'] ) && post_type_exists( $ _REQUEST['post_type'] ) ) {       $ typenow = $ _REQUEST['post_type'];     };   } elseif ( 'post.php' === $ pagenow ) {     if ( isset( $ _GET['post'] ) && isset( $ _POST['post_ID'] ) && (int) $ _GET['post'] !== (int) $ _POST['post_ID'] ) {       // Do nothing     } elseif ( isset( $ _GET['post'] ) ) {       $ post_id = (int) $ _GET['post'];     } elseif ( isset( $ _POST['post_ID'] ) ) {       $ post_id = (int) $ _POST['post_ID'];     }     if ( $ post_id ) {       $ post = get_post( $ post_id );       $ typenow = $ post->post_type;     }   }   return $ typenow; }

Then, ,we register the script only if it matches our CPT:

add_action('init', 'maybe_register_script'); function maybe_register_script() {   // Check if this is the intended custom post type   if (get_editing_post_type() != 'my-custom-post-type') {     return;   }
   // Only then register the block   wp_register_script(...);   wp_enqueue_script(...); }

Check out this post for a deeper dive on how this works.

Step 3: Creating the custom guide

I designed the functionality for my plugin’s guide based on the WordPress <Guide> component. I didn’t realize I’d be doing that at first, so here’s how I was able to figure that out.

  1. Search the source code to see how it was done there.
  2. Explore the catalogue of all available components in Gutenberg’s Storybook.

First, I copied content from the block editor modal and did a basic search. The results pointed me to this file. From there I discovered the component is called <Guide> and could simply copy and paste its code to my plugin as a base for my own guide.

Then I looked for the component’s documentation. I browsed the @wordpress/components package (which, as you may have guessed, is where components are implemented) and found the component’s README file. That gave me all the information I needed to implement my own custom guide component.

I also explored the catalogue of all the available components in Gutenberg’s Storybook (which actually shows that these components can be used outside the context of WordPress). Clicking on all of them, I finally discovered <Guide>. The storybook provides the source code for several examples (or stories). It’s a handy resource for understanding how to customize a component through props.

At this point, I knew <Guide> would make a solid base for my component. There is one missing element, though: how to trigger the guide on click. I had to rack my brain for this one!

This is a button with a listener that opens the modal on click:

import { useState } from '@wordpress/element'; import { Button } from '@wordpress/components'; import { __ } from '@wordpress/i18n'; import MyGuide from './guide';
 const MyGuideWithButton = ( props ) => {   const [ isOpen, setOpen ] = useState( false );   return (     <>       <Button onClick={ () => setOpen( true ) }>         { __('Open Guide: “Creating Persisted Queries”') }       </Button>       { isOpen && (         <MyGuide            { ...props }           onFinish={ () => setOpen( false ) }         />       ) }     </>   ); }; export default MyGuideWithButton;

Even though the block editor tries to hide it, we are operating within React. Until now, we’ve been dealing with JSX and components. But now we need the useState hook, which is specific to React.

I’d say that having a good grasp of React is required if you want to master the WordPress block editor. There is no way around it.

Step 4: Adding content to the guide

We’re almost there! Let’s create the <Guide> component, containing a <GuidePage> component for each page of content.

The content can use HTML, include other components, and whatnot. In this particular case, I have added three <GuidePage> instances for my CPT just using HTML. The first page includes a video tutorial and the next two pages contain detailed instructions.

import { Guide, GuidePage } from '@wordpress/components'; import { __ } from '@wordpress/i18n';
 const MyGuide = ( props ) => {   return (     <Guide { ...props } >       <GuidePage>         <video width="640" height="400" controls>           <source src="https://d1c2lqfn9an7pb.cloudfront.net/presentations/graphql-api/videos/graphql-api-creating-persisted-query.mov" type="video/mp4" />           { __('Your browser does not support the video tag.') }         </video>         // etc.       </GuidePage>       <GuidePage>         // ...       </GuidePage>       <GuidePage>         // ...       </GuidePage>     </Guide>   ) } export default MyGuide;
imaged gif showing the mouse cursor clicking on the Open Guide link in the block editor's document settings, which opens the custom welcome guide containing a video with links to other pages in the modal.
Hey look, we have our own guide now!

Not bad! There are a few issues, though:

  • I couldn’t embed the video inside the <Guide> because clicking the play button closes the guide. I assume that’s because the  falls outside the boundaries of the guide. I wound up uploading the video file to S3 and serving with <video>.
  • The page transition in the guide is not very smooth. The block editor’s modal looks alright because all pages have a similar height, but the transition in this one is pretty abrupt.
  • The hover effect on buttons could be improved. Hopefully, the Gutenberg team needs to fix this for their own purposes, because my CSS aren’t there. It’s not that my skills are bad; they are nonexistent.

But I can live with these issues. Functionality-wise, I’ve achieved what I need the guide to do.

Bonus: Opening docs independently

For our <Guide>, we created the content of each <GuidePage> component directly using HTML. However, if this HTML code is instead added through an autonomous component, then it can be reused for other user interactions.

For instance, the component <CacheControlDescription> displays a description concerning HTTP caching:

const CacheControlDescription = () => {   return (
The Cache-Control header will contain the minimum max-age value from all fields/directives involved in the request, or "no-store" if the max-age is 0
   ) } export default CacheControlDescription;

This component can be added inside a <GuidePage> as we did before, but also within a <Modal> component:

import { useState } from '@wordpress/element'; import { Button } from '@wordpress/components'; import { __ } from '@wordpress/i18n'; import CacheControlDescription from './cache-control-desc';
 const CacheControlModalWithButton = ( props ) => {   const [ isOpen, setOpen ] = useState( false );   return (     <>       <Button          icon="editor-help"         onClick={ () => setOpen( true ) }       />       { isOpen && (         <Modal            { ...props }           onRequestClose={ () => setOpen( false ) }         >           <CacheControlDescription />         </Modal>       ) }     </>   ); }; export default CacheControlModalWithButton;

To provide a good user experience, we can offer to show the documentation only when the user is interacting with the block. For that, we show or hide the button depending on the value of isSelected:

import { __ } from '@wordpress/i18n'; import CacheControlModalWithButton from './modal-with-btn';
 const CacheControlHeader = ( props ) => {   const { isSelected } = props;   return (     <>       { __('Cache-Control max-age') }       { isSelected && (         <CacheControlModalWithButton />       ) }     </>   ); } export default CacheControlHeader;

Finally, the <CacheControlHeader> component is added to the appropriate control.

Animated gif showing the option to view a guide displaying when a block is selected in the editor.

Tadaaaaaaaa 🎉

The WordPress block editor is quite a piece of software! I was able to accomplish things with it that I would have been unable to without it. Providing documentation to the user may not be the shiniest of examples or use cases, but it’s a very practical one and something that’s relevant for many other plugins. Want to use it for your own plugin? Go for it!

The post Adding a Custom Welcome Guide to the WordPress Block Editor appeared first on CSS-Tricks.

, , , , , ,

How to Create Custom WordPress Editor Blocks in 2020

Peter Tasker on creating blocks right now:

It’s fairly straightforward these days to get set up with the WP CLI ‘scaffold’ command. This command will set up a WordPress theme or plugin with a ‘blocks’ folder that contains the PHP and base CSS and JavaScript required to create a custom block. The only drawback that I noticed is that the JavaScript uses the old ES5 syntax rather than modern ESNext. Modern JavaScript allows us to write more concise code and use JSX in our custom block code.

You can also use the ‘create-guten-block’ tool by Ahmad Awais. It gives you a lot of the boilerplate stuff you need out of the box, like Webpack, ESNext support etc. Setting it up is fairly straightforward, and it’s similar to Create React App.

I’ve used create-guten-block for the handful of custom blocks I’ve made so far, and have found it a pretty nice experience.

But… I feel like I just sort of lucked into being comfortable with all this. I have one foot in WordPress development and just so happen to have one foot in React development. Building blocks with both technologies together feels decently natural to me. If blocks were Angular or something, I feel like I might not have even given it a shot.

I’ll echo this sentiment:

I also found it really annoying working on a block that’s actively changing in code. Every time you reload Gutenberg, you’ll get the “This block appears to have been modified externally…” message because the markup of the block has changed.

I get why it’s throwing the error, but it slows you down.

At the end, Peter mentions the approach of building blocks that Advanced Custom Fields has. It almost feels like a weird bizarro-reverso world. The ACF approach seems more like what WordPress would have done in a normal world (building blocks with just PHP and templating) and third-parties would be the ones adding all the fancy React stuff.

Direct Link to ArticlePermalink

The post How to Create Custom WordPress Editor Blocks in 2020 appeared first on CSS-Tricks.

, , , , ,

8 Little Videos About the Firefox Shape Path Editor

It sometimes takes a quick 35 seconds for a concept to really sink in. Mikael Ainalem delivers that here, in the case that you haven’t quite grokked the concepts behind path-based CSS properties like clip-path and shape-outside.

Here are two of my favorites. The first demonstrates animating text into view using a polygon as a clip.

The second shows how the editor can help morph one shape into another.

Direct Link to ArticlePermalink

The post 8 Little Videos About the Firefox Shape Path Editor appeared first on CSS-Tricks.

, , , , , ,


Content-Type: application/http; msgtype=response

WARC-Identified-Payload-Type: text/html

WARC-Type: response

text:
Global Residential Mortgage Loan Market 2020 Evolving Opportunities, Trends, Industry Outline and Future Growth, Forecast 2025 By Top Players- Wells Fargo, Caliber Home Loans, Bank of America

A new research study has been presented by ORBIS RESEARCH after a comprehensive analysis on Global Residential Mortgage Loan Market where user can get benefits from the complete market research report with all required useful information on Global Residential Mortgage Loan market. Report discuss all major market aspects with expert opinion on current market status along with historic data as well. Global Residential Mortgage Loan Market is a detailed study on growth, investment opportunities, market statistics, growing competition analysis, major key players, industry facts, all important figures, Sales, Price, Revenue, Gross Margin, Market Share, business strategies, top regions with demand and developments.

The report is so designed, as to meet the reader curiosity, presenting answers to some of the most vital questions prevalent in the Global Residential Mortgage Loan Market that have a lingering impact on holistic growth trail.

The report is mindfully structured in a top bottom format and addresses the various matrices such as opportunity assessment, challenge analysis, significant drivers and the like that lead towards a fulfilling growth trail in the Global Residential Mortgage Loan Market.

Get a sample of the report @

The report is designed in a chapter-wise presentation for superlative ease, also effectively drawing hints at the demand and supply trends prevalent, presenting the same as graphical representation wo align with reader discretion.

The discussed Global Residential Mortgage Loan Market has been valued at xx million US dollars in 2020 and is further projected to grow at xx million US dollars through the forecast span till 2025, growing at a CAGR of xx% through the forecast period.

The Major Players Covered in Residential Mortgage Loan Market are:
Wells Fargo, Caliber Home Loans, Bank of America, Quicken Loans, U.S. Bank, JPMorgan Chase, Flagstar Bank, LoanDepot, United Wholesale Mortgage, Fairway Independent Mortgage, HSBC, Deutsche Bank, Industrial and Commercial Bank of China, Japan Post Bank, BNP Paribas, Bank of China, China Construction Bank Corp, Mitsubishi UFJ Financial Group, Crédit Agricole, Agricultural Bank of China, Mizuho Financial Group, Sumitomo Mitsui Financial Group, etc.

Global Residential Mortgage Loan Market By Type:

Breakdown by Type, Residential Mortgage Loan market has been segmented into Residential, Commercial Estate, etc.

Global Residential Mortgage Loan Market By Application:

New House
Second-hand House

The report offers in-depth assessment of the growth and other aspects of the Residential Mortgage Loan market in important countries (regions), including:
North America (United States, Canada and Mexico)
Europe (Germany, France, UK, Russia and Italy)
Asia-Pacific (China, Japan, Korea, India, Southeast Asia and Australia)
South America (Brazil, Argentina, Colombia)
Middle East and Africa (Saudi Arabia, UAE, Egypt, Nigeria and South Africa)

Read complete report @

Understanding COVID-19 Impact

  • This dedicated section on COVID-19 analysis therefore is compiled to aid wise business discretion, enabling market players in Global Residential Mortgage Loan Market to direct remunerative business strategies, offsetting devastating impact of the COVID-19 pandemic.
  • The sudden breakout of the COVID-19 pandemic has wrecked a devastating impact on business developments and normal functionality pushing the global economy towards an abrupt standstill, thus resulting in a catastrophic devastation.
  • This report therefore is designed to address all significant alterations triggered by the pandemic and assesses the damage that is caused by the same.
  • This elaborately compiled research output on the Global Residential Mortgage Loan Market has been designed bearing in mind a systematic approach to identify, assess and address the core dynamics in the market that result in uncompromised growth trail.

Investing in the Report: Know Why

  • This report aims to holistically portray and categorize the Global Residential Mortgage Loan Market for unmatched reader understanding
  • A detailed estimation to inspect material foundations and downstream procurement developments are resonated in the report
  • Profligate references on purchaser needs, barrier analysis and opportunity valuation are also entrenched
  • The report surveys and makes optimal forecast pertaining to market volume and value approximation

For Enquiry before buying report @

Global Residential Mortgage Loan Market Dynamics

  • Drivers: Prevalent across both matured economies and developing regions alike
  • Barriers: A touchpoint featuring the core difficulties, threats and challenges experienced by market participants, also addressing threat probability
  • Opportunities: Briefly touching on consumption and production developments, competition intensity as well as growth rate across countries and regions.

About Us:
Orbis Research ( is a single point aid for all your market research requirements. We have vast database of reports from the leading publishers and authors across the globe. We specialize in delivering customized reports as per the requirements of our clients. We have complete information about our publishers and hence are sure about the accuracy of the industries and verticals of their specialization. This helps our clients to map their needs and we produce the perfect required market research study for our clients.

Contact Us:
Hector Costello
Senior Manager Client Engagements
4144N Central Expressway,
Suite 600, Dallas,
Texas 75204, U.S.A.
Phone No.: USA: +1 (972)-362-8199 | IND: +91 895 659 5155

warcinfo:
isPartOf: CC-MAIN-2021-21
publisher: Common Crawl
description: Wide crawl of the web for May 2021
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-81.ec2.internal
software: Apache Nutch 1.18 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.2-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/


text:
Anonymous Notice | Note by H.P.B.

Mrs. Anandabai Joshi, F.T.S., the well-known Mahratta Brahmin lady, sailed yesterday by S.S. City of Calcutta for New York. She goes to America with the object of studying medicine. We hope that profiting by the grand privileges and facilities afforded to women in America, our brave sister may achieve there the greatest success. May she return from that ocean of freedom an M.D., having meanwhile avoided its two most prominent sandbanks: The Women’s Right Society and the Young Men’s Christian Association, both of which classes, like the roaring lion in the desert seeking whom he may devour, are ever on the watch to entice at their arrival the innocent and the unsuspecting. Noticing her departure, our contemporary of Lahore, The Tribune, makes the following extremely just remarks upon our courageous young sister:

“Mrs. Anandabay Joshi, the well-known Mahratta lady, who was the other day lecturing at the Serampore College, in Bengal, so eloquently in English, sailed on Friday before the last, by one of the City Line Steamers for New York on her intended visit and stay there to study medicine. Besides being well-educated this Native lady is possessed of no ordinary amount of moral courage. She is not a Christian convert, as many of us may suppose, but a married Hindu lady whose husband is still living. But she goes alone beyond the seas on her mission, while her husband remains at home, being the only stay and support of his parents. Such courage is but very rare, considering that her mission is to remove a national want—that of Hindu lady doctors—and the sacrifices are almost dreadful to think of. Not a whit less, or perhaps more, than that of Pundita Rama Bai, her earnestness in such a patriotic cause should, it is to be hoped, commend itself strongly to the liberalism and conscientiousness of her fellow countrymen and society that she may not be declared an outcast by them at her return. Backward Punjab, alas, has not got one single member of her sex who is capable of even sympathizing with her object as, we believe, many of her own Presidency will! So, while we sincerely wish her every success, we venture to think, that some of her sisters of her own Presidency, Mahratta and Parsee, who are farther advanced in education and enlightenment than the most proficient better-half of the young Bengal, admittedly foremost in the ranks of educated India, will follow suit—and that, the sooner the better.”

It is with a well-warranted pride that we say here that this act of courage—which can hardly be appreciated by Western people unacquainted with the merciless caste system and Zenana rules of India—is very much due to the influence of Mrs. Joshi’s husband, one of the most liberal-minded and intellectual Brahmins we know of, as one of the best friends and members of our society. We are proud indeed at the thought, that the first Brahmin lady, who thus becomes practically the pioneer of the great national movement now stirring public opinion in favour of the education and certain legitimate rights for the women of India—is a Fellow of our society. We cannot recommend her too warmly to the sympathies and best fraternal feelings of all our American Theosophists, and hope and pray that they should render the poor and brave young exile every service, and help her as much as it is within their power.—Ed. Note [H.P.B.]


text:
Google does not use the keywords meta tag in web ranking

Monday, September 21, 2009

Recently we received some questions about how Google uses (or more accurately, doesn't use) the keywords meta tag in ranking web search results. Suppose you have two website owners, Alice and Bob. Alice runs a company called AliceCo and Bob runs BobCo. One day while looking at Bob's site, Alice notices that Bob has copied some of the words that she uses in her keywords meta tag. Even more interesting, Bob has added the words "AliceCo" to his keywords meta tag. Should Alice be concerned?

At least for Google's web search results currently (September 2009), the answer is no. Google doesn't use the keywords meta tag in our web search ranking. This video explains more, or see the questions below.

Does Google ever use the keywords meta tag in its web search ranking?

In a word, no. Google does sell a Google Search Appliance, and that product has the ability to match meta tags, which could include the keywords meta tag. But that's an enterprise search appliance that is completely separate from our main web search. Our web search (the well-known search at that hundreds of millions of people use each day) disregards keyword metatags completely. They simply don't have any effect in our search ranking at present.

Why doesn't Google use the keywords meta tag?

About a decade ago, search engines judged pages only on the content of web pages, not any so-called "off-page" factors such as the links pointing to a web page. In those days, keyword meta tags quickly became an area where someone could stuff often-irrelevant keywords without typical visitors ever seeing those keywords. Because the keywords meta tag was so often abused, many years ago Google began disregarding the keywords meta tag.

Does this mean that Google ignores all meta tags?

No, Google does support several other meta tags. This meta tags page documents more info on several meta tags that we do use. For example, we do sometimes use the description meta tag as the text for our search results snippets, as this screenshot shows:

Even though we sometimes use the description meta tag for the snippets we show, we still don't use the description meta tag in our ranking.

Does this mean that Google will always ignore the keywords meta tag?

It's possible that Google could use this information in the future, but it's unlikely. Google has ignored the keywords meta tag for years and currently we see no need to change that policy.


text:
Deprecations and removals in Chrome 63

In nearly every version of Chrome, we see a significant number of updates and improvements to the product, its performance, and also capabilities of the Web Platform. This article describes some of the deprecations and removals in Chrome 63, which is in beta as of October 26. Visit the deprecations page for more deprecations and removals from this and previous versions of Chrome. This list is subject to change at any time.

Interface properties with a Promise type no longer throw exceptions

Interface properties and functions that return a promise have been inconsistent about whether error conditions throw exceptions or reject, which would invoke a promise's catch() block. The current version of the IDL spec calls for all promise-returning properties and functions to reject rather than throw an exception.

For example, previously, a call to MediaKeySession.closed would throw a TypeError for illegal invocation if called at the wrong time. With this change such calls must now implement a catch() block.

This change brings Chrome inline with the specification. This change has already been made for functions.

Chromestatus Tracker | Chromium Bug

Remove getMatchedCSSRules()

The getMatchedCSSRules() method is a webkit-only API to get a list of all the style rules applied to a particular element. Webkit has an open bug to remove it. For these reasons it is removed from Chrome in version 63. Developers who need this functionality can look at this Stackoverflow post

Intent to Remove | Chromestatus Tracker | Chromium Bug

Remove RTCRtcpMuxPolicy of "negotiate"

The rtcpMuxPolicy is used by Chrome to specify its preferred policy regarding use of RTP/RTCP multiplexing. In Chrome 57, we changed the default rtcpMuxPolicy to "require" and deprecated "negotiate" for following reasons:

  • Non-muxed RTCP uses extra network resources.
  • Removing "negotiate" will make the API surface simpler, since an "RtpSender"/"RtpReceiver" will then only ever have a single transport.

In Chrome 63, "negotiate" is removed.

Intent to Deprecate | Chromium Bug

Deprecation policy

To keep the platform healthy, we sometimes remove APIs from the Web Platform which have run their course. There can be many reasons why we would remove an API, such as:

  • They are superseded by newer APIs.
  • They are updated to reflect changes to specifications to bring alignment and consistency with other browsers.
  • They are early experiments that never came to fruition in other browsers and thus can increase the burden of support for web developers.

Some of these changes will have an effect on a very small number of sites. To mitigate issues ahead of time, we try to give developers advanced notice so they can make the required changes to keep their sites running.

Chrome currently has a process for deprecations and removals of API's, essentially:

  • Announce on the blink-dev mailing list.
  • Set warnings and give time scales in the Chrome DevTools Console when usage is detected on the page.
  • Wait, monitor, and then remove the feature as usage drops.

You can find a list of all deprecated features on using the deprecated filter and removed features by applying the removed filter. We will also try to summarize some of the changes, reasoning, and migration paths in these posts.


text:
Best Natural Treats For Small Pets

Oxbow Animal Health® Simple Rewards Strawberry Treats (0.5 Oz)

Regular price
Sale price
Shipping calculated at checkout.
Quantity must be 1 or more

Why mess with nature’s perfection? Oxbow’s Simple Rewards Strawberry Treats consist of only 100% strawberries, harvested and freeze-dried at the peak of ripeness to ensure the freshest, best-tasting treat for your special pet. Rabbits, guinea pigs, chinchillas, and other small animals love these tasty treats, and you'll love the feeling of providing a reward that contains no additives, preservatives, or added sugar. Simple Rewards Strawberry Treats are a natural source of vitamin C and contain natural antioxidants. Use Oxbow’s all-natural Strawberry Treats to add variety and enrichment to your pet’s diet.


text:
September 3 – Father

Hear, my sons, the instruction of a father, and pay attention in order to gain and to know intelligent discernment comprehension, and interpretation [of spiritual matters]. Proverbs 4:1

The word father should bring a smile to every one of our faces. God intended every child to know the affirmation, acceptance and approval of their daddy.

And as the years go by, the father epidemic grows…because the fatherless don’t know how to be fathers.

So how in the world can we ever feel loved or led by the Father of fathers… God?

I have given my life to the idea of family because that is all I ever wanted growing up.  And when things happened I didn’t understand at my house, I blamed myself, then I blamed God.

But thankfully, God wasn’t offended with me, so when life started to get real scary and I had nowhere else to turn, I cried out for help.

As a broken man, I began to learn that He (God) wasn’t responsible for all the mistakes that were made in my house. He loved me, my momma, and my daddy even when we didn’t do everything right.  But the devil, fleshly  desires, and sinful behaviors can get to the best of us. And that is why the last thing we should ever do is run from our Father…yet we do.

And because He is a good Father, he doesn’t force His will or way on us and He won’t defend Himself when we play the blame game.

But when, and if, we ever put our fists down, stop the name calling, and ask for help…He will draw near, hug us and began to reveal the truth about the situations we face.

I don’t know what your daddy did or didn’t do. Nor would I dare judge how good a daddy you’ve been to your kiddos. But what I do know is if you and I want to heal or be a source of healing, we’ve got to let Daddy God love on us. Then He can lead us down that often broken road to a better place not only for us, but the generations to come.


text:
Verse of the day — Philippians 2:21

For they all seek after their own interests, not those of Christ Jesus.

Philippians 2:21(NASB)
Open Windows by T. Austin-Sparks

His Thoughts

The leading priests and the teachers of religious law saw these wonderful miracles and heard even the children in the Temple shouting, "Praise God for the Son of David." But the leaders were indignant. (Matthew 21:15 NLT)

From the Mount of Olives He went, and in that meek and lowly way presented Himself as King. The fickle multitude, of course, jumped at earthly possibilities, and again the disciples are all in it. But when you get to Matthew 21:15, you get to the true situation in Israel among the Jews, and it will be found that even the fickle multitude will come to that presently when they discover that He did not mean a temporal, political kingdom at all. And when all that prospect seems to be more than doubtful, the crowd will join the ruler cry, way with Him!The real thing deep down behind is in verse 15: the positive antagonism towards Him; no desire to have Him, of course stimulated by envy and jealousy. The place where it was really drawn out as to what people wanted was the Mount of Olives....

Really their thoughts and His are very far apart, and that becomes very clear in the end. The Mount of Olives first of all gets down into the truth as to what people are after. You never know the truth about a situation. It may look all right, it may seem to be quite favorable, but in fact it may be all wrong, false, and untrue. You never know until you obtain the heavenly position of higher ground, and then from that higher ground you can see the truth about things. That works in principle; that works in history. If you present the high ground of God full thought for His people and the hearts of the people are really set upon having a work for God down here that is flourishing and prosperous and well-spoken of, you find that people are really, after all, only going with Him so long as He comes into line with their ideas and ambitions. But immediately that runs counter to thoughts more earthly, thoughts even in relation to Him, something deeper rises up. They are not going to have that. You have seen that many times; you must not touch their things. They say it is for the Lord, but you must not touch it; it is their own. If you are not coming to help their thing or things with your ministry or presentation, of course they won have it, and it resolves itself into this: they won have Him; that is not the kind of Lord they want. They want a Lord who is going to make their thing for Him successful down here. You can only know and discriminate between the true and the false when you yourself are on the higher ground.

Bible verses: Matthew 21:15
Morning Daily Light by Samuel Bagster

You have been weighed in the balances, and found wanting.

The Lord is the God of knowledge; and by Him actions are weighed. § What is highly esteemed among men is an abomination in the sight of God. § The Lord does not see as man sees; for man looks at the outward appearance, but the Lord looks at the heart. § Do not be deceived, God is not mocked; for whatever a man sows, that he will also reap. For he who sows to his flesh will of the flesh reap corruption, but he who sows to the Spirit will of the Spirit reap everlasting life.

What profit is it to a man if he gains the whole world, and loses his own soul? Or what will a man give in exchange for his soul? § What things were gain to me, these I have counted loss for Christ.

Behold, You desire truth in the inward parts. § You have tested my heart; You have visited me in the night; You have tried me and have found nothing.

Dan. 5:27;  1 Sam. 2:3 ; Luke 16:15;  1 Sam. 16:7;  Gal. 6:7,8;  Matt. 16:26;  Phil. 3:7;  Ps. 51:6;  Ps. 17:3
Evening Daily Light by Samuel Bagster

Christ the firstfruits.

Unless a grain of wheat falls into the ground and dies, it remains alone; but if it dies, it produces much grain. § If the firstfruit is holy, the lump is also holy; and if the root is holy, so are the branches. § Now Christ is risen from the dead, and has become the firstfruits of those who have fallen asleep. § If we have been united together in the likeness of His death, certainly we also shall be in the likeness of His resurrection. § The Lord Jesus Christ … will transform our lowly body that it may be conformed to His glorious body, according to the working by which He is able even to subdue all things to Himself.

The firstborn from the dead. § If the Spirit of Him who raised Jesus from the dead dwells in you, He who raised Christ from the dead will also give life to your mortal bodies through His Spirit who dwells in you.

I am the resurrection and the life. He who believes in Me, though he may die, he shall live.

1 Cor. 15:23;  John 12:24;  Rom. 11:16;  1 Cor. 15:20;  Rom. 6:5;  Phil. 3:20,21;  Col. 1:18;  Rom. 8:11;  John 11:25
None but the Hungry Heart by Miles Stanford

Sans Effort

To him that worketh not, but believeth on Him that justifieth the ungodly, his faith is counted for righteousness" (Rom. 4:5).

There is no work involved in our receiving the Lord Jesus for life, and there should certainly be no self-effort involved in the manifestation of His life in and through us. The principle is the same, from re-birth to maturity.

˜Thanks be to God, who giveth us the victory through our Lord Jesus Christ' (1 Cor. 15:57). That is grace. That is the test of the real or the counterfeit. Just remember this: any victory over the power of any sin whatsoever that you have to get by working for it is counterfeit. Any victory that you have to get by trying for it is false. If you have to work for your freedom, it is not the real thing, it is not that which the Father offers you in His Son."

"The effortless life is not the will-less life. We use our will to believe, or receive, but not to exert effort in trying to accomplish what only the Father has done. Our hope for freedom from the power of sin is not Christ plus my efforts,' but Christ plus my receiving.' To receive victory from Him is to believe His Word that solely by grace He is, this moment, freeing us from the dominion of sin. And to believe on Him in this way is to recognize that He is doing for us what we can never do for ourselves." -C.G.T.

"The Father has left us as much dependent on the Lord Jesus' work for our deliverance as for our forgiveness. It is wholly because we died with Him on the Cross, but unto sin and unto the whole legal principle, that sin's power for those in Him is broken."

"Now to him that worketh is the reward not reckoned of grace, but of debt" (Rom. 4:4).

My Utmost for His Highest by Oswald Chambers

Do It Yourself

“Casting down imaginations and every high thing that exalteth itself against the knowledge of God.” 2 Corinthians 10:5

Deliverance from sin is not deliverance from human nature. There are things in human nature, such as prejudices, which the saint has to destroy by neglect; and other things which have to be destroyed by violence, i.e., by the Divine strength imparted by God's Spirit. There are some things over which we are not to fight, but to stand still in and see the salvation of God; but every theory or conception which erects itself as a rampart against the knowledge of God is to be determinedly demolished by drawing on God's power, not by fleshly endeavour or compromise (2Cor 10.4).

it is only when God has altered our disposition and we have entered into the experience of sanctification that the fight begins. The warfare is not against sin; we can never fight against sin: Jesus Christ deals with sin in Redemption. The conflict is along the line of turning our natural life into a spiritual life, and this is never done easily, nor does God intend it to he done easily. It is done only by a series of moral choices. God does not make us holy in the sense of character; He makes us holy in the sense of innocence, and we have to turn that innocence into holy character by a series of moral choices. These choices are continually in antagonism to the entrenchments of our natural life, the things which erect themselves as ramparts against the knowledge of God. We can either go back and make ourselves of no account in the Kingdom of God, or we can determinedly demolish these things and let Jesus bring another son to glory.

Bible verses: 2 Corinthians 10:5
Devotional Studies by Elizabeth Haworth

God With Us - Perfect MAN Eternal SON (22)

Behold, a virgin shall be with child, and shall bring forth a son, and they shall call HIS name Emmanuel, which being interpreted is, God with us.
Matthew 1:23

Messianic Prophecies

It was Matthew who delighted to quote fulfilled Messianic prophecies in His gospel. This former tax-collector thrilled to link the Lord Jesus Christ with prophecies of old. This disciple of the Lord Jesus trawled the Old writings and linked them with the New. This apostle of Christ, uncovered prophetic Scripture and secured them in his writings.

Christ Revealed

He rooted Christ’s genealogy to the patriarchs of old – to Abraham, Isaac and Jacob. He linked Christ’s Jewish lineage through the esteemed kingly line of the great king David. Much in his gospel demonstrated the legitimate Messiahship of Jesus – to Israel. Matthew took the prophecies of Old and certified their fulfilment in the New. He was a writer who saw what was hidden in the Old – and revealed it in his Gospel. As the old maxim goes: The new is in the old concealed. The old is in the new revealed.

God Incarnate

Matthew's historical record showed the genuine, genealogical supremacy of Jesus Christ. He proved Christ’s legitimate claim to be Israel’s king – and proclaimed Him as God. He also gave many indications that this man Jesus was God Incarnate – God with us.

God With Us

He wrote of Isaiah who cried out to Israel – the Lord Himself will give you a sign; Behold, a virgin shall conceive, and bear a son, and shall call His name Immanuel – Immanuel, which being interpreted is, God with us – God manifest in the flesh. John called Him the Word made flesh, while Mark writes of the beginnings of the good news about Jesus the Messiah, the Son of God – and Matthew calls Him Emmanuel.

Word of God

Christ was not merely a man, chosen from the human race to play the part of Messiah. Nor was He a created Son of God, like the host of angelic beings or the race of man.

read more
Bible verses: Matthew 1:23
Topics: Man
Knowing Jesus Devotional by Elizabeth Haworth

Father Forgive

Then Jesus said, Father, forgive them; for they know not what they do.
Luke 23:34

Precious Pardon

They killed the One so long expected – crucifying Israel’s promised Messiah.. not knowing He bore their sins on His shoulders, so that they could be forgiven. And yet a precious pardon was prayed over every guilty party, Jew and Gentile alike. Forgiveness was God’s heart of love towards the perpetrators of this heinous crime.. for in Isaiah we read: He bore the sin of many and interceded for the transgressors. Isaiah 53:12

Gracious Intercession

His intercession reached back to include all sin, beginning in the garden of Paradise – a pardon extending forward to pay for every mortal sin, including yours and mine. Only the wisdom of a holy God could have designed such an act of gracious mercy. Only the love of our precious Saviour could have implored such a powerful pardon – and His death purchased and procured God’s gracious forgiveness for us all.

Father Forgive

His entire life was a march towards this final goal for He came to save His people. He came from His home in heaven, knowing that cruel crucifixion awaited Him. How staggering that His prayer was uttered as the nails were driven into His flesh: Father forgive them, for they know not what they do.

Lord of Glory

They knew in part what they did, for in every respect they knew He was innocent.. yet had they known the fuller consequences, Jesus would never have been crucified, for had they known it, they would not have crucified the Lord of glory.1 Corinthians 2:8  But the Lord Jesus had to die if we guilty sinners were to live. Had the Lord of glory not died our sins could not have been forgiven.

Propitiatory Sacrifice

Perhaps this is the epitome of the goodness of God, Who turns all evil to good. God’s propitiatory sacrifice for sin was the product of history’s most heinous crime. The crucifixion of God’s Son, opened the floodgates of His gracious forgiveness – and His death paid for the full price of

read more


text:
“Shadrach, Meshach, and Abednego, answered and said … Be it known unto thee, O king, that we will not serve thy gods.” – Daniel 3:16, 18

The narrative of the manly courage and marvellous deliverance of the three holy children, or rather champions, is well calculated to excite in the minds of believers firmness and steadfastness in upholding the truth in the teeth of tyranny and in the very jaws of death. Let young Christians especially learn from their example, both in matters of faith in religion, and matters of uprightness in business, never to sacrifice their consciences. Lose all rather than lose your integrity, and when all else is gone, still hold fast a clear conscience as the rarest jewel which can adorn the bosom of a mortal. Be not guided by the will-o’-the-wisp of policy, but by the pole-star of divine authority. Follow the right at all hazards. When you see no present advantage, walk by faith and not by sight. Do God the honour to trust him when it comes to matters of loss for the sake of principle. See whether he will be your debtor! See if he doth not even in this life prove his word that “Godliness, with contentment, is great gain,” and that they who “seek first the kingdom of God and his righteousness, shall have all these things added unto them.” Should it happen that, in the providence of God, you are a loser by conscience, you shall find that if the Lord pays you not back in the silver of earthly prosperity, he will discharge his promise in the gold of spiritual joy. Remember that a man’s life consisteth not in the abundance of that which he possesseth. To wear a guileless spirit, to have a heart void of offence, to have the favour and smile of God, is greater riches than the mines of Ophir could yield, or the traffic of Tyre could win. “Better is a dinner of herbs where love is, than a stalled ox and inward contention therewith.” An ounce of heart’s-ease is worth a ton of gold.


text:
“Woe is me, that I sojourn in Mesech, that I dwell in the tents of Kedar.” – Psalm 120:5

As a Christian you have to live in the midst of an ungodly world, and it is of little use for you to cry “Woe is me.” Jesus did not pray that you should be taken out of the world, and what he did not pray for, you need not desire. Better far in the Lord’s strength to meet the difficulty, and glorify him in it. The enemy is ever on the watch to detect inconsistency in your conduct; be therefore very holy. Remember that the eyes of all are upon you, and that more is expected from you than from other men. Strive to give no occasion for blame. Let your goodness be the only fault they can discover in you. Like Daniel, compel them to say of you, “We shall not find any occasion against this Daniel, except we find it against him concerning the law of his God.” Seek to be useful as well as consistent. Perhaps you think, “If I were in a more favourable position I might serve the Lord’s cause, but I cannot do any good where I am”; but the worse the people are among whom you live, the more need have they of your exertions; if they be crooked, the more necessity that you should set them straight; and if they be perverse, the more need have you to turn their proud hearts to the truth. Where should the physician be but where there are many sick? Where is honour to be won by the soldier but in the hottest fire of the battle? And when weary of the strife and sin that meets you on every hand, consider that all the saints have endured the same trial. They were not carried on beds of down to heaven, and you must not expect to travel more easily than they. They had to hazard their lives unto the death in the high places of the field, and you will not be crowned till you also have endured hardness as a good soldier of Jesus Christ. Therefore, “stand fast in the faith, quit you like men, be strong.”


text: Land-based fishing enthusiasts can try for kahawai and snapper from the rocky outcrops of Mahurangi. Sustainable commercial fishing, aquaculture, pearling and petroleum exploration and production are permissible provided they do not compromise conservation values. A tiny island nation that controls a vast area of the Pacific Ocean has announced it will ban all commercial fishing in a massive marine park that is the size of California. Inset map. Marine parks. Surf fishing along the Ninety Mile Beach or in the wilderness coast of East Gippsland, the remote beaches of Croajingolong National Park are an anglers dream. Offshore fishing at Mallacoota is among the best in Victoria, and remote fishing in the Tamboon Inlet is an excellent alternative for those wanting to fish in medium sized boats or "tinnies". David Booth ne travaille pas, ne conseille pas, ne possède pas de parts, ne reçoit pas de fonds d'une organisation qui pourrait tirer profit de cet article, et n'a déclaré aucune autre affiliation que son organisme de recherche. No fishing or setting of fishing gear allowed. The government response also establishes a new Marine Estate Management Authority and a Marine Estate Expert Knowledge Panel to replace the existing Marine Parks Authority and scientific panels. in fishing gear. Visit the marine parks website for more information. Sanctuary zones protect approximately 6 per cent of our coastal waters ‑ that means you can still enjoy recreational fishing in 94 per cent of our state waters, including public jetties, breakwaters and popular beaches. Funded through the Federal Government’s Our Marine Parks Grants Program, the project being delivered by Tuna Australia uses beacons and satellites to help prevent the accidental drift of lines into no-fishing areas of marine parks. Port Davey/Bathurst Harbour Marine Nature Reserve No fishing or setting of fishing gear is allowed in the no fishing zone. It is a sad parallel with the new NSW Government initiatives to allow recreational hunting in land national parks, and is clearly a bid to court these powerful hunting and fishing lobby groups. When fishing in a marine protected area, it’s important to: Know your zones and … The NSW Government was responding to the report of the Independent Scientific Audit of Marine Parks in New South Wales, delivered last year. A marine park is a designated park consisting of an area of sea (or lake) set aside to achieve ecological sustainability, promote marine awareness and understanding, enable marine recreational activities, and provide benefits for Indigenous peoples and coastal communities. Marine parks are an important tool in the toolbox of ocean conservation – helping reduce stress on marine ecosystems. The Marine National Park (Green) Zone makes up about 33 per cent of the Great Barrier Reef Marine Park. Écrivez un article et rejoignez une communauté de plus de 118 300 universitaires et chercheurs de 3 807 institutions. Fishing is prohibited in all areas of Long Bay Regional Park as the Long Bay Okura Marine Reserve runs along the park's entire coastline. III: Natural monuments or features Marine parks may include up to four types of zone: Sanctuary zones Sanctuary zones are ‘look but don't take' areas. is zoned to help ensure . In fact only around 20% of marine park area in NSW is no-take, so that only about 7% of the coast is protected from fishing. University of Technology Sydney apporte des fonds en tant que membre fondateur de The Conversation AU. Voir les partenaires de The Conversation France. Under the proposed changes released today, six marine park management plans would be amended to allow fishing in parts of sanctuary zones, the boundaries of two marine parks would be expanded and a new sanctuary zone would be created at Port Stanvac. While the new allowances by the Government apply only to beach fishing, it is likely that other recreational fishers will demand equity, also calling for access to these previously off-limits areas. The truth about marine parks and fishing. The men were caught using fishing rods in the Bunurong Marine National Park, near Cape Paterson in Gippsland. You don’t need a permit to fish recreationally in Australian Marine Parks, however you do need to comply with the relevant state and territory recreational fishing rules and regulations, including species, bag and size limits, seasonal closures, gear restrictions and licence requirements. It includes Hervey Bay, Great Sandy Strait, Tin Can Inlet and the waters off the World Heritage-listed K'gari (Fraser Island) seaward to three nautical miles. However, there may be some places where anchoring is not allowed to protect important habitats or where research is being conducted. The State Government introduced 19 marine parks in 2014. the biodiversity values of the marine park are conserved and protected, while providing managed opportunities for recreational use … Marine parks are multiple-use MPAs, meaning they have different zones allowing different types of activities. All forms of commercial and recreational fishing are prohibited in these areas. Marine parks usually allow recreational activities, such as boating, snorkeling, and sport fishing. We reckon Sydney Marine Park will be just like the many other marine parks around Australia, delivering great fishing, great times … For more information, see recreational fishing in marine … Marine parks also contain specific sanctuary zones where where fishing and other activities might be restricted. Marine parks provide a platform to showcase our distinctive sealife and iconic natural features. Fishing experiences in marine parks include the raw power of surf beaches, your own closely-held offshore spot, or casually fishing from a jetty or breakwater with the kids. Read more about Long Bay Regional Park. Marine parks and reserves are administered by the Department of Conservation. The global conservation status of a NSW marine park is at risk after the Berejiklian government weakened its sanctuary status without consultation to allow recreational fishing, documents show.


text:
so, i was on cloud 9 after having learnt n mastered(hopefully) angularjs..but the devs said wait, u r outdated, we r up with angular2..i was up for the challenge, folded my sleeves n started scratching angular2 only to realise they had more to mock me up when they finally said, haha, learnt angular2? now get ready for angular4..!! nd m damn sure by the tym i hv learnt angular4, they wud say, oh we r really sorry for u, we are back with angular5, 6, 7:@

  • 1
    Welcome to devrant, and the world of JS frameworks. This is how it is, so get used to it, and your knowledge being obsolete every 3 month.
  • 1
    only thing that is constant is change 😀
Add Comment