Coder Social home page Coder Social logo

docs's Introduction

📣 Frontity Framework is not actively maintained!

Frontity Framework is not under active development anymore. Pull requests and issues are not being actively reviewed. For more details, please see the blog post.

The team is now working on the WordPress Interactivity API. This will unblock the same UX Frontity framework enabled but directly in WordPress Core, fully compatible with the new Site Editor.

If you are interested in becoming a maintainer and continuing the development of the framework please do get in touch with one of the developers or let us know in this community thread.

Thanks!



The React Framework for WordPress

Frontity is the easiest way to create amazing websites using WordPress and React


Discourse users npm badge License

Get started | Try demo in your browser | Learn Frontity


What is Frontity Framework?

Frontity is a free and open source framework for building WordPress websites based on React. It strips away the complexity that entails connecting both WordPress and React, and gives you a big head start by providing many of the most common queries already built in. In short, you can spend the bulk of your time on the development requirements of the project (e.g. the theme) and less time on setting up the project or worrying about tooling and configuration.

Frontity's unique approach, with its ease of use and extensibility pattern (similar to that of WordPress itself), offers distinct advantages over other similar React frameworks:

» It's 100% focused on WordPress

Each part of the framework has been simplified and optimized to be used with WordPress. This means the number of concepts that you as a developer need to learn are minimal. No complex configuration is necessary to get started, and the queries to the APIs that deliver the content are pre-configured for the things that developers most frequently need.

» It's opinionated

Frontity has its own state manager and CSS-in-JS solution. Thanks to that developers don't have to figure out how to configure these tools, or learn other technologies such as Redux or GraphQL.

» It's extensible like WordPress

Frontity powers a very flexible extensibility pattern similar to that of WordPress itself. To add new functionality or expand the capabilities of Frontity, you can use any of the existing Frontity and npm packages without having to build them from scratch.

Moreover, Frontity packages (including themes) can be activated and deactivated without code changes and are reusable across projects, helping reduce both development and maintenance times.

» It's rendered dynamically

In Frontity the HTML is rendered dynamically by a Node.js server or a serverless service. This means the HTML does not have to be rebuilt each time the content is edited or new content is published.

Because of its dynamic approach, Frontity provides a great power and reliability when it comes to frequent and real-time content updates, making it a great fit for those projects with content that might change rapidly or that is expected to grow over time.

See the About Frontity page in the docs to learn more. 🤓

How does Frontity work?

In a Frontity project, WordPress is used as a headless or decoupled CMS, just for managing the content. Frontity uses data from the WordPress REST API and generates the final HTML that is displayed in the browser using React.

With Frontity you still use your WordPress dashboard to edit and create content in exactly the same way that you are accustomed to. As you make changes content is automatically updated in your Frontity site, just as it is when using a traditional WordPress theme.

Frontity apps require both a Node.js server and a WordPress server (PHP) to run on. And there are two main Frontity Modes (architectures or configurations):

Why a different Node.js server?

React is a JavaScript library. In order to generate HTML for site visitors or for Google, the server needs to be able to run JavaScript as well.

In theory a PHP server can send an empty HTML file with the JavaScript files included and the visitor will see the page after the JavaScript has loaded. However, this is not a good user experience and it is certainly not recommended if your site needs to be SEO friendly and to rank in search engine listings.

Frontity is prepared to be hosted either in a regular Node.js server or in serverless services. That makes it super cheap and infinitely scalable.

The Architecture page of the docs explains how Frontity works in detail. 🏗

Getting started

You'll need a WordPress installation and Node.js. See the Requirements page for more information.

If you can't wait to see what Frontity can do, head over to the Quick Start Guide.

If you're new to Frontity, we recommend that you check out the step-by-step tutorial, which will guide you through the fundamentals of building and deploying your first Frontity website.

Documentation

The Frontity documentation is distributed across three separate sites:

  1. docs.frontity.org is the generic documentation. As well as theoretical information, such as Frontity Architecture and Core Concepts, you can find many practical guides here.
  2. api.frontity.org is the API reference. This is where you can find detailed technical descriptions for the CLI, and for the packages and plugins available in Frontity Framework.
  3. tutorial.frontity.org is the introductory step-by-step guide. It's designed to provide you with a deep and solid understanding of web development using Frontity.

More learning resources, such as videos and example projects, can be found in the Learn Frontity page. 📚

Community

