Giter Site home page Giter Site logo

og's Introduction

Status

DESCRIPTION

The Organic Groups module (also referred to as the 'og' module), provides users the ability to create, manage, and delete their own 'groups' on a site. Each group can have members, and maintains a group home page which individual group members may post into. Posts can be sent to multiple groups (i.e. cross- posted), and individual posts (referred as 'group content') may be shared with members, or non-members where necessary. Group membership can be open, closed or moderated.

TERMS AND DEFINITIONS

  • GROUP: A single node which can have different content types and users associated with it.
  • GROUP CONTENT: Content such as nodes or users, which are associated with a group.
  • GROUP ADMIN: Is a privileged user with permission to administer particular activities within a group.
  • SITE ADMIN: Compared to group admin, a site admin is granted access to all groups operating within a site. The site admin can specify the permissions group admins are granted in order to control their group related activities, while keeping other permissions out of their reach.
  • GROUP CONTEXT: Whenever an individual piece of content such as a node or a user is viewed, the module attempts to determine if the content is associated with a particular group. The group context is later on used to determine which access rights the user is granted. For example, in a particular group context the user can edit nodes, but is only allowed to view the nodes in a different group context. The group context can also be used by custom modules to determine different behaviors. For example, displaying different blocks on different groups, switching to a different theme, etc.
  • ENTITY: Nodes, users, and taxonomy terms, are examples of Drupal entities. Organic Groups allows each individual Drupal entity type to be associated with a group or with a group content. This means that you can associate different users (as group content) to a certain user (as a group).

GROUP ARCHITECTURE

At the lowest level the module associates content types with groups. Above this level is the role and permissions layer, which operates at the group level. The Organic Groups module leverages Drupal's core functionality, especially the field API. This means that a content type is associated with a group, by setting the correct field value. Users are also allowed to select the groups that will be associated with the content from a list of groups, which they have authorization to view. As is the case with Drupal itself, in Organic Groups different permissions can be assigned to different user roles. This allows group members to perform a different set of actions, in different group contexts.

OG Membership Entity

The membership entity that connects a group and a user.

When dealing with non-user entities that are group content, that is content that is associated with a group, we do it via an entity reference field that has the default storage. The only information that we hold is that a group content is referencing a group.

However, when dealing with the user entity we recognize that we need to special case it. It won't suffice to just hold the reference between the user and the group content as it will be laking crucial information such as: the state of the user's membership in the group (active, pending or blocked), the time the membership was created, the user's OG role in the group, etc.

For this meta data we have the fieldable OgMembership entity, that is always connecting between a user and a group. There cannot be an OgMembership entity connecting two non-user entities.

Creating such a relation is done for example in the following way:

 $membership = Og::createMembership($entity, $user);
 $membership->save();

Notice how the relation of the user to the group also includes the OG audience field name this association was done by. Like this we are able to express different membership types such as the default membership that comes out of the box, or a "premium membership" that can be for example expired after a certain amount of time (the logic for the expired membership in the example is out of the scope of OG core).

Having this field separation is what allows having multiple OG audience fields attached to the user, where each group they are associated with may be a result of different membership types.

INSTALLATION DRUPAL 8.x

