bluehost / bluehost-wordpress-plugin Goto Github PK

Summarize the issue (briefly)
Will this get auto-added to our project?

Currently, we are using Cypress version 7.1.0. We should upgrade to the latest version. This has the added benefit of ensuring that we can use Replay.io with our project.

Right now, we simply test our code in a single version of WordPress on a single version of PHP. We should be testing in multiple versions of each. Implementing a matrix in GitHub Actions would allow us to do this, although there may be some implications as far as build time costs.

Update from using the plugin updater module to using the wp-forge updater as we have in the other brand plugins. This will remove the dependency on having the endurance module loader.

Replace:
https://github.com/bluehost/endurance-wp-plugin-updater
with:
https://github.com/wp-forge/wp-update-handler

Describe the solution you'd like

Describe alternatives you've considered

Additional context

PHP Fatal error: When accessing the Menu option on the dashboard "There has been a critical error on this website" is displayed

Steps to reproduce

1. Go to Wordpress Dashboard.
2. Hover over Appearance and Click on Menu.

Debug Error
PHP Fatal error: Cannot declare class Bluehost\Data, because the name is already in use in... ///public_html/*****/wp-content/plugins/bluehost-wordpress-plugin/inc/Data.php on line 14

Bluehost Plugin Version:

• Version: 3.1.0

Browser (with version) & Operating System (with version)

• Browser: Firefox 116.0.3
• Operating System: Windows 11 Home
• Device: PC

Hi there,
It seems that the plugin is causing a redirect to the bluehost admin page for all users upon login. This causes non admin users to be shown a screen saying they are not permitted on this page.
This was seen on https://unswoc.org/wordpress/ but the plugin has now been disabled.
This was an issue before the last major release (->3.x.x) but after that update the issue seemed to go away and was only noticed again now.

Summarize the issue (briefly)

Steps to reproduce

1. signup for bluehost shared
2. create staging site
3. click the radio button to switch sites
4. you should see the transparent takeover screen
5. page redirects to a 404

Remove performance code and add performance module. If required update module to ensure no features are lost. Performance settings interface and hooks/events will need updating.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
Previously, the plugin had a dashboard widget that displayed recent posts from the Bluehost blog. It was disabled because when the blog migrated to the new site the connection broke.

Describe the solution you'd like
We should be able to update the code to point to the new blog fairly easily.

Describe alternatives you've considered
This may be something we don't end up fixing and can remove the code altogether. Open to discussion, depending on how useful customers found the widget and the investment to fix when we no longer manage the blog site.

If we're going to fix it, let's go ahead and migrate this functionality into a module. Ideally, we can load the module and pass in an RSS feed to any brand's blog so it can be brand specific. Hopefully, it's not a huge lift and can be a nice little module to expose brand blogs within the dashboard.

Additional context

Summarize the issue (briefly)

Currently, the Cypress tests run but sometimes the GitHub Action never completes. This may be due to the degradation of Github's services. Either way, we should set timeout limits on the actions to prevent them from running for up to 6 hours before timing out.

https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepstimeout-minutes

For Jarvis sites, it appears the "Bluehost Account" link is pointing to the wrong location. I believe this stems from cpanel not understanding how to redirect properly after login.

The correct URL for Jarvis sites should be this: https://www.bluehost.com/my-account/hosting/details

This was reported by Chris Pond. Check with him if you have questions about proper situations and destination.

Investigate the secure passwords module for compatibility with newfold module loader.

https://github.com/bluehost/wp-module-secure-passwords

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Remove all notifications code and use the notifications module. If required update the notifications module to ensure no feature loss.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Just testing an integration

Investigate Business Reviews and if it's compatible with the newfold module loader.

https://github.com/bluehost/endurance-wp-module-business-reviews

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Summarize the issue (briefly)
Update the plugin's JavaScript dependencies and address security issues (https://github.com/bluehost/bluehost-wordpress-plugin/security/dependabot).

Summarize the issue (briefly)
CTB modal windows are not very mobile friendly, the edges of the modal get cut off pretty severly on screens smaller than 500px.

Steps to reproduce

1. Open a CTB modal
2. Be on small screen
3. See edges left and right get cropped off. Including image and copy.

Expected behavior
These should be flexible and have a max-width of around 5-600px and on mobile have a max width of 90-100%

Screenshots

Bluehost Plugin Version:

• Version: 2.11.7

Browser (with version) & Operating System (with version)

• Browser:
• Operating System:
• Device: All small