For general help using Frontity, please refer to the documentation and the available learning resources. If you can't find an answer in these resources you can always check out the Frontity Community Forum, which is packed full of answers and solutions to all sorts of Frontity questions.

The community forum is a great place to ask questions, help fellow users build Frontity apps, and share your projects. It's also where you can keep track of the work done for the framework, join feature discussions, and collaborate on building Frontity itself.

Frontity is dedicated to a positive and inclusive community experience for everyone. Read through this guide to learn more about the forum guidelines, how it is organized, and how to get the most out of it.

Other channels

In addition to the community forum, Frontity has other channels where you can find out more information about the project, join in discussions about it, and also get involved:

  • GitHub: for bug reports and code contributions.
  • YouTube channel: learn from Frontity videos and playlists.
  • Newsletter: designed to inform you about the latest product updates, learning resources and community news surrounding Frontity Framework.
  • Twitter and the blog are also pretty good places if you're looking for news, case studies, and other updates.

Showcase

Want to know who's using Frontity? Need some inspiration for your project? The community is always building amazing projects with Frontity, discover some of them in the Showcase page.

Contributing

There are different ways to support the project and get involved. These are a few things that are always welcome:

  • Testing new features
  • Creating themes/packages and share them on npm or GitHub
  • Creating educational content like blogs, videos, courses
  • Improving the documentation
  • Helping the community

See the Contributing section of the docs for more information on how to contribute. ✨

License

Frontity is licensed under the terms of the Apache 2.0 license.

docs's People

Contributors

19h47 avatar adebiyi-al avatar adebiyial avatar alberto-marin avatar alexwoollam avatar allcontributors[bot] avatar ben-wright avatar chyne avatar darerodz avatar davidshq avatar dependabot[bot] avatar divaksh avatar frontibotito avatar goiblas avatar harnerdesigns avatar ianand avatar josesotelocohen avatar juananrodriguez avatar juanmaguitar avatar luisherranz avatar mburridge avatar michalczaplinski avatar pichichi91 avatar pixelovers-blog avatar poliuk avatar punit5658 avatar rmartinezduque avatar veliky avatar versusbassz avatar zubb avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar avatar

Forkers

chyne goiblas harnerdesigns joannasaerom geraldglynn juanmaguitar pixelovers-blog mburridge zvidenova arnoldlc juananrodriguez mehul-terminaltrend psahalot rodrigojimenezdencker kuzvac andresmgsl theninabird sammosna ben-wright bonjur ryanharrigan divaksh taylorchasewhite htmercury pakman198 punit5658 adbib joelsem ianand adebiyi-al whale-agency arkade1984 civonafets michael-sumner

docs's Issues

Recommend ESLint for a better developer experience with Frontity

Some of the issues reported in the Alexandra Spalato starter theme (console.log, unused variables, ...) could be prevented by adding a linter in our default themes.

wp-source WP REST API URL more clear

Make it more clear the type of URL that need to be set in wp-source

https://test.frontity.org/wp-json/wp/v2/ vs https://test.frontity.org/wp-json/

And some typical examples:

  • Wordpress.com
  • localhost

etc...

Better explanation of frontity.settings.js

We should add more comments to the frontity.settings.js & the index.js generated by default by the CLI with some more information about the purpose of each setting, some examples:

  • explain why all the code is under packages.
  • explain what is mars-theme and that it’s like a “starter” theme in WordPress.
  • explain what is the purpose of the wp-source package in the frontity.settings.js
  • explain that the settings, state & actions in index file are merged with the ones in frontity.settings.js

https://community.frontity.org/t/reflections-on-moving-the-blog-from-gatsby-to-frontity/2248

Explain better in the DOCS advantages of packages

what would be the difference between the “React-only PHP theme” & “Static Rendered HTML” vs using Gatsby or Next.js?

I think the most important difference between Gatsby and Next is not the rendering (static vs dynamic…) but the package/extensibility system. This is hard to see right now because there are almost no packages for Frontity, but Frontity is prepared to become more like what WordPress is today, than to another npm/React framework.Right now that is not explained in our docs, but it’s not a priority so there’s no hurry. We can have a discussion later on. I’d love to explain you all the patterns backed in the framework and how they will be used to extend Frontity

Suggest to add an "Edit in codesandbox" link in "How to share your Frontity project"

We already have an excellent guide to instruct people how to share their Frontity project with the world: https://docs.frontity.org/guides/how-to-share-a-frontity-project

