creativecommons / creativecommons-base Goto Github PK

We have some minor changes that we would like to release.

Task

• change project metadata to indicate version 2022.02.2
• publish 2022.02.2 release on GitHub

Problem

The footer area currently contains hard-coded structure and information including:

• social media links
• contact information/address
• copyright notice

Description

Rather than hard-coding that information, consider allowing content editors to use generic WordPress blocks to structure the page footer. This could open up possibilities to not only changing the content but also the layout of the footer without requiring a designer or developer.

Goals

• make the theme more site-agnostic (generic)
• enable content managers to make structured changes to site layout

Additional context

Not only does WordPress 5.8 support block-based widget layout, it also helps users to create higher-level widget combinations, such as a "social media links" icon row.

Problem

The creativecommons-base theme currently defines theme configuration forms and templates for two specific components:

• featured conetent
• donation appeal

However, the hard-coded nature of these templates may be inflexible while introducing a maintenance burden to the project.

Description

Consider creating two generic theme block areas, such as below_header and above_footer wherein we can place Gutenberg blocks. For example, there can be a separate project for CC-specific Gutenberg blocks such as a Donation Appeal Block and a Featured Content Card block.

Additional context

WordPress 5.8 allows developers to define template regions that can contain Gutenberg blocks.

• https://make.wordpress.org/core/2021/06/29/block-based-widgets-editor-in-wordpress-5-8/
• https://jbaker.media/blog/using-block-areas-with-wordpress-gutenberg/

Describe the bug

When tried to upload this theme to wordpress, it gives an error in functions.php. Tried in localhost.

To Reproduce

1. Upload theme in wordpress
2. Activate theme

Expected behavior

Screenshots

Desktop (please complete the following information)

• OS: Windows and Ubuntu

Smartphone (please complete the following information)

• Device: (ex. iPhone6)
• OS: (ex. iOS8.1)
• Browser (ex. stock browser, safari)
• Version (ex. 22)

Additional context

The files that have been linked have different names, they need to be updated in functions.php

Split from PR #75

Related issue: #69 (due to abandoned dependency causing error below)

I am unable to install the package dependencies in composer.json due to incompatibilities.

Your lock file does not contain a compatible set of packages. Please run composer update.
| 
|   Problem 1
|     - doctrine/inflector is locked to version v1.2.0 and an update of this package was not requested.
|     - doctrine/inflector v1.2.0 requires php ^7.0 -> your php version (8.0.7) does not satisfy that requirement.
|   Problem 2
|     - doctrine/inflector v1.2.0 requires php ^7.0 -> your php version (8.0.7) does not satisfy that requirement.
|     - felipelavinz/queulat v2019.4.2 requires doctrine/inflector v1.2.* -> satisfiable by doctrine/inflector[v1.2.0].
|     - felipelavinz/queulat is locked to version v2019.4.2 and an update of this package was not requested.

Reproduction

1. run composer install
2. see error

Expectation

Project dependencies would install correctly without conflict.

Environment

• Device: laptop
• OS: Ubuntu 20.04

Notes

• The official Composer image does not support PHP below version 8.
• Doctrine/inflector latest version is at 1.44.

Description

The breadcrumb is being rendered twice:

Reproduction

1. start the development server
2. import the staging content
3. set any page as the front page
4. view the front page and notice the breadcrumb is rendered twice

Expectation

The breadcrumb should only render once. The breadcrumb should be aligned with the overall theme container, rather than right against the edge of the screen.

Problem

Remove the project dependency on Queulat.

Description

The project depends on a WordPress development framework called Queulat. The Queulat framework has some possible shortcomings

• very limited documentation
• limited community contribution
• defining its own conventions
• has broken/abandoned dependencies
  • https://packagist.org/packages/anahkiasen/underscore-php

Additional context

Before making the decision whether to deprecate Queulat, it is good to

• determine how Queulat is being used in the project
• identify alternatives in the WordPress development ecosystem
  • these should be ideally part of WordPress core and not some third-party, proprietary plugin

How is Queulat used?

Queulat is used to

• define the theme settings page
• create custom WordPress metaboxes

What would be used instead of Queulat?

Use standard WordPress functions to define the theme options forms

• https://blog.templatetoaster.com/wordpress-settings-api-creating-theme-options/