Additional context
This is in the ctb.css file, so it seems to be affecting every CTB, otherwise we could fix in a hiive template.

Summarize the issue (briefly)

Currently, the Bluehost plugin doesn't work on VPS accounts.

Specifically, staging isn't compatible. I requested that the exec function be enabled on VPS and Chris Miles created a JIRA ticket for this.

Is your feature request related to a problem? Please describe.
Moving the test code into the module where the code lives will help manage tests from the source rather than having every test duplicated in each brand plugin.

The workflow for tagging a module update needs to include running tests locally to ensure they all pass, so that when the module update PR in the plugin runs the tests will pass and we can avoid a series of module releases that fix broken tests not found until the plugin PR is created.

Once tests are all moved to the module level we'll look at how we can automate the module PRs running the tests too. Perhaps we can use the blueprint plugin as a container or use a componentized environment for the module.

Describe the solution you'd like
The tests should be removed from the plugin and added to the module. The cypress config should also be updated to look for tests in the modules and add an environment variable for plugin-specific things like brand plugin id for urls. Any fixtures specific to the test should also be moved into the module.

Modules that have migrated:

• CTB
• Coming Soon
• Staging
• Marketplace (with premium plugins tab test)
• Notifications

Modules that need tests migrated:

• Onboarding

Modules that should have e2e tests written and added:

• Ecommerce
• Patterns
• Help Center
• Performance

Describe alternatives you've considered

Additional context

Replace the endurance SSO module with the newfold SSO module.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Summarize the issue (briefly)

When I deploy from my staging site to my production site, my production .htaccess file gets overwritten. That file contains the rule that redirects HTTP requests to HTTPS; but when the file gets overwritten, the rule disappears, and I have to re-add it manually.