Note that the following guide is here to get you started. Names for content types, groups and group content given here are suggestions and are given to provide a quick way to get started with Organic groups.

  1. Enable the Group and the Group UI modules.
  2. Create a new content type via admin/structure/types/add. Call it "Group", and click on tab "Organic groups" then define it to be of Group type.
  3. Create a second content type. Call it "Group content", and click on tab "Organic groups" then set it to be of Group content type.
  4. Add a Group by going to node/add/group. Call it First group.
  5. Add a Group Content by going to node/add/group-content. In the Groups audience field, select First group. In the group content view a link was added to the group.
  6. Click on the Group link. In the group view, a new tab was added labeled Group.
  7. Click on the Group tab. You will be redirected to the group administration area. Note that this is the administration of First group only. It will not affect existing or new groups which will be created on the site.
  8. You are now presented with different actions you can perform within the group. Such as add group members, add roles, and set member permissions. You will notice that these options have the same look and feel as Drupal core in matters relating to management of roles and permissions.
  9. You can enable your privileged users to subscribe to a group by providing a 'Subscribe' link. (Subscribing is the act of associating a user with a group.) To show this subscribe link:
    1. Make sure you have the Group UI module enabled
    2. Go to admin/config/group/permissions and make sure that the "Subscribe user to group" permission is given to the appropriate user-roles.
    3. Navigate to the "manage display" tab of your content type (admin/structure/types/manage/group/display) and choose the Group subscription format for the Group type field.
    4. Back in the group view you will now notice a 'Subscribe' link (If you are the group administrator it will say "You are the group manager").
  10. In order to associate other entities with group or group content, navigate to Organic Groups field settings", in admin/config/group/fields.
  11. In order to define default permissions for groups that are newly created or to edit permissions on all existing groups, navigate to the Group default permissions page. Important permissions in this page are the ones under the administer section. These permissions are what enable group admins to have granular control over their own group. This means, that if you as the site admin, don't want to allow group admins to control who can edit nodes in their own group, you need to uncheck those permissions.

DEVELOPERS & SITE BUILDERS

  • Views integration: There are some default views that ship with the module. Follow those views configuration in terms of best practice (e.g. adding a relationship to the group-membership entity instead of querying directly the group-audience field).
  • Token integration: Enable the entity-tokens module that ships with Entity API module.
  • Rules integration: Organic groups is shipped with a Rules configuration that allows simple notification. You can disable it or clone and change its behaviour.
  • Devel generate integration: Enable devel-generate module to create dummy groups and groups content.
  • You may craft your own URLs to prepopulate the group-audience fields (e.g. node/add/post?field_group_audience=1 to prepopulate reference to node ID 1), using the "Entity reference prepopulate" module http://drupal.org/project/entityreference_prepopulate and configuring the correct settings in the field UI. Read more about it in Entity reference prepopulate's README file. Further more, when Entity reference prepopulate module is enabled the node "create" permissions will be enabled even for non-members. In order to allow a non member to create a node to a group they don't belong to, you should craft the URL in the same way. OG will recognize this situation and add the group as a valid option under the "My groups" widget.
  • When deleting groups, it is possible to delete orphan group-content, or move it under another group. In order to do it in a scalable way, enable the "Use queue" option, and process it using for example: drush queue-run og_membership_orphans

API

use Drupal\og\Og;
use Drupal\og\OgGroupAudienceHelperInterface;

// Define the "Page" node type as a group.
Og::groupTypeManager()->addGroup('node', 'page');

// Add OG audience field to the "News" node type, thus making it group content.
Og::createField(OgGroupAudienceHelperInterface::DEFAULT_FIELD, 'node', 'news');

Access control

See Access control for groups and group content.

DRUPAL CONSOLE INTEGRATION

The Drupal 8 branch integrates with Drupal Console to do actions which used by developers only. The supported actions are:

  • Attaching OG fields to entities

Please notice: You need to install DrupalConsole 1.0.0-RC5 and above.

FAQ

Q: How should I update from Drupal 6? A: Run update.php; Enable the og-migrate module and execute all the migration plugins.

Q: How should I update from a previous Drupal 7 release (e.g. 7.x-1.0 to 7.x-1.1)? A: Same as updating from Drupal 6 -- Run update.php; If requested enable the og-migrate module and execute all the migration plugins.

Q: How do I use OG tokens with pathauto module to craft the url alias. A: After enabling entity-tokens module you will have some tokens exposes by Organic groups. However you are not able to do something like [node:og_membership(1):group:label]. See http://drupal.org/node/1088538#comment-4376910

Q: Must I use Panels module along with Organic groups? A: No. However note that the maintainer of the module highly recommends using it, and considers it as good practice.

CREDITS

  • Organic groups for Drupal 5 and 6 authored by Moshe Weitzman -
  • Current project maintainer and Drupal 7 author is Amitai Burstein (Amitaibu) - gizra.com

