1a07ad8d9e
* transliterate when generating attribute names to avoid emptiness If you enter a non-ascii (non `\w` matching) string as the profile field label, the attribute name is the empty string. This causes problems outlined in #16391 To avoid losing user provided data, transliterate (Sterile is the same tool we're using for Article#title_to_slug) before matching against the word regex. If we persist an empty string, or persist a non-`\w` name, the coordinating regex in Profile::ATTRIBUTE_NAME_REGEX will leave a nil match and raise NoMethodError (the method missing is for match[:attribute_name] when match was nil, not Profile - that's the next commit. * Guard against nil matches If an attribute name doesn't match the regex, the match is nil, and trying to access (nil)[:attribute_name] raises a NoMethodError. If there was no match, assume profile does not respond to the selector, and don't handle it in method missing. * Ensure generated attribute name is valid before saving This raises a validation error if the generated name (from the label) would be empty. It's not an optimal error message (since the user can't see the internal attribute name) but it prevents persisting broken/empty data * actually raise error when validating validate/valid? only return true or false (and set errors on the object). In order to reject the creation, we need to raise a validation error, not only call validate. I think this is because the execution of before_create hooks happens after validation (which is why the validation was only checked on update, not create). * Generate an attribute name completely independent of the field label This prevents mistakenly labeling a field "Class" or "Association" or one of the other hundred public methods an AR model like Profile exposes. Since attribute_name will be passed to `profile.public_send` we really shouldn't build selectors from user supplied inputs. * Use the admin supplied label in the sidebar The profile decorator is used in the Users#show page to populate the sidebar fields. Don't use the attribute name (which we mangled during creation, and now generate randomly) as the label, use the label. * Make the label lookup null safe, and filter attributes more * Update data update script to not expect predictable labels This is low impact since it ran in july, but we no longer know what attribute name a label will create. * Fix moderator spec "Test Field" label no longer predictably generates :test_field as an attribute name. Ask the field what it's name is before asking profile about it. * Fix profile preview card request spec Remove the assumption that profile responds to a method name based on the label for Work and Education fields. * Update old DUS and its test This can probably be archived * Update profile spec to use fields generated attribute names We used to "know" how attributes were generated from labels. Now we don't. * update e2e seeds for profile field change * Don't expect attribute name to be based on the label * expect created profile fields respond to their attribute name * Update system test The label, not the attribute name, is shown on the profile form (the field has an id related to the attribute name, but the view shows the mutable/human-readable label). * Keep the field title lowercase when sending the json preview card The userMetadata component expects "work" and "education" to be attributes of the metadata, but the ui_attributes_for() method was titlizing these (for display). Ideally we wouldn't have "special purposed" these two field names, but they're there. * update profile field by attribute name, not based on label * Update profile field removal assumptions We don't know what the method selectors will be, we have to ask. * remove old test * Update translations for Education and Work Since the ui_attributes_for(area:) now gives the label, not the attribute, we need to match the label of the profile field. Note to self: this exposes an issue in localizing the custom profile fields (probably a bigger problem for large, international communities like DEV than some others, but trying to match static translation files against user-modifiable database records seems like a problem we'll see again). * Empty commit to retrigger buildkite * Remove profile field migration update scripts Cloned the specs from the other "remove unused scripts" script. * Remove unused scripts The data update script removes the entry from the table (recording that these have run) - we also want to remove the files (preventing them from running again). * remove unneeded spec for removed file * when translation for header area field not found, use the title Only Work and Education already have keys in the yml translation file, and there's not a great (or easy?) way to make multiple translations on these fields right now. Since an admin can create a new field, and assign it to the header area, we can't assume the code has a configured translation key for this field. Fallback to the title (we do this in another context already) if there's no translation. * PR feedback: Avoid n+1 query for labels the original implementation of "label_for_attribute" had an n+1 query looping over each matched key. Follow suggested improvement and pull labels and attributes at once from the db and modify the returned hash. * Downcase title before looking for translation key This avoids putting "odd" capitalized keys into the yml translation file Revert addition of "Work" and "Education" to the users files. * use a let binding for duplicated test data * Update app/models/profile_field.rb prefer SecureRandom.hex for a dashless uuid (instead of removing the dashes). Co-authored-by: Jamie Gaskins <jgaskins@hey.com> Co-authored-by: Jamie Gaskins <jgaskins@hey.com> |
||
|---|---|---|
| .buildkite | ||
| .gems | ||
| .github | ||
| .husky | ||
| .vscode | ||
| .yarn/releases | ||
| app | ||
| bin | ||
| config | ||
| cypress | ||
| datadog | ||
| db | ||
| lib | ||
| log | ||
| public | ||
| scripts | ||
| spec | ||
| vendor | ||
| .codeclimate.yml | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.test | ||
| .env_sample | ||
| .erb-lint.yml | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .gitattributes | ||
| .gitignore | ||
| .gitpod.dockerfile | ||
| .gitpod.yml | ||
| .lintstagedrc.js | ||
| .nvmrc | ||
| .postcssrc.yml | ||
| .prettierignore | ||
| .prettierrc.json | ||
| .rspec | ||
| .rubocop.yml | ||
| .rubocop_todo.yml | ||
| .ruby-version | ||
| .simplecov | ||
| .slugignore | ||
| .solargraph.yml | ||
| .travis.yml | ||
| .yardopts | ||
| .yarnclean | ||
| .yarnrc | ||
| babel.config.js | ||
| CHANGELOG.md | ||
| CODE_OF_CONDUCT.md | ||
| config.ru | ||
| container-compose.yml | ||
| Containerfile | ||
| CONTRIBUTING.md | ||
| customJsDomEnvironment.js | ||
| cypress.dev.json | ||
| cypress.json | ||
| docker-compose.yml | ||
| Dockerfile | ||
| empty-module.js | ||
| Gemfile | ||
| Gemfile.lock | ||
| gitpod-init.sh | ||
| Guardfile | ||
| jest.config.js | ||
| jsconfig.json | ||
| LICENSE.md | ||
| package.json | ||
| postcss.config.js | ||
| Procfile | ||
| Procfile.dev | ||
| Procfile.dev-hot | ||
| Rakefile | ||
| README.md | ||
| release-tasks.sh | ||
| SECURITY.md | ||
| svgo.config.js | ||
| testSetup.js | ||
| yarn.lock | ||
Forem 🌱
For Empowering Community
Welcome to the Forem codebase, the platform that powers dev.to. We are so excited to have you. With your help, we can build out Forem’s usability, scalability, and stability to better serve our communities.
What is Forem?
Forem is open source software for building communities. Communities for your peers, customers, fanbases, families, friends, and any other time and space where people need to come together to be part of a collective. See our announcement post for a high-level overview of what Forem is.
dev.to (or just DEV) is hosted by Forem. It is a community of software developers who write articles, take part in discussions, and build their professional profiles. We value supportive and constructive dialogue in the pursuit of great code and career growth for all members. The ecosystem spans from beginner to advanced developers, and all are welcome to find their place within our community. ❤️
Table of Contents
- What is Forem?
- Table of Contents
- Community
- Contributing
- Getting Started
- Developer Documentation
- Core team
- Vulnerability disclosure
- License
Community
For a place to have open discussions on features, voice your ideas, or get help with general questions please visit our community at forem.dev.
Contributing
We encourage you to contribute to Forem! Please check out the Contributing to Forem guide for guidelines about how to proceed.
Getting Started
This section provides a high-level quick start guide. If you're looking for a more thorough installation guide (for example with macOS, you'll want to refer to our complete Developer Documentation.
We run on a Rails backend, and we are currently transitioning to a Preact-first frontend.
A more complete overview of our stack is available in our docs.
Prerequisites
Local
- Ruby: we recommend using rbenv to install the Ruby version listed on the badge.
- Yarn 1.x: please refer to their installation guide.
- PostgreSQL 11 or higher.
- ImageMagick: please refer to ImageMagick's installation instructions.
- Redis 4 or higher.
Containers
Linux
- Podman 1.9.2 or higher
- Podman Compose 0.1.5 or higher
OS X
Installation Documentation
Please see our installation guides, such as the one for macOS.
Developer Documentation
Check out our dedicated docs page for more technical documentation.
Core team
- @benhalpern
- @jessleenyc
- @peterkimfrank
- @maestromac
- @zhao-andy
- @lightalloy
- @atsmith813
- @joshpuetz
- @juliannatetreault
- @ridhwana
- @fdoxyz
- @msarit
- @jdoss
- @cmgorton
- @andygeorge
- @phannon716
- @s_aitchison
- @jgaskins
- @djuber
- @rt4914
- @jeremyf
- @dscottS3
- @asheren
Vulnerability disclosure
Forem is the open source software which powers DEV.
We welcome security research on DEV under the terms of our vulnerability disclosure policy.
Acknowledgments
Thank you to the Twemoji project for the usage of their emojis.
License
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. Please see the LICENSE file in our repository for the full text.
Like many open source projects, we require that contributors provide us with a Contributor License Agreement (CLA). By submitting code to the Forem project, you are granting us a right to use that code under the terms of the CLA.
Our version of the CLA was adapted from the Microsoft Contributor License Agreement, which they generously made available to the public domain under Creative Commons CC0 1.0 Universal.
Any questions, please refer to our license FAQ doc or email yo@dev.to.
Happy Coding ❤️