It also doesn't seem to matter if I add the rule to the staging .htaccess file; it doesn't get copied over to production (or at least, the HTTP-to-HTTPS redirection rule doesn't get copied over).

Steps to reproduce

1. Make changes to both staging and production .htaccess files to include (for example) an HTTP-to-HTTPS redirection rule.
2. In the Wordpress settings, navigate to the Bluehost plugin's Staging page.
3. Click the "Deploy all changes" button.
4. Notice that the HTTP-to-HTTPS redirection rule is now gone from the production .htaccess file and that visiting the production site using HTTP fails to redirect to HTTPS.

Expected behavior

I expect changes that I make to both staging and production .htaccess files to persist after deployment. I understand that there are probably good reasons for overwriting certain values in the production .htaccess file, but it'd be nice if there was at least one section of the file that was specifically for rules that would not be overwritten, like:

# ==========
# Put some custom rules here:

# ==========

# %%%%%%%%%%
# Do NOT change these values; they're overwritten automatically during deployment!

# %%%%%%%%%%

# ==========
# Put some more custom rules here:

# ==========

Bluehost Plugin Version:

• Version: 2.12.13

Thanks!

Remove PHP 5.2 support. Move to supporting PHP 5.6 (update PHP version for our Bluehost coding standards as well)

Fatal error since last update.

I'm with SatelliteWP, a maintenance service for WordPress websites owners. We don't directly use your services but some potential clients contacted us. I do not have more information about what happened. I see many people on Twitter complaining too so I'm opening this ticket in hope that you can help your clients ASAP. :-)

Warning: Undefined variable $bh_data in /home2/xxxx/public_html/wp-content/plugins/bluehost-wordpress-plugin/vendor/bluehost/bluehost-wp-customer-data/includes/Customer.php on line 42

Fatal error: Uncaught TypeError: array_key_exists(): Argument #2 ($array) must be of type array, bool given in /home2/xxxx/public_html/wp-content/plugins/bluehost-wordpress-plugin/vendor/bluehost/bluehost-wp-customer-data/includes/Customer.php:45 Stack trace: #0 /home2/xxxx/public_html/wp-content/plugins/bluehost-wordpress-plugin/vendor/bluehost/bluehost-wp-customer-data/includes/Customer.php(45): array_key_exists('plan_subtype', false) #1 /home2/xxxx/public_html/wp-content/plugins/bluehost-wordpress-plugin/vendor/newfold-labs/wp-module-onboarding/includes/Data/Data.php(116): Bluehost\WP\Data\Customer::collect() #2 /home2/xxxx/public_html/wp-content/plugins/bluehost-wordpress-plugin/vendor/newfold-labs/wp-module-onboarding/includes/ModuleController.php(31): NewfoldLabs\WP\Module\Onboarding\Data\Data::customer_data() #3 /home2/xxxx/public_html/wp-includes/class-wp-hook.php(305): NewfoldLabs\WP\Module\Onboarding\ModuleController::module_switcher() #4 /home2/xxxx/public_html/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters(NULL, Array) #5 /home2/xxxx/public_html/wp-includes/plugin.php(476): WP_Hook->do_action(Array) #6 /home2/xxxx/public_html/wp-settings.php(576): do_action('after_setup_the...') #7 /home2/xxxx/public_html/wp-config.php(101): require_once('/home2/xxxx...') #8 /home2/xxxx/public_html/wp-load.php(50): require_once('/home2/xxxx...') #9 /home2/xxxx/public_html/wp-blog-header.php(13): require_once('/home2/xxxx...') #10 /home2/xxxx/public_html/index.php(17): require('/home2/xxxx...') #11 {main} thrown in /home2/xxxx/public_html/wp-content/plugins/bluehost-wordpress-plugin/vendor/bluehost/bluehost-wp-customer-data/includes/Customer.php on line 45

Summarize the issue (briefly)
Today a plugin update was causing my site to throw a fatal error.

When I logged in using the recovery mode link in the admin email, I was redirected to the Bluehost dashboard instead of the dashboard screen, the default when the plugin is active and no redirect is requested.

This is problematic because all admin notices are hidden on the Bluehost screen and Recovery Mode displays multiple admin notices to help guide the user.

A recovery mode links seem to use the action query parameter instead of the redirect_to one.

Steps to reproduce

1. Set up a site and activate another plugin.
2. Create a fatal error.
3. Try to enter recovery mode.
4. Get redirected to BH screen on login instead of the plug

Expected behavior
User is redirected to the Plugins screen in order to troubleshoot the issue.

Screenshots
Default behavior.

Bluehost Plugin Version:

• Version: 2.12.5

Browser (with version) & Operating System (with version)

• Browser: Firefox
• Operating System: MacOS
• Device: Macbook Pro

Additional context

Currently, all of our tests are at the plugin level. We would like any tests related to our modules to be stored in the module repos and then run as part of the plugin-level tests. Any non-module or additional custom tests would be stored directly in the plugin.

https://www.youtube.com/watch?v=96Yn_IiQUJI

We can run groups of tests from the CLI by defining multiple --spec flags:

cypress run --base-url http://localhost:3000 --spec vendor/cypress/integration/**/*.js --spec tests/e2e/**/*.js

In order to avoid Composer autoloading package version conflicts when other popular plugins use the same package at a different version, we will use Imposter to ensure our vendor packages are wrapped in a custom namespace.

Is your feature request related to a problem? Please describe.

Currently, we set a $container->get('plugin')->id, which gets passed as origin to the Hiive. We also send a brand property to the Hiive, which is the value of the mm_brand (soon to be nfd_brand) option. As such, we are getting a lot of empty brand values.

Describe the solution you'd like

We need to make sure we set the passed brand as either not empty, or we need to update the empty brand property to match the origin (plugin ID).

Summarize the issue (briefly)

Currently, we are running wp-env at version 4.0.2, but the version on NPM is 4.9.0.

There is an issue in the version we are using where we have to manually define the WordPress version to get it to install the latest version. Obviously, as new versions of WordPress come out, this requires that we manually update the version. It is unclear if the latest version of wp-env will properly install the latest version or not, but is something we should try.

Is your feature request related to a problem? Please describe.
As discussed in this PR: #651 (review), we could potentially use a partner module that deals with partner settings and code (woo, jetpack, toast, etc) for all plugins in one module rather than copying code to each plugin.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
Currently the plugin uses a local UpgradeHandler class, let's update it to use the one from https://github.com/wp-forge/wp-upgrade-handler. This will give us consistency across plugins and we can remove this class from the plugin source.

the new tool follows the same pattern of using a dir of upgrade routines so we will continue that practice.

Describe the solution you'd like

• Remove inc/UpgradeHandler.php from the plugin.
• Add wp-forge/wp-upgrade-handler package.
• Set up the UpgradeHandler instance.

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
In order to migrate to the newer plugin blueprint we need to move any one-off code from this plugin into a module for reuse in other brand plugins.

Describe the solution you'd like
We need to build a staging module that will recreate the staging functionality currently found in the Bluehost plugin. This will need to support legacy as well as isJarvis sites.

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

Right now, this is what will trigger a build of the plugin:
https://github.com/bluehost/bluehost-wordpress-plugin/blob/master/.github/workflows/upload-artifact-on-push.yml#L1-L6

As a result, we must merge into master to create a build. We need to update this to allow triggering a build in the following additional contexts:

• develop
• feature/*

Is your feature request related to a problem? Please describe.

There are typically a few flaky tests that fail when running the full testing matrix. When these fail, we have to re-run the failed jobs to make sure everything is passing.

Describe the solution you'd like

We should implement automatic retries (at least one retry) for failed tests.

This is how WordPress has implemented it:

• https://github.com/WordPress/wordpress-develop/blob/trunk/.github/workflows/failed-workflow.yml
• https://github.com/WordPress/wordpress-develop/blob/trunk/.github/workflows/phpunit-tests.yml#L233-L260

Is your feature request related to a problem? Please describe.
In order to migrate to the newer plugin blueprint we need to move any one-off code from this plugin into a module for reuse in other brand plugins.

Describe the solution you'd like
We need to create a new wp-module-ctb module that contains all ctb functionality as is. Once we migrate to Jarvis we can simply update the module and can use it in any isJarvis sites.

Describe alternatives you've considered
Alternatively, we could sunset the CTB as sites are migrated since they will need to be rebuilt for Jarvis, but getting it into a module is something we can do now and then we are not blocked on migrating the plugin by hosting migrations.

Additional context

Is your feature request related to a problem? Please describe.
In order to migrate to the newer plugin blueprint we need to move any one-off code from this plugin into a module for reuse in other brand plugins.

Describe the solution you'd like

• CTB: #379
• Performance: #162
• Staging: #383
• Tour/Defaut Content #381 (potentially sunset this in favor of onboarding and patterns)
• Dashboard widget: #382 (can skip this for now since it's not an active feature)

Describe alternatives you've considered

Additional context

It looks like other user roles than administrator are also redirected to admin.php?page=bluehost#/home

which gives them a 'sorry you are not allowed to access this page' error message because they don't have capability to access that page.

There's possibly something to look into while checking administrator role.

Is your feature request related to a problem? Please describe.
The performance module is in place and now has components for plugins to use. This plugin still has the plugin-based component and should load the module-based component.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Once all dependencies are updated and/or removed, remove the old module loader package.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

We should have tests that will check various instances of customer data.

• Check with mocked api response data
• Check that installer provided options are properly read and stored.
• Check that older transient stored data gets updated properly.
• Check that new data is requested after soft expiration.
• Check that broken cdata is not stored.

Summarize the issue (briefly)

Is your feature request related to a problem? Please describe.
Currently, we are using wp-scripts v14.1.1. The other plugins are using wp-scripts v19.2.2 and the latest as of today is 24.2.0. Let's get these in sync at least and at best updated to latest so we can stay updated better. This will affect our build process, so we'll need to take care that the build doesn't break and we can still manage the multiple entry points and apps in the plugin.

Describe the solution you'd like
Ideally, we can update wp-scripts in this plugin to at least the version we have in the other plugins. We can also update the build process to closer reflect the process in HG and Web plugins which is more modern and more simple.

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

Currently, the plugin is using the mm_brand option instead of the nfd_brand option (Mojo instead of the NewFold prefix).

Describe the solution you'd like

We need to update the plugin to use the nfd_brand and remove all instances where mm_brand is used. However, we should add a filter to the nfd_brand option to use the value from mm_brand, if present, when nfd_brand is empty.

Is your feature request related to a problem? Please describe.
In order to migrate to the newer plugin blueprint we need to move any one-off code from this plugin into a module for reuse in other brand plugins.

Describe the solution you'd like
Move Tours and Default Content to a module and pull into this plugin.

Describe alternatives you've considered
Possible that this functionality is sunset in favor of cloud patterns and onboarding efforts. This is open for discussion and further discovery.

Additional context

You could have added a description of how to use the plugin.
And why is it not on the plugins page on Wordpress?

Remove coming soon code and add coming soon module. If required update module to ensure no features are lost. Coming soon settings interface and hooks/events will need updated as well and a coming soon template will need to be customized.

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
Currently, if the active theme is FSE, the customize my site links route to the legacy customizer, where no options exist to edit the site.

Describe the solution you'd like
Detect if the active theme is an FSE theme and route onboarding links to the new site editor experience.

Cleaning up some technical debt and consolidating all plugins to using the same code base.

We need to remove all the "old" modules and migrate to the new ones.

• #140
• #141
• #142
• #162
• #163
• #164
• #165
• #166

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.
It's hard to keep dependencies up to date!

Describe the solution you'd like
By adding a Dependabot YML file, PRs for GHA updates can be created automatically. This will help us be better about keeping these actions updated, much like Dependabot does for NPM or Composer dependencies by default.

Describe alternatives you've considered
Manually checking for updates every so often.

Additional context
This could also create too much noise, and I know some people do not like Dependabot alerts as they can become annoying if too many updates become available in a short period of time. But I think it could be nice to keep an eye on the actions we utilize.

WordPress Core currently has a version of this configuration file for this purpose.

See also: dependabot.yml documentation.

Summarize the issue (briefly)

When Max Mega Menu and the Bluehost plugin are enabled together, a fatal error is triggered on the Appearance > Menus page.

Steps to reproduce

1. Install the Bluehost plugin
2. Install Max Mega Menu
3. Go to Appearance > Menus
4. See/experience error

Expected behavior

nav-menus.php loads as expected.

​The problem starts here:
​
​https://plugins.trac.wordpress.org/browser/megamenu/tags/3.2.2/megamenu.php#L169
​
​Which is a line of code that loads all of the assets from widgets.php onto the nav-menus.php page. We need this in order to be able to add and edit widgets in the mega menu builder on nav-menus.php, and usually it works just fine. When the Bluehost plugin is installed, it triggers this error:
​
[07-Aug-2023 09:20:51 UTC] PHP Fatal error: Cannot declare class Bluehost\Data, because the name is already in use in /Users/tom/***/app/public/wp-content/plugins/bluehost-wordpress-plugin/inc/Data.php on line 20 [07-Aug-2023 09:20:51 UTC] PHP Stack trace: [07-Aug-2023 09:20:51 UTC] PHP 1. {main}() /Users/tom/***/app/public/wp-admin/nav-menus.php:0 [07-Aug-2023 09:20:51 UTC] PHP 2. require_once() /Users/tom/***/app/public/wp-admin/nav-menus.php:694 [07-Aug-2023 09:20:51 UTC] PHP 3. do_action() /Users/tom/***/app/public/wp-admin/admin-header.php:118 [07-Aug-2023 09:20:51 UTC] PHP 4. WP_Hook->do_action() /Users/tom/***/app/public/wp-includes/plugin.php:517 [07-Aug-2023 09:20:51 UTC] PHP 5. WP_Hook->apply_filters() /Users/tom/***/app/public/wp-includes/class-wp-hook.php:332 [07-Aug-2023 09:20:51 UTC] PHP 6. Mega_Menu->admin_enqueue_scripts() /Users/tom/***/app/public/wp-includes/class-wp-hook.php:308 [07-Aug-2023 09:20:51 UTC] PHP 7. do_action() /Users/tom/***/app/public/wp-content/plugins/megamenu/megamenu.php:169 [07-Aug-2023 09:20:51 UTC] PHP 8. WP_Hook->do_action() /Users/tom/***/app/public/wp-includes/plugin.php:517 [07-Aug-2023 09:20:51 UTC] PHP 9. WP_Hook->apply_filters() /Users/tom/***/app/public/wp-includes/class-wp-hook.php:332 [07-Aug-2023 09:20:51 UTC] PHP 10. NewfoldLabs\WP\Module\Runtime\Runtime->register_runtime() /Users/tom/***/app/public/wp-includes/class-wp-hook.php:308 [07-Aug-2023 09:20:51 UTC] PHP 11. NewfoldLabs\WP\Module\Runtime\Runtime->prepareRuntime() /Users/tom/***/app/public/wp-content/plugins/bluehost-wordpress-plugin/vendor/newfold-labs/wp-module-runtime/includes/Runtime.php:60 [07-Aug-2023 09:20:51 UTC] PHP 12. apply_filters() /Users/tom/***/app/public/wp-content/plugins/bluehost-wordpress-plugin/vendor/newfold-labs/wp-module-runtime/includes/Runtime.php:41 [07-Aug-2023 09:20:51 UTC] PHP 13. WP_Hook->apply_filters() /Users/tom/***/app/public/wp-includes/plugin.php:205 [07-Aug-2023 09:20:51 UTC] PHP 14. Bluehost\Admin::add_to_runtime() /Users/tom/***/app/public/wp-includes/class-wp-hook.php:308
​
I think this could be fixed by adding some "class_exists" checks to make sure it can't be loaded twice(?)