og's People

Contributors

amitaibu avatar aronnovak avatar bboro avatar chx avatar claudiu-cristea avatar dakala avatar damiankloip avatar davidhernandez avatar dawehner avatar dww avatar fazni avatar gheydon avatar idimopoulos avatar jelana avatar joachim-n avatar kbrodej avatar mariano-dagostino avatar massgov-outsider avatar matslats avatar mpparsley avatar pfrenssen avatar pineray avatar pwolanin avatar sandervd avatar varshith avatar webchick avatar webflo avatar xurizaemon avatar yakoub avatar zerolab 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  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  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  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

og's Issues

New users can select arbitrary groups on login

In admin/config/people/accounts/fields/og_user_node, I haven't set it as a mandatory field, and I also haven't set it to display in the account registration. Still, when a new user registers, he can select any group to become a member of.

Possibly related: When I save the above mentioned field settings form, I get the following error: FieldValidationException: Fehler bei der Eingabeüberprüfung des Feldes in OgBehaviorHandler->validate() (Zeile 295 von /home/orpheusv/public_html/sites/all/modules/og/plugins/entityreference/behavior/OgBehaviorHandler.class.php)

This is independent of what I actually edit in the form.

Test import

The test can be import using the drupal module importer that webchick showed in DrupalCon Amsterdam. Since i moved the tests we need to do that on another og file and then move them back to this repo.

After we got the alpha release blocker removed we can develop using the TDD methodology.

No Query is Run in View When Using Group ID Contextual Filter for User with Multiple Group Memberships

Since 7.37 core update, if you have a view using the "OG Membership: Group ID" Contextual Filter set to provide "the OG groups of the logged in user" as a default when a filter is not provided, and "OG group" validation is enabled along with "Allow multiple values", the query will not run for a user with multiple group memberships when no filter is provided, due to argument validation failing in og_plugin_argument_validate_group.inc.

This is due to the contract of entity_load being more strictly enforced starting in 7.37, in response to this issue, https://www.drupal.org/node/1003788. The condition placed on the $ids parameter is

"An array of entity IDs, or FALSE to load all entities."

The validate_argument function in og_plugin_argument_validate_group.inc calls entity_load_single with the string of concatenated gids that Views supports, ie. "1+2+3". entity_load now tries to validate that this is numeric which fails, so no entities are returned, argument validation fails, and the query does not run.

I will be submitting a pull request with a proposed fix.

node:og-group-ref:0:url:relative token stopped working

It seems this token has stopped working. node:og-group-ref:0:url still exists, but it doesn't take into account a manually-set alias.

As an example, we have a "Human Resources" group that is located at mysite.com/hr

Before using the token above would generate URLs like mysite.com/hr/mypage - which is the desired effect.

Now the same token is generating mysite.com/human-resources/mypage

Essentially, its not respecting the URL alias of the parent node.

Incoherent access rights in og_register on User registration form

Using D7.39 and OG7.27
Here's my use case. I am building a system with groups and subgroups using the og_subgroups module. I have a user "ricardo" who is a Member of a Level 1 group, and Admin Member of a Level 2 group.
I want Ricardo to be able to create new users (not just add them to the group but actually register a new user), while at the same time adding them to the Level 2 group of which he is a member (instead of having first to create the user and then add the user to the group).
I have proceeded as follows:

  1. Enable the og_register module
  2. Add the Group Register field to both Level 1 and Level 2 Group content types
  3. Add the Group Membership field to the User Entity. When I did nothing more than this, to my surprise I found that the User registration form displayed a choice of Groups to Anonymous and to Super-admin, but not to Ricardo despite him being Admin member of his group.
  4. The only way to get the Group list to show up (without giving Ricardo the OG Admin full rights) was to check the "Allow entity access to control field access" option in the Group Membership field.
    This works, but... the User registration form displays all the groups of which Ricardo is a Member, including the Level 1 group where he does not have permissions to add new users. And if you select the Level 1 group in the list, the new user gets added there without any problems, which is clearly a security issue

og_users_roles migration is broken

