boldgrid / boldgrid-theme-framework Goto Github PK

Describe the bug
The menu background color does not touch the sides of screen when container is set to Full Width with Crio.

To Reproduce

1. Activate Crio
2. Make a header layout with a menu in a Full Width container
3. Add a background color to the menu
4. The color does not touch the sides of the screen.

Expected behavior
I expect the color to hit the sides of the screen - be truly full width.
If I remove the left/right padding on the column it looks as expected.

Screenshots

Gulp4 has been out for a while, and addresses some of the shortcomings of gulp3. We use gulp as a taskrunner, and we should upgrade to the latest version so we can keep our deps up to date. Ideally I would like to be able to move from gulp altogether, but I think this would be a good preliminary step where we can re-evaluate some of the build processes happening, and optimize certain portions/pull out others into an alternative workflow.

As we've implemented webpack in v2 of the framework, I think it would be a good next step to look into creating a manifest for assets, and autoloading them in the framework. This would help reduce some of the enqueue's and reduce some of the overhead in various classes that add scripts/register scripts etc.

When selecting southwest alignment, content is aligned east:

I suggest a notice be thrown if the vendor folder is missing because the developer did not run composer.

I am using Crio 2.1
When I have the site background set to a dark color, the 'Set featured image' button and the Page Attributes dropdown are not legible.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

When Parallax is selected, and any background image size isn't set to auto, then there is a gap at the bottom of the screen because the offset is not calculated correctly:

Describe the bug
The color palette help is not displayed

To Reproduce
Steps to reproduce the behavior:

1. Reset help pointers
2. Go to color palette tool in customizer
3. Help pointer does not display

Expected behavior
Color Palette help should display

Desktop (please complete the following information):

• OS: Windows 10
• Browser: chrome
• Version: 72

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Currently our CSS is split up into various parts, and during the build process we don't have any transforms added to create RTL styles. We should look at consolidating some of this CSS, and also look into piping through something like postcss to create RTL styles. Themes would then be able to be tagged as having support for this.

Customizer > WooCommerce > Checkout
I have ‘Highlight required fields with an asterisk’ checked but the asterisks do not show on the page.

Describe the bug
After changing display for customizer icons in sections/panels and the associated headings, they are all wonky. A lot of css was removed and stable, but things aren't stable as there have been many changes since then. The css for this needs to be reevaluated, and perhaps further reduced. Previous selectors were causing some performance impacts as they were chaining together several attribute contains word and attribute contains substring selectors. Reduction has helped a bit in the transition between panels/sections, but the display of these need to be adjusted, and icons need to be "normalized". There's 3 types of icons currently, dashicons, bgtfw icons, and fontawesome - all of which has slightly different positioning/sizing to look out for.

To Reproduce
Steps to reproduce the behavior:

1. go to customizer, switch through various panels/sections - some of the title sections are too small, and some of the panel/section selections are too short.

Expected behavior
These should all be displayed as intended by wp

Desktop (please complete the following information):

• OS: ubuntu
• Browser chrome/ff/ie/safari

Additional context
wp 5.0, wp 5.1

As the framework has grown, it's become clear that we need to begin splitting out our components into their own contained repos. With our controls, we have several intertwined deps, such as Kirki, our own framework/custom controls, and our js controls lib. A good goal to help make this more maintainable as the future of the customizer/WordPress changes to become more JS driven would be to embrace our own controls lib more, and perhaps look at rendering the controls using react as that's what core will be using. This would also allow us to leverage controls available within the editor(gutenberg), so users would have a more consistent interface when working with their sites. This would also give us an opportunity to focus a bit more on controls, and untangling some of the interrelated logic of the previewer, controls, previews and come up with a unified method that is optimized for frontend output as well. We use a variety of different methods at the moment, and it becomes a burden trying to figure out which pieces might conflict with others. while making changes.

One thing we don't do across all of our plugins and themes is coverage of accessibility. This is a pretty important part, especially given the statistics of user who use assistive technology.

One test suite that is worth exploring is AXE, which I have installed the chrome extension to see some of the information and results I could get from it. It does some pretty good general testing, and also provides details on how to fix issues. I think integrating AXE testing in an automated fashion can be done effectively as well.

A toggle to turn off/on the scroll to top arrow functionality in the WordPress customizer would be a nice feature addition.

I think an appropriate place to add this in the customizer would be: "Design > Site Content > Scroll To Top"

This lib is separated out into configs already, so additional controls to handle the many options it has shouldn't be hard to implement. I think for the time being the toggle wouldn't require any adjustments to the library that handles the functionality, but in the future I'd like to add some icon selection, alignment, and color selection options and think we would rewrite this library to use our own implementation and get rid of the third-party dep.