It'd be awesome if you could add a section there to instruct people to add a sandobx.config.json file with the node template like explained here https://community.frontity.org/t/update-codesandbox-template-automatically/862/3?u=luisherranz and a link to "Edit in codesandbox" in their project to make collaboration even easier.

Documentation platform

@juanma Garrido 15/04/2020

For what I've seem, this seems to be the best option as documentation generator

Build optimized websites quickly, focus on your content | Docusaurus

To take into account → https://community.frontity.org/t/migrate-documentation-to-wordpress/1348

Nuxt

Contributors a lot of visibitlity
Edit in Github

nuxtjs.org

Docs in Github (markdown)

nuxt/docs

Gatsby

Search Algolia
Edit in Github

Conceptual Guide

Docs in Github (markdown)

gatsbyjs/gatsby

Maybe add a system so people can suggest and vote topics?

Something like

package version mismatch

I think this is a use case we didn’t think of. That users can just upgrade frontity and expect it to work. @frontity/core is not a dependency of frontity because we want to keep frontity lightweight and the users might end up with a package version mismatch like how it happened here.

@juanma I mention you here in case that it’s that something that should be more prominent in the docs. By that I mean that frontity is a modular framework that is composed of packages that need to be updated together.

https://community.frontity.org/t/error-unexpected-token-export/2307/2

Add a requirements section to packages

  • Head Tags WordPress Plugin → requires Head Tags frontity package to work
  • wp-source → requires a proper REST API URL defined
  • wp-source → requires permalinks proper settings

Is Frontity compatible with page builders (like Elementor)?

Hey, ... asked me if Frontity is or plans to be compatible with page builders. I'd love to understand and learn more about this because I feel quite confused/stupid about it now.

If someone has created a page with Elementor, for example, can he/she fetch it into Frontity?

(pieces of a Slack conversations)

  • I’m not quite sure myself. I think Luis David or Mario might know a bit better!
    ...
  • Pages built with page builders like Elementor, Page Builder by SiteOrigin, CoBlocks and the likes can be fetched into Frontity apps. However, like we do with Gutenberg in frontity.org, you'd need to import the builder's styles into the Frontity application.In frontity.org, we saved the Gutenberg styles in a folders, imported it and included it with the <Global /> component in Frontity.I was able to test this with Elementor and it worked. I'm also trying it out with other builders.NB: Using other builders does not also limit the use of Frontity features like Processors e.t.c
  • I was able to test this with Elementor and it worked. I’m also trying it out with other builders.
  • Does Elementor output somehow nice HTML then? Can their blocks be identified with HTML to React?
  • I guess that we can say then that Frontity is compatible with some page builders, right? To import the styles would users need a package, like the @frontity/gutenberg one?
  • Elementor outputs nice HTML similar to Gutenberg. The elements comes with class names which can be used to style in Frontity. Frontity is compatible with most page builders. To use the page builders styles in Frontity, you'd have to copy the css files from the plugin directory into your Frontity project. In the case of Elementor, the styles can be found in wp-content/plugins/elementor/assets/css folder. The location of the css files in the page builders plugin might differ from the other, depending on how the plugin's folder is structured.
  • How do you mean my "identified"?
  • with a class name or any other HTML attribute

Add a "Caveats" section for the Head Tags plugin

There are some archives/pages of WordPress that aren't supported by the Head Tags plugin because they don't have an entity in the REST API. Although we already are specifying the entities that are supported, we thought it would be nice to list also the ones that aren't. These are the ones we have in mind:

  • Date archives
  • Search pages
  • 404 pages
  • Format archives: It seems something old from WordPress that is not used anymore. It's not even supported by the 2020 PHP theme.