I have tons of this error and ~90% of the items are not migrated:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-10-1' for key 'PRIMARY': INSERT INTO {og_users_roles} (uid, rid, gid, group_type) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => 1 [:db_insert_placeholder_1] => 10 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => node ) (\includes\common.inc:7316)

renaming a table on install in hook_schema og_access.install

Why is this table being renamed?

This is causing a PDO exception under some circumstance. I haven't tested a full reproduction, but it seems if og_access is enabled/disabled/enabled/disabled/uninstalled/enabled while field for group access are still attached to the group then this can happen.

It seems like this is for upgrades from d6 to d7, shouldn't this be in an update hook then?

Do not load menu item just before determining context handler to prevent premature access denial due to empty og context.

Issue in og_context.module, function og_context_determine_context().

When determining the context, don't by default load the menu item and just test on current path. Because if during the custom menu access check og_context is called (as can be the case in a views access plugin or ctools access plugin where og_context would be called), then the statically cached initialized context will seem empty.
Solution is not loading the menu item before determining the context, thus preventing a custom access being executed which could in turn execute og_context() to establish a context, resulting in denial of access as the context is initialized alrready, but empty.

og_context-access-issue

"your groups" and "other groups" within admin OG audience field do not respect cardinality of 1.

Scenario:
My content type contains an OG group reference field with cardinality limited to 1 so that content can only be associated with a single group.
A groups administrator sees a more complex field for OG audience that has two parts: "your groups" and "other groups" (either auto-complete or select).
When an administrator selects a value in one of the two fields but doesn't manually remove the value from the other field and saves the node, the following error is generated:

OgException: OG membership can not be created in entity node and bundle freeform using the field og_group_ref as the field cardinality is set to 1. in OgMembership->save() (line 69 of /sites/all/modules/contrib/og/includes/og.membership.inc).

Ideally, there would be form validation that prevents the node form from being submitted when cardinality is 1 and more than one value for group audience is selected. It would be even better if (with cardinality 1) after selecting a value for "other groups" that "your groups" was set with JS to "none" (and the reverse).

Entity access for groups and group content

OG supply basic permission(og_access extends it). For now the permission is a content entity. But this could be a config entity since we want to export permission for roles.

This a discussion we can do here but will provide solution via code.

of_field_access makes OgMigrateMembership fail

Problem/Motivation

During a migration of OG Memberships from 7.x-1.x to 7.x-2.x, the process tries to determine whether the user has access to all potential group audience fields. That calls the og_field_access_field_access() function which calls og_user_access_entity() which tries to load all the groups related to the given entity. The problem is that most of these groups are not fully migrated yet so their group_type is empty so when OG tries to create an entity_metadata_wrapper('', $gid), an Exception is fired.

Proposed resolution

Use the last og_get_best_group_audience_field() parameter to avoid that field_access test during the migration process.

group audience stopped working

