CAll Us: +1 888-999-8231 Submit Ticket
Menu

Daily ArchivesOctober 6, 2017

Home / Blog

Community Collaboration With Magento Open Source

Community Collaboration With Magento Open Source

Photo by rawpixel.com on Unsplash

Magento 2.2 has arrived! The newest release fixes 428 bugs, with 17 percent of those being community contributions.

The full release notes can be found here.

The 17 percent represents 71 bug fixes that would’ve likely been overlooked if not for the efforts of the Magento community. This result was thanks in no small part to plenty of Contribution days and hackathons, improved GitHub management, and the tireless effort of the Community Engineering team.

At Meet Magento Sweden, I was fortunate enough to participate in the Contribution Day in Stockholm.

Digging into the code, I developed a fix in response to issue report #9278, “Create new CLI command: Enable Template Hints.” You can read more about this new CLI command here.

However, this is far less about singing my own praises and more about highlighting the process behind its approval and eventual inclusion. The issue in question had the “Up for Grabs” label, which means pretty much what you’d think – anyone can take a shot at resolving an issue that was already tagged by the Community Engineering team.

After writing and testing the code, I showcased the new feature during the allotted demo time at the end of Contribution Day, then submitted the pull request (PR) to the develop branch for the upcoming Magento 2.2.

As we speak, there are other branches in use, and the develop branch always used as the integration branch for upcoming releases. For example, 2.3-develop will point to the 2.3.x releases, 2.2-develop pointed to 2.2.x, and so on.

Usually, once the pull request is submitted, someone from the Community Engineering team checks the submission, asks for more input if needed, and, if and when it’s ready, approves it for merging. The team uses self-explanatory labels to identify the status of each pull request, and is intended to keep things user-friendly and transparent.

If you’re curious about Magento Open Source, I recommend starting with the Magento Issue gates to fully understand how issues and PRs are labeled. After that, head to the Magento automated testing standards and the Magento Code of Conduct so we all can get along on GitHub while working together to achieve great things!

Posted in:
Magento

Source link

WordPress Says No To React, Forcing Gutenberg Editor Delay

WordPress Says No To React, Forcing Gutenberg Editor Delay

Photo by Michael Mroczek on Unsplash

Javascript has become increasingly important to WordPress developers over the last couple of years. Anyone working on the web front-end needs to know Javascript, but the introduction of the WordPress REST API has focused the cutting-edge of WordPress development on Javascript and frameworks like React. But, in what must be welcome news to React competitors like Vue, the WordPress project will no longer use React because its license is viewed as potentially harmful.

The move away from React will force a rewrite of key WordPress front-end apps and components, including the new Gutenberg editor, which will be delayed by several weeks at least. The decision doesn’t affect most WordPress theme and plugin developers, who are free to use any framework they like, but it highlights an issue with React that is worth considering.

The anti-React stance, which was announced by WordPress creator and lead developer Matt Mullenweg, is a response to Facebook’s refusal to modify React’s BSD+Patents license. The license has caused controversy in the open source community, and WordPress is only the most recent project to ban its use.

Developers have embraced React because it makes it easier to design, build, and maintain complex front-end interfaces for the web. React is distributed under a BSD+Patents license. The BSD license is a standard open source license which allows anyone to use the code. The “Patents” component of the React license is, however, is definitely non-standard.

In brief, it says that anyone can use React for any purpose, but that they lose the right to use any Facebook-patented technology — including in React — if they sue Facebook for patent infringement. The worry is that any company that makes a significant investment in React and similarly licensed software will face a dilemma if Facebook infringes their patents: they can sue and be forced to abandon that investment or let Facebook get away with it.

The patent issue was recently brought to a head when the Apache Foundation decided that no Apache project could directly depend on React — necessitating the rewriting of a lot of code.

Facebook says that the BSD+Patents license allows it to make React and other open source projects available to the community, while reducing the number of frivolous patent lawsuits it has to deal with.

But there’s a concern that using React will cause many companies and developers to avoid using WordPress and other projects using React. For the majority of developers and companies, the BSD+Patents licenses isn’t likely to cause problems directly — most of us don’t have patents to protect. For open source projects like WordPress, it’s more complicated.

Open source projects are often used by big companies with patents — or by smaller companies that might be bought by big companies with patents. Those companies will not want to give up their right to sue for patent infringement or buy a company with products that carry that risk. The concern is that using React in WordPress will discourage a large swath of its potential user base.

For WordPress users, the most obvious impact of the project moving to a different front-end framework will be the delayed release of Gutenberg, which is expected to be a headline feature in a future WordPress release. For developers, it might be worth considering whether React is the right choice for future WordPress-related projects.

Posted in:
WordPress

Source link