v1 themes have php notice when entering editor in WP 5.1.1(Gutenberg):

Undefined index: body_class in /srv/www/wordpress-two/public_html/wp-content/boldgrid/boldgrid-theme-framework/boldgrid-theme-framework/includes/class-boldgrid-framework-editor.php on line 279.

when wooCommerce is installed, they add their own customizer controls. I'd like to see their icon added to the control so it fits the existing interface choices of all sections/panels having their own icons.

In looking into it, it appears they have an icon font included, so we could use something along the following with their import of the fontface (or enqueue whatever file) & style customizer script:

@charset "UTF-8";@font-face {
    font-family: star;
    src: url(../fonts/star.eot);
    src: url(../fonts/star.eot?#iefix) format("embedded-opentype"),url(../fonts/star.woff) format("woff"),url(../fonts/star.ttf) format("truetype"),url(../fonts/star.svg#star) format("svg");
    font-weight: 400;
    font-style: normal
}

@font-face {
    font-family: WooCommerce;
    src: url(../fonts/WooCommerce.eot);
    src: url(../fonts/WooCommerce.eot?#iefix) format("embedded-opentype"),url(../fonts/WooCommerce.woff) format("woff"),url(../fonts/WooCommerce.ttf) format("truetype"),url(../fonts/WooCommerce.svg#WooCommerce) format("svg");
    font-weight: 400;
    font-style: normal
}

#customizer-section-id? {
    font-family: WooCommerce;
    content: '\e03d';
}

"Nested menu in sticky navigation looses its dropdown indicator and the actual dropdown menu when changing the location of the menu using the Alignment control. Page refresh corrects it."

It seems like the menus aren't being initialized/destroyed properly when the locations are dynamically added/removed.

Firefox Console provided this error:

When using safari 12 the columns seem to be slightly larger than the row and wrap to new lines:

Since the free version doesn't have a global page title control, we're going to hide the option within the editor.

by default smartmenus is keyboard accessible, and follows accessibility standards. They do provide an additional plugin which enhances keyboard support and brings alternative navigation patterns into the menu, such as arrow keys. I think for accessibility focus this would be a good improvement. Some details available here for reference: https://www.smartmenus.org/blog/smartmenus/advanced-keyboard-navigation-and-v0-9-4/

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Going through testing, I noticed that currently the build paths for webpack requires are resolved to the path for /wp-content/themes/prime/inc/boldgrid-theme-framework/. I had added this path in order to resolve imports for patterns, but the issue is/was preexisting just a different path was resolved before. This hasn't caused any conflicts since we switched to webpack because we are generating the output on build, then enqueue them through WP when they are used. All the imports from the entry point where they are enqueued from are resolved relatively to that location, but dynamic imports will look for public paths, __webpack_publicpath__ or runtime paths, __webpack_require__.p. We sometimes run bgtfw from outside of theme directories via defining the constant in PHP, which changes the paths needed to resolve, and during build time, we are building from the directory we install bgtfw to, which we had path.resolve() calls to ensure successful builds. These all result in the wrong paths needed for resolution.

Steps to replicate:

1. Take the current build and put it in a theme called test.
2. Remove any other themes which may have BGTFW installed.
3. Go to customizer > background > images & patterns.

The result is that you will get a console error, and the pattern import will fail and no patterns are shown, just boxes with the current color selected.

Note: the latest .zip release provided on Friday, I did a find & replace to change the resolution paths in the final build, so the dist copy works as intended. This isn't a resolution though as we need the paths to be correct at runtime, so no part of our build process can accurately change them until bgtfw is being implemented wherever that may be. It's possible as a quick fix that build scripts are added in the themes to find replace for theme releases, but I think I'll figure out something a bit more flexible as we wouldn't want someone developing against BGTFW to have a requirement of running a find and replace on a dep. Similar issues happen with create-react-app and other various deps who want the runtime to be dynamically determined. I don't think it will be much work to fix this.

BGTFW should be licensed under GPLv3 instead of GPLv2. See BoldGrid/prime#26 for further information.

I cannot make my WooCommerce pages full width - they do not respond to page or post container control. Please add a control specific for WooCommerce pages or have them respond to the Page container control.

When clicking on the various Home icons in the customizer, there is a noticeable delay before being moved to the main location after clicking on the icon:

Additional information:
BGTFW: v2.1.0
WP: 4.9.8
Tested in: Chrome/FF/Edge

A major setback for the framework is and has been not having solid unit testing being done. I believe at the base level, we at least need to get coverage for phpunit tests across the majority of our codebase. We also need to look at some JS testing, in particular some testing for controls and expected outputs etc.

We should have our color palettes integrated with the Gutenberg editor palette via add_theme_support and updating it based on the user's active palette. This would provide tighter integration of site content colors with the overall color palette selected in the theme.

Describe the bug
In the customizer's dynamic header/footer areas, the widget areas added don't appear when adding new ones if you have no thememods set.

To Reproduce
Steps to reproduce the behavior:

1. Clear thememods for a bgtfw based theme, such as https://github.com/BoldGrid/prime
2. Go to customizer > Design > Footer > Layout
3. Add a widget area to a section.
4. Expand the widget area added, and click on button to go to "Edit Sidebar" for that area.

The result is that the button doesn't take you to the widget area's controls because the control doesn't exist.

Expected behavior
The widget area should exist for dynamically created area.

Note: Possibly related to overriding the render_content method in the parent class. I don't recall this happening before that change.

Desktop (please complete the following information):

• OS: Version 70.0.3538.77 (Official Build) (64-bit)
• Browser: Chrome
• Version 70.0.3538.77 (Official Build) (64-bit)

Additional context
WordPress 5.1

For resource documentation, I couldn't track down icon-newpage.png without asking a bunch of people where they got it from since it's used internally in other applications:

After looking at the image itself, we can just replace this with dashicons-external to avoid doing all that other stuff.

The colorPalette.bind_help_section_visibility has an event listener registered triggering for every click on .accordion-section. This is causing some performance issues as every registered section has listeners registered here:
https://github.com/BoldGrid/boldgrid-theme-framework/blob/dev/src/assets/js/customizer/color-palette.js#L74

I believe this is for an admin notice/pointer - but I think the listener should only be added for the color palettes expanded state to help reduce some of the memory/cpu consumption which is causing slow performance.

It looks like an install with get_option( 'fresh_site' ) === 1 doesn't apply footer link colors to the attribution areas. I believe the classes just need to be added to the filters for that block, but I'm not 100% sure on that off the top of my head.

Describe the bug
The page and post titles do not display since controls were removed into premium.

To Reproduce
Steps to reproduce the behavior:

1. Activate a theme using bgtfw, like prime.
2. view any page/post with thememods cleared.

Expected behavior
Page and post title should be displayed.

Desktop (please complete the following information):

• OS: ubuntu
• Browser chrome/ff
• Version: latest

Additional context
wp 5.1, wp 5.0

In exploration of other themes, and ideas for a better experience for users -- it seems like responsive ombeds are a nice feature to have. One implementation I ran across was https://github.com/Automattic/jetpack/blob/7.1.1/modules/theme-tools/responsive-videos.php/#L102 - which might be something worth implementing within the theme framework.

Describe the bug
Clicking the Edit icon in the Customizer for elements contained in page content displays the 'Go There Now' button as expected. However, the button does not navigate to the Page Editing interface as expected.

To Reproduce
Steps to reproduce the behavior:

1. Open the Customizer in any V1 theme.
2. Click on the Edit icon for page content elements.
3. See the popup containing the 'Go There Now' button directing the user to the page editing interface.
4. Click the button.
5. User is not redirected as expected.

Expected behavior
User should be taken to the page editing interface.

Screenshots

Desktop (please complete the following information):

• OS: Fedora 29
• Browser: Firefox
• Version: 64.0.1

Additional context
This behavior was replicated in Cloud WordPress and on a VPS.

Console also showed this error:

Unsafe JavaScript attempt to initiate navigation for frame with URL 'https://demo2.boldgrid.com/trial-63y0w8z9/wp-admin/customize.php?return=https://demo2.boldgrid.com/trial-63y0w8z9/wp-admin/' from frame with URL 'https://demo2.boldgrid.com/trial-63y0w8z9/?customize_changeset_uuid=a37b7120-a6ec-4066-89e5-1785c545c268&customize_theme=boldgrid-swifty&customize_messenger_channel=preview-0&customize_autosaved=on'. The frame attempting navigation of the top-level window is sandboxed, but the flag of 'allow-top-navigation' or 'allow-top-navigation-by-user-activation' is not set.
Uncaught DOMException: Failed to set the 'href' property on 'Location': The current window does not have permission to navigate the target frame to 'https://demo2.boldgrid.com/trial-63y0w8z9/wp-admin/post.php?post=17&action=edit'.
at HTMLDivElement.d.buttons.(anonymous function) (https://demo2.boldgrid.com/trial-63y0w8z9/wp-content/themes/boldgrid-swifty/inc/boldgrid-theme-framework/assets/js/customizer/edit.min.js?ver=1.2.2:1:1902)
at HTMLButtonElement.d.click (https://demo2.boldgrid.com/trial-63y0w8z9/wp-includes/js/jquery/ui/dialog.min.js?ver=1.11.4:11:6517)
at HTMLButtonElement.dispatch (https://demo2.boldgrid.com/trial-63y0w8z9/wp-includes/js/jquery/jquery.js?ver=1.12.4:3:12444)
at HTMLButtonElement.r.handle (https://demo2.boldgrid.com/trial-63y0w8z9/wp-includes/js/jquery/jquery.js?ver=1.12.4:3:9173)
d.buttons.(anonymous function) @ edit.min.js?ver=1.2.2:1
d.click @ dialog.min.js?ver=1.11.4:11
dispatch @ jquery.js?ver=1.12.4:3
r.handle @ jquery.js?ver=1.12.4:3

On hovering on the ellipsis in pagination, the ellipsis has a hover state like the links to pages:

Expected behavior
The ellipsis should not have a hover state applied, and remain the same visually when a user hovers over it.

Describe the bug
link colors not added in gutenberg

To Reproduce
Steps to reproduce the behavior:

1. Open a page with links in the gutenberg editor.

Expected behavior
The link color should be the same as the front end, but the styles aren't being applied. Hover appears to be applied just not the the default color.

Desktop (please complete the following information):

• OS: ubuntu
• Browser: chrome/ff

Additional context
wp 5.1

Is your feature request related to a problem? Please describe.
Some Headings are too large when viewed on a mobile screen and there is no option to set specific font sizes for various devices.

Describe the solution you'd like
Add controls in the Customizer to allow for site wide defaults to control fonts across the range of devices.

Describe alternatives you've considered
Currently you need to use custom CSS code to address these display problems.

When enabling jQuery Stellar in the customizer, the script is not loaded on the frontend after saving and publishing the site, so the effects are not seen for background images.

Now that we don't have focus on php 5.2+ and require php 5.4+ we can take advantage of composer and/or using an autoloader. This could help with some of the performance hits currently from loading everything when the framework is instantiated.

Describe the bug
If you add a custom header image, the image is not visible on the frontend.

To Reproduce
Steps to reproduce the behavior:

1. go to customizer, and add a header background image.
2. save and publish.
3. view homepage on front end. The image does not appear.

Expected behavior
I expect the header image to visible.

Describe the bug
When the parallax option is set for the Site Background in the Customizer it disables the parallax from working on any boldgrid-section configured in the page content. Using Scroll or Fixed on Site Background does not produce this bug.

To Reproduce
Steps to reproduce the behavior:

1. Go to the Site Background settings in the Customizer
2. Configure an image background with the parallax option
3. Edit a page and set a parallax background for a section in the visual editor
4. View the page from the front end
5. The background for the section will scroll with the content and will not have the parallax behavior.

Expected behavior
Parallax backgrounds in the page content should function regardless of the Site Background settings.

Desktop:

• OS: Fedora 28
• Browser: Firefox, Chromium

I have an item in my cart. When I change the quantity to 4 and click Update Cart, when the page reloads the minus button isn’t clickable until I click the plus button.

It appears that header/footer sections are inheriting the font style declared by bootstrap.css. These areas should inherit the customizer control for "Main Text", so that the user is able to change these.

Additional Information:
BGTFW: 2.1.0
WP: 4.9.8
Tested in: Chrome/FF/Edge

Right now the Store Notice appears at the bottom of the page - it should be at the top. Header Top position.

This is related to #78 where a toggle was introduced for the scroll to top arrow functionality for a site. To help address usability it was suggested to add a customizer edit button to the scroll to top arrow in the customizer preview, so users can easily turn it on/off.

Add background overlay effects for background images in customizer.

Given increased browser support of background blend modes, I think a nice feature would be to add different background blend mode effects for background image overlays in the customizer to give a little more diversity.

Initially most controls didn't exist in previous versions, and as a measure to counteract some of the "missing" theme_mods during the transition periods for testers - additional CSS has been added to adjust for certain things missing and still displaying without any mod correctly. For the most part this has worked out, but there are a couple of small alignments and color configurations that I think need to be moved into @rramo012 's implementation in the theme_mod array for the configs. I believe doing this should resolve the slight discrepancies, and also help ensure seamless upgrade/downgrades without users having certain settings disappear unintentionally.

For browserstack support we need to add the image and link to their website and let others know we use them for browser testing coverage.