Hello,
We are unable to use OG - group audience. It stopped working around the time we installed/enabled the blog modual. When creating a new contnet (document, blog, page. ect. ) the option for group audience shows "none". What could couse this. At one time the blog content type did work and the other did not. At that time I compared the blog content type with the others and all the settings looked the same. We sent a message witht eh System Admin to look at the logs of the server and no errors were wound.
We are gettting the following errors in the Drupal Recent log messages report:
Undefined index: membership_type in og_entity_property_info() (line 236 of /var/www/html/drupal7/sites/all/modules/og/og.module.

Any help would be greatly appreciated,
Thank you,
Abe

non-required group audience field failing validation when group admin edits group node

We have a content type that can be a group and sometimes group content as well. (eg node 123, "My Group", is itself an OG group node, and belongs to the OG group 456, "My SuperGroup") most nodes are only group nodes, and are not members of any other group. the og_group_ref group audience field is not required.

however, group admins - people who are members of the group with the "administrator member" group role - are unable to save changes to the group node, even though they have the OG permissions "Edit group" and "Administer group", because when they don't choose an existing group in the group audience field (either leaving it altogether blank, or selecting "- None -"), they get the error, "You must select one or more groups for this content."

users who have Drupal role based edit permission on the content type do not get this error. giving the group admins explicit OG permissions on the og_group_ref field makes no difference.

there are other issues related to this validation error in the Drupal issue queue, but they all boil down to different problems, from what i can see.

OG audience filed population

The OG audience field(AKA og_group_ref) is a special field. It's a field that populated like all the other fields. Every time there is a change in the field we need to remove/update/insert og membership entity.

This split into:

  • When populating the field programatically.
  • When editing an entity from the UI we need to create manually the form elements.

ajax submit button breaks entity prepopulate of group admin audience field "other groups"

To recreate:

  1. log in as an admin with "administer groups" permission
  2. in a group where the logged in user is not a member, create new content using a required group audience field with entity prepopulate via the URL.
  3. Despite not being a member, the group appears in the 'default' field as part of the combo audience field for group administrators.
  4. Click 'upload' on a file/image field within the group content node form. The default field will still show the prepopulated group in 'your groups'. (If no ajax submit buttons are clicked, saving works.)
  5. Attempt to save.
  6. Your groups is cleared, and the node form throws the following error: "An illegal choice has been detected. Please contact the site administrator." - from line 1388 in includes/form.inc - because the value of the prepopulated group is no long in the options for 'your groups'.
  7. This error is compounded because after the error, it's no longer possible to select the prepopulated group in EITHER 'your groups' or 'other groups'. If selected in 'other groups', the referenced group throws "The referenced group (@type: @id) is invalid." from OgBehaviorHandler.class.php because the prepopulated value is not listed in the results from entityreference_get_selection_handler() any longer.

Note that I tried this with the admin part of the audience field as both an autocomplete and as a select field. I also tested this with the latest dev version of entityreference_prepopulate that contained a patch for a different ajax error. (http://cgit.drupalcode.org/entityreference_prepopulate/commit/?id=41ed253) The error was present in all cases.

Code guideline

OG have a lot of og_ function that can move into the controller as static methods. For example OG::IsGroup() OG:IsGroupContent(). This also should effect the access part of OG(not og_access).

Any other thoughts?

EFQ support

OG audience field(AKA og_group_ref) field is empty but the values is kept in the og membership entity. In drupal 7 we had entity field query alter hook that do for us the work. This is a also something we need to import.

Groups as Entities?

I realize this is a late in the game ask/question, but is there any good reason for groups being nodes with specific fields attached, instead of a custom entity type? I would think it would ultimately make them a lot more manageable.

Node context negotiation fails

Problem / Motivation

Issue #28 and commit 66d3b72 causes Node context negotiation to fail due to comparison between menu router path (pattern) and path instance:

        if (strpos(current_path(), $path) === 0) {

For nodes this result in comparison between e.g. node/1107 and node/%.

Proposed resolution

One of:

  1. Revert
  2. As explained in #28, the call to menu_get_item() may result in a new/nested call to og_context() due to menu router item object loading and translation. But one cannot compare a menu item path with a live path due to the above comparison failure, so you have to retrieve the menu router item from the current live path somehow. One solution is to implement a truncated version of menu_get_item() that halts processing the router item before item translation and object loading. It's only used to compare string. Leave it to the negotiation implementations to further check access control.

Widget to share existing content in group

This is a Feature request

There should be some kind of widget that will appear in node pages. The widget will be like a shortcut to post the node in a group. Currently, you have to go to node edit page and select group where you want to post the content.

The widget will only appear if the user is member of some group.

P.S. I liked the drupal issue queue, you can add tags, etc.

Development roadmap for OG 8.x

Following on from a brief exchange with @amitaibu on Twitter.

Rational

Porting over a module such as OG to Drupal 8 is a large, time consuming task. The current guesstimate is around 100 developer days of work.

Proposal

I'd like to propose that we come up with a development roadmap to bring the code to a stable 8.x-1.0 release.

I feel it would be beneficial to break the development of OG down into bite-sized milestones as it would likely encourage companies to sponsor at least some of the milestones in order to have the module stable for when Drupal 8 is released.

Ideas

Rather than a fully featured Drupal 8 port of the Drupal 7 version, could a minimal viable product be a better target for the initial 8.x-1.0 release? Subsequent minor versions could then add these additional features (such as integration with other modules, etc)?

This could help get a minimal functioning version to the community earlier and spur on other developers / companies to add some of the missing features they need.

Next Steps

  1. Draft an initial roadmap - this will require someone with a good knowledge of the OG architecture.
  2. Assign a very approximate number of developer days needed to complete each of the milestones.
  3. Find sponsors and developers willing to offer time / money.

Thoughts?

Default OG Group link not in menu

After the upgrade from D6 to D7 I no longer have "/og" link named "Groups". Why is this one missing? Can you fix this bug, please?

Test seems false negative for og_field_access

This is related to the Drupal.org issue 1950894. I have proposed patch that I believe should pass without issues but surprisingly I got stuck by an unusual Test case. The test is granting the user permission to edit the field, and stating that shouldn't be able to edit the field.

The patch I'd like to review is:
https://www.drupal.org/files/issues/og_user_access_entity-1950894-38.patch

Test case to review:
https://qa.drupal.org/pifr/test/1046753

The later patch was for thought to further check if user needs to have another permission but that other patch (with more code) is failing too.

Implement automated test bot for patches in issues queue

As I know Github has no testbot like Drupal.org has. Committing patches without a test run and tests is not good and will cause regressions.

Implement a testbot to make sure no regressions happen and patches are automatically run when posted, but before they will be committed.

create group content: how to block anonymous user but allow authenticated non-members?

Content type MyType has no Drupal role permissions granted on it at all. It's set up to be used as OG group content. The default (site-wide) OG permission "Create MyType content" is set for non-members and members.

The result is that anonymous users as well as authenticated non-members are able to create MyType nodes if they prepopulate the group audience to a valid group.

I think that this is all theoretically correct behavior. Checking different settings of the OG edit permissions seems to confirm that OG permissions override Drupal role-based permissions.

So my question is, how do I exclude anonymous while still allowing logged-in users? To OG, they're all just non-members.

Option to hide 'pending' membership status

For non-self-signup groups, the 'pending' membership status is not needed and confuses users.
Currently there is no clean way to remove.

Proposed resolution

a) A configuration option per group
b) Simple magick that checks that no group role has the right to join

My gut feeling is b) (with an olter hook) should be fine.