Use conventional WordPress code to define metaboxes.

• https://developer.wordpress.org/plugins/metadata/custom-meta-boxes/

Related code

Queulat is used in the following files:

What to avoid?

Avoid adding new plugins to this theme, particular those with premium extensions or features.

Description

The vue-eslint rule that restricts mixing vue-for and vue-if was broken in the sidebar component.

Reproduction

1. Check out the docs branch by running the command git checkout docs on your terminal
2. cd to wp-content/themes/wp-theme-base/docs/src/components/Sidebar.vue
3. Delete the statement eslint disable rule on line 19
4. On the terminal run the script npm run lint
5. See error.

Expectation

• An error is logged on the console, that outlines the vue-eslint rule that has been broken.

Screenshots

The screenshot below captures the error

Environment

• Device: Dell Laptop
• OS: Ubuntu 20.04
• Browser: N/A
• Version: N/A
• Other info: (eg. display resolution, ease-of-access settings)

Resolution

• I would be interested in resolving this bug.

Problem

Our docker-compose.yml currently uses a deprecated link definition to allow for inter-container communication.

Description

Replace the link with a user-defined network configuration in our docker-compose.yml.

Problem

The project does not currently include instructions for setting up a development environment.

Description

Add some developer "getting started" steps so it is easy to get the project running locally. Further, a Dockerfile and docker-compose.yml can make it as easy as running docker-compose up to get started developing.

If it is useful, include a devcontainer configuration to run the development server with all requirements.

Additional context

It is useful to run the project locally when developing so that you can see the results of changes.

Implementation

• I would be interested in implementing this feature.

💡 One approach would be to add a develop/ subdirectory in this project with several files:

• docker-compose.yml - Docker services needed to run the project
• Dockerfile - specific configuration environment needed for the project, such as including composer
• php.conf.ini - PHP configuration variables
• .env - used for environment variables such as database credientials

🚧 Work-in-progress

Below are some work-in-progress files that are not yet ready to commit to a new branch.

version: '3'

services:
  wp:
    image: wordpress:latest # https://hub.docker.com/_/wordpress/
    ports:
      - ${IP}:80:80 # change ip if required
    volumes:
      - ./config/php.conf.ini:/usr/local/etc/php/conf.d/conf.ini
      - ./wp-app:/var/www/html # Full wordpress project
      #- ./plugin-name/trunk/:/var/www/html/wp-content/plugins/plugin-name # Plugin development
      - ./:/var/www/html/wp-content/themes/creativecommons-base # Theme development
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: "${DB_NAME}"
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: "${DB_ROOT_PASSWORD}"
    depends_on:
      - db
    links:
      - db

  wpcli:
    image: wordpress:cli
    volumes:
      - ./config/php.conf.ini:/usr/local/etc/php/conf.d/conf.ini
      - ./wp-app:/var/www/html
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_NAME: "${DB_NAME}"
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: "${DB_ROOT_PASSWORD}"
    depends_on:
      - db
      - wp

  pma:
    image: phpmyadmin/phpmyadmin
    environment:
      # https://docs.phpmyadmin.net/en/latest/setup.html#docker-environment-variables
      PMA_HOST: db
      PMA_PORT: 3306
      MYSQL_ROOT_PASSWORD: "${DB_ROOT_PASSWORD}"
    ports:
      - ${IP}:8080:80
    links:
      - db:db

  db:
    image: mysql:latest # https://hub.docker.com/_/mysql/ - or mariadb https://hub.docker.com/_/mariadb
    ports:
      - ${IP}:3306:3306 # change ip if required
    command: [
        '--default_authentication_plugin=mysql_native_password',
        '--character-set-server=utf8mb4',
        '--collation-server=utf8mb4_unicode_ci'
    ]
    volumes:
      - ./wp-data:/docker-entrypoint-initdb.d
      - db_data:/var/lib/mysql
    environment:
      MYSQL_DATABASE: "${DB_NAME}"
      MYSQL_ROOT_PASSWORD: "${DB_ROOT_PASSWORD}"

volumes:
  db_data:

file_uploads = On
memory_limit = 500M
upload_max_filesize = 30M
post_max_size = 30M
max_execution_time = 600