Although they are not supported by the plugin right now, a workaround hardcoding it in Frontity it's pretty easy. They just have to add the title they want in the date or 404 pages.

  • I've been testing the WP SEO plugin for Aleteia, two version of it: the latest one in Alley's GitHub - 0.13.0 (https://github.com/alleyinteractive/wp-seo) and the one in the vip-svn they shared - 0.10.0 (https://vip-svn.wordpress.com/plugins/wp-seo/).These are the settings of the plugin, you can change the title, description and meta keywords for most of them. You can set up a default value using variables like Post - #title# and apart from that, at each specific post, page, category... customize it if you want to override it. I've checked the ones that are supported by the current status of our plugin/package.

image

These are the things that are left (we'll have to consider with Aleteia if it makes sense to support them from Frontity or suggest a workaround):

  • Format archives: I didn't know what was that in WordPress. It's kind of similar to CPT or ACF. Inside a post you can select the Post Format (video, image, standard...) and from there you can go to .../type/video and see an archive of all the post with the video format. Anyway, it's something that the theme has to support, and not even the 2020 theme is supporting it. It seems that is not used anymore. It doesn't seem to have support for the REST API neither.
  • Date archives: Right now, it's not using any head tags, not even the ones included in the homepage.
  • Search pages: I think there are two issues here. Frontity doesn't work with /search/query right? It's the url they use as example. Apart from that, with ?s=query, it's getting the head tags of the homepage. The title, that is the only setting you can configure in this case, could be easily hardcoded in Frontity.
  • 404 pages: Right now, it's not using any head tags. The title, that is the only setting you can configure in this case, could be easily hardcoded in Frontity.

For these last cases (search and 404), if we don't want it to be hardcoded in Frontity, I guess we'd need to add REST API support for that settingsand get that from the Frontity package.

I still have to open the Feature Discussion, but I'd like to know your opinion, maybe after talking to Aleteia, of what we should support or not.

  • I’ve never seen format archives to be honest.
  • I guess Date Archives head tags are not supported by the Head Tags plugin yet because they don’t have an entity in the REST API. Is that right @david? Maybe they can use the home tags (type “post”).
  • Hardcoding the title of date archives, 404 pages and search pages seems about right. Another workaround would be to inject the <title> using the Theme Bridge.

What is not working right now?

What do you mean with what is not working? All the settings of the WP SEO plugin are working excepting the ones mentioned (format archives, date archives, search pages and 404 pages).

ohhh, ok thanks

then I guess it’s working because none of those work in Yoast SEO or AIOSP

Which one is the "Format Archive"?

the others are those cases that our plugin can't handle

so yes, it's working

So I guess:

  • We don’t need a FD for WPSEO
  • Maybe we need to add those caveats to the head-tags docs so people is aware

What do you think? (edited)

In the docs it's specified which type of entities come with the head_tags field, but not those that don't. I think is a good idea to add a note explicitly mention those types.

https://docs.frontity.org/frontity-plugins/rest-api-head-tags#entities-with-head-tags

there

We could create a section called “Caveats”

(I’m not sure if that is the better name, we can ask Michael)

And do a list of things that are not working in general and then the things that are not working in each SEO plugin

Hey

I want to write to Aleteia to catch up and see how they're doing, but first I'd like to understand the state of this

Can you help me?

From all the settings of the WP SEO plugin, everything works except the ones I mention before, but they are cases that the plugin can't handle so we can suggest a workaround if Aleteia is using them:

  • Format archives: It seems something old from WordPress that is not used anymore. It's not even supported by the 2020 PHP theme and it doesn't seem to have support for the REST API neither.
  • Date archives: They don't have an Entity in the REST API. The title could be easily hardcoded in Frontity.
  • Search pages: Here we would need to know if they use the format /search/query ot the query ?s=query. . Anyway, it's not supported by the plugin. The title could be easily hardcoded in Frontity.
  • 404 pages: We can't make it work with the plugin. The title could be easily hardcoded in Frontity.

Explain better in the DOCS advantages of cache (CDN)

https://403page.com/scaling-for-volume-with-frontity-cloudflare/

with that setup, he is pretty much testing how well cloudflare CDN works
because 99.89% of the requests when to the CF CDN
and that obviously scales to the infinitum
but that’s one of the points I always try to make: Frontity is as fast and as scalable as a static site as soon as you add a CDN
and you should add a CDN
(by the way, all the modern static site hostings like Now, Netlify, Surge… have CDNs)
For the rest of 0.11% of the requests that went into Frontity:
If you use a Node server: much more scalable than WordPress, because it’s Node (which by default is more scalable for its I/O) and it’s stateless so you can easily scale horizontally.
If you use Serverless: then this part is also infinite scalable, like a CDN.
and finally the last thing that needs to be taken into consideration to scale Frontity is how well you cache the REST API

Deployment - Check Steps

Also I had problems to follow the Deployment section, when it is even easy to read an understand, I couldn't deploy my site by following that guide. But I had to manage to deploy :) .

https://docs.frontity.org/deployment/deploy-using-now-vercel

@mburridge Can you do a test following the instructions to detect any improvements that could be done here?

This issue is opened for any member of the community who wants to follow these steps and provide feedback about it to improve it

Add Connect page

Say a kind of "Recap": Okay, so far you've learnt all the concepts, let's make a recap". Frontity and its packages exposed state, actions, libraries, etc globally so components can use them using "connect", and if they are updated, all the components affected know it.

Add error and warn to "frontity" package

Both the error and warn commands from the frontity package are missing.

Conversations are here:

The API is:

import { error, warn } from "frontity";

// ## Development
// Throw this message and a link to the community.
error("Message");
// Console error this message and a link to the community.
error("Message", { throw: false });
// Console warn this message and a link to the community.
warn("Message");

// ## Production
// Throw this message.
error("Message");
// Console error this message.
error("Message", { throw: false });
// Does nothing.
warn("Message");

connect and useConnect

Review docs and check if this can be explained better

> the docs say it still needs the connect HOC, what's the point of useConnect then?
> Good question, I'm using it without the connect HOC and its working right. I guess its maybe an error in the docs.
> By using  useConnect() you can create your own hooks that make use of the frontity state, which would not be straightforward with just using connect :slight_smile: 
For example, we are going to release a useInfiniteScroll  hook which is using useConnect internally to access the frontity state!

Wrong `populate` example in @frontity/wp-source package

The example included for the populate function shows a wrong use of api.get.

api.get is an asynchronous function and must be called using await to get the returned object. However, await is not used in the example, and that can make handlers to stop working if developers include that code in their projects. See frontity/frontity#438

The way to fix this is just adding await to the api.get function call:

const response = await libraries.source.api.get({ endpoint: "posts" });

I would take the opportunity to clarify other examples as well, for example, adding await also to other asynchronous function calls like actions.source.fetch and libraries.source.populate.

Pretty permalinks

It'd be good to mention in the @frontity/wp-source package that it only works with pretty permalinks (as opposed to plain permalinks).

This is not about Frontity itself, it's a thing of @frontity/wp-source. And it can be improved in the future, with either support for plain permalinks in that package or by creating a new package, for example @frontity/wp-plain-source.

Possibly incorrect docs for `libraries.source.api.get()` and `api.init()`

Hola! 👋

It seems to me that the documentation has some incorrect / confused info for api.set / api.init and api.get:

https://github.com/frontity/gitbook-docs/blob/616012622fccff28ac5eea40fa682b303561e49c/docs/api-reference-1/wordpress-source.md#L345-L376

  1. As far as I understand, there is no such method as api.set(), so this line https://github.com/frontity/gitbook-docs/blob/616012622fccff28ac5eea40fa682b303561e49c/docs/api-reference-1/wordpress-source.md#L345 should refer to api.init(). Also, the examples for the usage of api.get() below are actually (correctly) showing the usage of api.init() 🤦

  2. The description of api.set() (which should actually be api.init() like described above) says "Request entity to the WordPress REST API.". This is incorrect. It should say something like "Set the path to the WordPress REST API"

Improve documentation regarding WP API REST urls

The rest API problem

Instead of installing WordPress on my server I tried to use a free site on worpress.com and the problem was that they don’t support the /wp-json endpoint. Instead, you have to use something like this:

https://public-api.wordpress.com/wp/v2/sites/instajuegos.home.blog/posts/ 3

That drove me crazy because it was so difficult to find that endpoint on forums etc. I realize that wordpress.com was very limited so I decided to install WordPress on my server. But the /wp-json endpoint still does not work because I didn’t have something called permalink. Again google and forums looking for the answer.

I think this is a very important part because is the way you connect your backend with your frontend. So, in my opinion, the docs are a bit poor explaining all of these cases.

What I would do is create a small tool inside of the docs where you can type the URL of your site and then it tells you what endpoints can be used. Checking first /wp-json then /?rest_route=/. or even the wordpress.com format.

Source: https://community.frontity.org/t/my-experience-and-some-feedback-for-frontity/999

Document different layouts depending on category

From discussion at: https://community.frontity.org/t/moving-an-existing-wordpress-website-with-over-5000-articles/1477/23

Thanks for the quick reply! In Frontity can we handle the multiple post layout depends on category?

Sure.

You could use the [Switch component 1](https://docs.frontity.org/api-reference-1/frontity-components#switch) for example:

<Switch>
  <Layout1 when={data.category === "nature"} />
  <Layout2 when={data.category === "cities"} />
  <DefaultLayout /> {/* rendered by default */}
</Switch>

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.