OgMembership::save() does not update entity audience field

To set context, I have a module that generates a node from an incoming email and associates it with a group based on the email address that it came in on. The flow looks something like this:

//(email arrives, and triggers drupal)
// Prepare node, populate fields
node_save($node);
foreach ($group_nodes as $gid => $group_node) {
  og_group('node', $gid, array('entity_type' => 'node', 'entity' => $node);
}
// At this point, $node->og_group_ref should be populated, but it is not.

(FYI, this is a modification I'm making to the og_mailinglist module).

In the og_group() source code, it specifically mentions that OgMembership::save() should update the entity in question.

My current solution is this:

    $entity_wrapper = entity_metadata_wrapper($entity_type, $entity);
    $items = $entity_wrapper->{$field_name}->value();
    $items[] = $group;
    $entity_wrapper->{$field_name}->set($items);

In OgMembership::save() after parent::save(). (Sorry, no patch at the moment).

Status

Hi,

Could you add a section to the README or maybe keep this issue updated with what the status is for d8? Can we use it yet? Can we help you out in any way? I looked at the d.o page for og but there's no mention of D8 either.

Regards,

Alexander

Removed field og_group_ref but content type still shows as Group Content

I have removed og_group_ref but content still shows as Group Content. It shows checked on the content type's edit tab > Organic Groups (Group Content is remains checked). Also when I go to Configuration > Organic Groups > OG Permissions overview all of the fields for this content type show up here (I have OG Field Access enabled). This is problematic.

I have cleared cache multiple times. Is there a DB field I can just set to disassociate this?

I am using 7.x-2.7

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.