IP=127.0.0.1
DB_ROOT_PASSWORD=password
DB_NAME=wordpress

📝 Todo

• determine how best to include Compose in the project
  • compose seems to be used mainly for the Queulat package, which may be deprecated at some point #69
• change project structure to better organize the development files and separate them from the theme files

Resources

• nezhar / wordpress-docker-compose

Problem

Currently, in the docs directory, we do not have a coding standard enforced, so it is difficult to maintain code consistency.

Description

I want to add the two npm modules eslint and prettier to the project as well as a script to automate linting and code formatting.

Alternatives

• N/A

Implementation

• I would be interested in implementing this feature.

Description

The navigation menu is not visible due to the text being white on a white background:

Reproduction

1. start the development server
2. import the staging content
3. add the CC menu to the main navigation menu location
4. view the front page and notice the menu text is not visible

Expectation

Menu text should be visible and have a high degree of contrast. The menu text should use the default font color, which is a shade of grey.

Description

composer gives the following warning:

Package jakub-onderka/php-parallel-lint is abandoned, you should avoid using it. Use php-parallel-lint/php-parallel-lint instead.

Expectation

Use php-parallel-lint/php-parallel-lint instead

We have a small bugfix release prepared and need to deploy those changes to production.

Problem

Not only do we have some dependency conflicts (#76), we also have some warnings about abandoned dependencies:

Package anahkiasen/underscore-php is abandoned, you should avoid using it. No replacement was suggested.
Package patchwork/utf8 is abandoned, you should avoid using it. Use symfony/polyfill-mbstring or symfony/string instead.

Description

Determine how best to upgrade and clean our project dependencies.

Problem

To test out emails it is also recomended to add a system like mailhog so you read the email on our local development instance without actual sending email by an outgoing smtp server.

Then you you the internal sendmail protocol to send it locally

Resources

• What is MailHog and why may you need it?

Problem

Our default layout currently displays a sidebar. The sidebar renders a page list where the pages are children of the parent:

However, having the sidebar doesn't allow Gutenberg blocks to display full-width.

Description

Determine how best to handle the sidebar menu, such as

• moving it to a custom Gutenberg widget
• using the default Gutenberg page list block (which doesn't allow specifying a root page)
• making the default template have no sidebar and creating a "page with sidebar" theme

Related resources

• Upstream issue WordPress/gutenberg#33883

Problem

We already compile most (if not all) of Bulma into vocabulary-styles. Adding Bulma CDN to projects with vocabulary-styles makes the CSS redundant and a tard annoying to work through problems involving the CSS.
cc @brylie

Currently, the default page template has a container class that adds 24px of the bottom margin. This causes an empty white bar to appear between the page content and the footer.

We added the content class with the idea that it would cause typical HTML elements to behave as expected since Bulma contains a minireset.css that removes HTML default styles like margin and padding.

It is worth considering that our page template already defines main-content and entry-page-content elements that may make the Bulma content class unnecessary in that context.

Task

• determine origin of main-content and entry-page-content classes
• determine how best to remove the 24px bottom margin from the page template(s)
• ensure that default HTML elements from the Gutenberg editor still render as expected

Problem

This project currently defines come custom post behavior for video and gallery posts. In order to define some of the custom post functionality, we use the Queulat project, which we have agreed to deprecate (#69). The project roadmap has now shifted to focus on replacing functionality built with Queulat.

Description

Rather than re-create a custom-code solution for video and gallery posts, we should use the WordPress Gutenberg editor. The Gutenberg editor essentially allows content editors to create arbitrary post types, including video embeds and photo galleries.

There would be several benefits of using Gutenberg

• improved user experience based on thousands of WordPress installations and many releases
• flexibility for editors to define their own content types and layout (i.e. mobile-responsive rows and columns)
• little or no custom code required
• simplify our project dependencies
• Gutenberg is maintained by WordPress core developers and community contributors

Alternatives

One alternative would be to continue to define custom post types. Defining our own custom post types means we need to maintain unnecessary code. It also limits the creative possibilities of content managers.

Additional context

Gutenberg editor was released in 2018 with WordPress 5.0.

Split from #93

@alainseys made the excellent recommendation that we use GitHub actions to test our Docker images. GitHub actions can be triggered by pull requests and can be used as part of the approval process.

We have 2000 minutes a month on the free plan, with additional minutes billed as described on the GitHub billing page.

Problem

• In contribute.md under the heading Recommended Setup for WordPress Coding Standards in item 3 titled Confirm Installation the suggested PATH will not work with linux Ubuntu 20.04 distribution. Instead this one below works:
  export PATH="$HOME/.config/composer/vendor/bin:$PATH"

  • I followed the outlined contributing instructions but as I was using composer to install the php code sniffer instead of creating a .composer folder for the configs the system created a .config/composer directory. The differences in the installation procedure might be either due to differences in OS or its coming up because of updates.

• Prospective contributors are not advised to run composer install after project setup so as to install package dependencies

• In addition to that contributors should be informed that the dependency Quelat will not load automatically despite being a mu-plugin and advised how to proceed. I personally used the composer auto-loader.

Description

I recommend we update contribute.md and add that detail so as to ensure faster on-boarding of linux Ubuntu contributors.

Alternatives

• N/A

Implementation

Edit the docs where there is a problem area, by just adding a statement detailing what would work for Ubuntu users and also by enriching the docs' content so as to make it more intuitive.

• I would be interested in implementing this feature.

Description

Our composer.json contains a requirement for felipelavinz/queulat.

Under the repositories section, we have configured a fork of the queulat package.

For some reason, the queulat dependency does not seem to be installing, since the felipelavinz directory is empty after running composer install, despite the message indicating the archive was extracting:

- Installing felipelavinz/queulat (v2019.4.2): Extracting archive

Reproduction

1. run composer install
2. observe the message "- Installing felipelavinz/queulat (v2019.4.2): Extracting archive"
3. look in the felipelavinz/directory
4. observe there are no files
5. look for a creativecommons/queulat/ directory (from VCS)
6. observe that the creativecommons/queulat project does not seem to have been cloned

Expectation

The queulat dependency would install correctly either from

• felipelavinz/queulat or
• creativecommons/queulat

Additional context

Regardless of whether we decide to deprecate Queulat (#69) it would be useful if the dependency would install correctly.

Issue Description

Please add HTML Comments around the WordPress HTML we want to use other places. These places include:

• Legalcode files
• ccEngine
• FAQ
• Platform Toolkit

This will allows us to extract the header and footer so that they can be updated automatically based on the live header and footer instead of being edited manually in each project.

Related Links

(Please replace this text with any related links.)

Problem

We would like to unify our static documentation deployment to use GitHub Pages.

Description

This project is currently configured to be deployed by Netlify. We would like to use fewer tools related to documentation deployment and want to use GitHub Pages as the primary solution.

Description

Whenever we do a simple yarn install then bugs are reported while when we do a npm install nos uch bugs are found.

Reproduction

1. git checkout docs
2. cd docs
3. yarn install
4. gyp error found

Expectation

Screenshots

Environment

• Device: laptop
• OS: Ubuntu 20.02
• Browser: Chrome

Additional context

Resolution

• I would be interested in resolving this bug.

Description

Until recently, almost every Git repository had a default branch named "master". But thankfully, as part of a movement to make the tech industry more inclusive and open, many software teams and open source projects are moving away from this unhealthy naming.

How To Rename Your Git Repositories From "Master" to "Main"

Alternatives

We could leave the master branch as-is. However, renaming the branch is relatively easy and would be consistent with other repos in the CC org.

• CC WordPress Plugin
• CC chooser
• CC legaldb
• CC licenses

Implementation

• I would be interested in implementing this feature.

Description

would it not be intresting to add a slack channel to github so we can chat while working on issues ?

Add a Slack button to the project README that links to our Slack sign up page:

https://slack-signup.creativecommons.org/

That way other contributors can join the conversation.

Problem

creativecommons-base still uses the old vocabulary imports. We have since separated the vocabulary project into three distinct projects and have published these 3 packages individually.

Description

Update the CDN imports to use the respective latest versions.

Alternatives

Do nothing

Implementation

• I would be interested in implementing this feature.

Problem

We are enabling Gutenberg to control page layout as part of #130

Description

Consider making the Gutenberg full-width template the default. The current default layout contains a sidebar, which may be deprecated in #132

• rename the page.php to template-sidebar.php
  • consider adding grid classes again to control the layout
• rename template-no-sidebar.php to page.php

Alternatives

Additional context

Most of the Figma mockups don't contain a sidebar menu so the menu should not be the default template.

Problem

At some point, we may need to define custom Gutenberg blocks for some of the desired design elements from our Figma mockups. In that case, we may need inspiration or code from other open-source Gutenberg block libraries. One such library is the CoBlocks project, which is fully open-source (no "pro" or "VIP" version.)

Description

If/when it becomes relevant, review the components and source code for CoBlocks project to determine how the components or architecture might be adopted to serve the needs of CC.

Alternatives

It may also be worth researching other fully open-source Gutenberg component libraries.

Problem

By default, WordPress pages have a title. Typically, the page title is hard-coded into the template to define the desired layout. However, the Gutenberg editor also has a "post title" block that allows the content editor to control the placement of the page title. In some cases, we may want to have a pre-defined placement for the page heading, but in others, such as the Home Page, we want to let the user control the placement with the Gutenberg editor.

Description

Determine whether the default page template should have a hard-coded heading placement. If so, create a new template for full control of page layout with Gutenberg's editor. If not, rename the default template to something like "page with static heading" and duplicate the code without the heading part as the default page template.

Additional context

It would be useful to understand what the most common use case would be. I.e., will it be more common for content managers to want to control the placement of the page heading, or is the hard-coded placement desired in most cases? The default template should probably cover most cases, where the content editors would use a secondary template for more rare cases.

Description

I'm getting error while going to use this theme

Reproduction

1. Zip this repo
2. Upload this theme via WordPress dashboard panel
3. Activate the theme
4. See error.

Expectation

Activate the theme and i can modify based on my preference.

Screenshots

Fatal error: Class 'Queulat\Metabox' not found
Screenshot : https://prnt.sc/t8ikzv

Environment

• Device: Laptop
• OS: Windows
• Browser: Chrome

Resolution

• I would be interested in resolving this bug.
• I'd like to contribute on documentation of this theme

Problem

We recently switched to using GitHub pages for hosting static documentation for this project. Now that GitHub pages is enabled, there are a few minor housekeeping and bug fixing tasks.

Description

We want to preserve all content from the previous Gridsome project while removing any Gridsome-specific boilerplate/configuration.

• configure project to use Just the Docs remote theme
• move index page content to /docs/README.md
• move all content to /docs/ root directory
  • /docs/content/* -> /docs/
• double-check markdown content renders correctly (e.g. there may be some broken code blocks or other unneeded texts)
• Make sure all content is available via a navigation menu
  • double-check menu structure from docs/data/settings.json
  • add an auxiliary nagivation link to "CC Open Source"
• preserve structure of /assets/** folder while removing any unused elements
• add the logo to the main template (/assets/img/CC-theme-base.svg) via a theme configuration variable
• Remove all Gridsome / unused code from at least the following locations
  • /docs/.editorconfig
  • /docs/.eslintrc.js
  • /docs/.gitignore
  • /docs/.prettierrc.js
  • /docs/gridsome.config.js
  • /docs/gridsome.server.js
  • /docs/netlify.toml
  • /docs/package.json
  • /docs/data/ directory
  • remove empty /docs/content/ directory (after moving content markdown files)
  • remove /docs/src/ directory after moving content from /docs/src/pages/index.vue to /docs/README.md
• Configure Repository Details: Website with new URL

Additional context

Netlify and Gridsome add unnecessary complexity to this relatively simple static documentation site. The main idea here is to remove unnecessary complexity while preserving the essential content and functionality of the creativecommons-base documentation site.

We want to find the source code for this documentation: https://cc-wp-theme-base.netlify.app/getting-started

We want to ensure the source code is within a CC repository, so that it can be evolved as a developer and/or user guide over time.

Proposal

Merge the docs branch into main to make it easier to find the documentation.

We have completed template designs for all pages on CreativeCommons.org:
https://www.figma.com/file/K6kbDVsx4Zpluhd52yEdDB/Mockups?node-id=1503%3A0

We need to review each of these template designs and determine which ones should be added to the Base theme, and which one to the Child theme for CC.org.

Note, this issue may be updated to include similar listings for other CC sites under construction, such as Certs and CCGN

Problem

1. Production/Staging installation is done via composer
2. composer uses releases
3. current release is grossly outdated

Description

Release a new version

Additional context

• "External" Composer version numbers must be prefixed with v (ex. v0.1.0)
  • Versions and constraints - Composer
  • Git Tags
  • GitHub Releases
• "Internal" Composer version numbers and WordPress version numbers must not be prefixed (ex. 0.1.0)
  • composer.json
  • PHP files
  • WordPress readme.txt
  • etc.

Problem

Our theme currently has a hard-coded layout for the page content area, whereby the layout is specified in columns with column width. For example, there is a sidebar of three columns and a content area of eight columns. The hard-coded layout means that Gutenberg content cannot display full-width.

Description

Remove hard-coded columns in page content areas so that Gutenberg can be used as a page builder.

The icon in the footer donate button needs to be updated to use the cc-letterheart-filled icon.
Update footer.php and component class if needed

Original Issue: creativecommons/vocabulary#589

Problem

We don't currently have a list of CC websites that use creativecommons-base as a base theme.

Description

Add a list of all CC websites that use creativecommons-base as a base theme to the project README

WIP table

The following table shows Creative Commons WordPress projects and indicates whether the theme inherits from creativecommons-base. The table will be used as the basis for the final list of projects inheriting from creativecommons-base and includes negative cases for thoroughness.

The following themes inherit from creativecommons-base:

Additional context

This is related to the possibility of deprecating Queulat (#69), on which this base theme depends.

Problem

@TimidRobot and I were debugging some composer issues on the new certificate server and noticed a discrepancy between the repo name and the composer metadata. One is wp-theme-base, one is wp-base-theme:

https://github.com/creativecommons/wp-theme-base/blob/7d35ff4036ff02fa1227660640f4094c52b1f3bc/composer.json#L2

This is a good opportunity to rename the repository to something else, as described in this issue (private repo).

We will need to think about the consequences of renaming—what site(s) could break, what projects that reference this theme would need to be renamed, etc.

CC @hugosolar @TimidRobot

Implementation

• I would be interested in implementing this feature.

Problem

We have agreed to create an "umbrella" project to combine WordPress themes/plugins related to the creativecommons.org project. The new project repository will primarily consist, at first, of development instructions and environment.

Description

Move or duplicate the developer environment/instructions from this project to the new creativecommons/project_creativecommons.org.

Additional context

We need to get permission from previous contributors, to the development tooling, to make sure it is alright for us to relicense their work under MIT.

Problem

The Post_Metabox is currently defined using the Queulat package.

Since we have established a consensus to deprecate the Queulat package, we need to re-create the Post_Metabox using conventional WordPress code.

Task

• Determine what fields are needed for the Post_Metabox
• Determine how the metadata should be processed and stored
• Re-create the Post_Metabox using conventional WordPress code
• determine whether a more class-name meaningful name would be useful (if applicable)

Problem

Developers currently need to have Composer installed globally on their computers in order to develop this theme.

Description

Installing Composer within the development container would mean fewer development dependencies. Further, the containerized Composer could install the composer dependencies automatically at build time.

Determine how to install Composer within the development container and then run the composer install command during the image build.

Implementation

• I would be interested in implementing this feature.

Problem

The development container currently uses MySQL. However, our production systems tend to use MariaDB.

Description

Change the db layer in the docker-compose.yml to use MariaDB image. Make sure the WordPress layer can still connect to the database.

Problem

The repository root is currently cluttered by a mix of theme files and project metadata (editor config, license, code of conduct, etc.).

Description

Move all theme files to a theme/ subdirectory. That would make the repository root a bit cleaner and separate metadata from the theme files. Likewise, the docs/ subdirectory will soon contain theme documentation that we don't want to publish with the theme (#67)

Alternatives

Additional context

We would need to understand how this theme is intended to be published and included in the CC website deployments. We would only want to include the contents of theme/ in the deployed version of this project.

Implementation

• I would be interested in implementing this feature.

Check for WordPress main classes $wp_scripts & $wp_styles to use them in a custom WP-API endpoint. the goal is to gather styles and script dependencies to be available to use on licenses, FAQ and others non-WordPress websites