humanmade/altis-media 2.0.1 is installing Safe SVG to the plugins folder as PR #52 of Altis Core has not been released.

I don't think apply_filters() and related functions are available when the installer runs but if they are, is it possible to add a filter to the plugin list to allow modules to add their own plugins to be installed in the vendor folder?

Steps to reproduce:

1. Run an install or composer update using Composer v2
2. Browse to the About page from the Altis logo menu dropdown
3. Everything is undefined and warnings are thrown

The page should work as before showing the versions of all modules and all dependencies.

Acceptance criteria:

• About page is functional after an install with Composer v2

Steps to reproduce:

1. Disable the global media library via global-media-library: false in composer.json
2. Run composer server cli -- altis migrate to upgrade from a version prior to v9
3. Observe that the global media library site is still created even though it's not needed and won't be used

If a module configuration is set to a boolean value eg. false to turn it off there's a merge error and a warning thrown.

We need to check the type of the value of $settings in the following lines:

If the type is a boolean then the value should be set to:

$settings = [
    'enabled' => settings
];

If the type is anything other than a boolean or array then we should trigger a warning using trigger_error( ..., E_USER_WARNING ) indicating which module settings are broken and then continue; the loop.

Acceptance criteria:

• Setting a module in composer.json config to true or false should not trigger an array_merge warning
• A boolean value set for a module in composer.json should be used as the enabled setting value

Original iisue

Similar to this issue, I'm seeing this error from the site's PHP logs:

PHP Warning:  array_merge(): Argument #2 is not an array in /chassis/vendor/altis/core/inc/namespace.php on line 83

Here's the snippet of the project's composer config:

{
  "extra": {
     "altis": {
      "modules": {
        "media": {
          "smart-media": false,
          "tachyon": false
        },
        "workflow": false,
        "seo": {
          "redirects": false
        },
        "analytics": {
          "native": {
            "experiments": {
              "titles": false
            }
          }
        }
      }
    }
  }
}

The Altis telemetry opt-in panel renders on the edit post and edit page screens before disappearing when the react app renders. It should probably not render on these pages (maybe only on the dashboard).

Steps to reproduce:

1. Log in to a new Altis site without having opted in or out to Altis telemetry
2. You should see the opt-in panel displayed. Don't click it.
3. Click to edit a post or page
4. The opt-in panel displays again then is obscured by the editing interface.
5. This also occurs when clicking edit post or edit page from the front end where is seems more jarring.

I wouldn't expect to see the opt-in panel display on these screens at all.
Optionally, maybe only display it on the dashboard.

https://images.zenhubusercontent.com/173866019/1f546770-a5b4-4711-b433-dee623f5becf/altis_admin_stats_optin_hb.mp4

Acceptance criteria:

• The panel should not appear on the edit post or edit page screens.

The function Altis\Cloud\get_main_site_url() should really be at a lower level as it has more general usefulness and doesn't quite make sense under the Cloud namespace specifically.

It should be moved to this module under the Altis namespace directly then the Cloud module version deprecated.

Steps to reproduce:

1. On a clean Altis v8 install add a custom module with an entry point file based on loading custom module docs here
2. Run composer dump-autoload
3. Open https://subdomain.altis.dev/wp-admin/

Reproduced on both ARM64 & Intel Mac installs of the same project.

Site does not load and the following PHP Fatal is displayed:

Fatal error: Uncaught Error: Class 'Yoast\WP\Duplicate_Post\Admin\Options_Page' not found in /usr/src/app/vendor/yoast/duplicate-post/duplicate-post-options.php:21 
Stack trace: 
#0 /usr/src/app/vendor/yoast/duplicate-post/duplicate-post-admin.php(13): require_once() 
# humanmade/altis-seo#1 /usr/src/app/vendor/yoast/duplicate-post/duplicate-post.php(104): include_once('/usr/src/app/ve...') 
# humanmade/altis-seo#2 /usr/src/app/vendor/altis/workflow/inc/namespace.php(67): require_once('/usr/src/app/ve...') 
# humanmade/altis-seo#3 /usr/src/app/wordpress/wp-includes/class-wp-hook.php(292): Altis\Workflow\load_duplicate_posts('') 
# humanmade/altis-seo#4 /usr/src/app/wordpress/wp-includes/class-wp-hook.php(316): WP_Hook->apply_filters(NULL, Array) 
# humanmade/altis-seo#5 /usr/src/app/wordpress/wp-includes/plugin.php(484): WP_Hook->do_action(Array) 
# humanmade/altis-seo#6 /usr/src/app/wordpress/wp-settings.php(358): do_action('muplugins_loade...') 
# humanmade/altis-seo#7 /usr/src/app/wp-config.php(80): require_once('/usr/src/app/wo...') 
# humanmade/altis-analytics#4 /usr/src/app/wordpress/wp-load.php(42): require_once('/usr/src/app/wp...') 
# humanmade/altis-seo#9 /usr/src/app/wordpress/wp-admin/admin.php(34): require_once('/usr/src/app/wo...') 
# humanmade/altis-seo#10 /usr/src/app/wordpress/wp-admin/index.php(10): require_once('/usr/src/app/wo...') 
# humanmade/altis-seo#11 {main} thrown in /usr/src/app/vendor/yoast/duplicate-post/duplicate-post-options.php on line 21
Fatal error: Uncaught Error: Class 'Yoast\WP\Duplicate_Post\Admin\Options_Page' not found in /usr/src

Acceptance criteria:

• Custom module entrypoints are loaded
• composer dump-autoload runs without error
• Site does not produce a fatal error

Should contain:

• Version
• Module versions
• License information
• Stack specs
• Docs / resources links

This could potentially show some information we previously had on the cloud page UI such as latest deployment but not a hard requirement right now.

We want to add support for PHP sessions in multi-server configuration. By default, PHP stores sessions on the disk, which won't work properly with autoscaling. The typical place these are offloaded is into the object cache, i.e. Redis.

This is useful for ecommerce sites which use sessions for storing cart information, but is only very rarely used outside of these sites.

One option is WP Session Manager, a plugin that enables support for PHP sessions using Redis.

https://github.com/ericmann/wp-session-manager

This would have implications for the cacheability of the site, and we need to check that session IDs are correctly passed through the CDN to the backend. This may require us to reconfigure the cookie name in PHP (by default SESSIONID I think?).

We should include this capability and provide the Redis integration if it is enabled in the cloud module.

The below example changes the title, path and domain of the site created. These could also be edited via the network admin as well:

https://github.com/humanmade/altis-core/blob/master/docs/global-content-repository.md

The example below changes the title, path and domain of the site created. These could also be edited via the network admin as well:

Steps to reproduce:

1. Opt out of personal data collection in Telemetry
2. Observe ID is 32303231

We're using bin2hex and then truncating this value, however the value is a datetime so we're just getting a hex representation of 2022 (or 2021). 🤦

Acceptance criteria:

• Different anonymous users have unique IDs

Looking at #21, managing nested JSON configuring multiple environments is somewhat error-prone. Long-term it could be interesting to provide a visual configuration editor similar to how VS Code has evolved the interface for user and workspace settings:

At minimum directing people to make config changes through an editor would give us a place to validate the shape of the config at the time it is being edited or saved, which would reduce the lag between "make edit" and "see error" which might be experienced if you configure a bunch of things then try to run the site and see an error.

As of Altis v10 the new insights dashboard enabled by default replaces the standard dashboard where we show the upgrade notice for Altis versions out of Long Term Support.

We need to update to an approach that will work regardless of whether the dashboard is overridden at all.

Acceptance criteria:

• Upgrade notice should always show regardless of dashboard being used
• Upgrade notice should be styled according the dashboard it is shown on, screenshots to come

This ticket addresses the issues raised by the documentation linting

composer dev-tools lintdocs all -l packages/core

File Issues:

None

Markdown issues:

Linting: 4 file(s)
Summary: 126 error(s)

Style issues:

22 errors, 0 warnings and 0 suggestions in 4 files.

https://github.com/roots/wp-password-bcrypt

Steps to reproduce:

1. Newly installed altis v12-beta1 php 8.0
2. installed twentytwentytwo theme
3. Activated theme
4. Got 500 error in browser. On invesitgation this was an out of memory error.

I expected the theme to activate without an error

See log entry below:

altis-upgrade-test-php  | [21-Jul-2022 13:55:36 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /usr/src/app/vendor/humanmade/wp-redis/object-cache.php on line 627
altis-upgrade-test-php  | [21-Jul-2022 13:55:36 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /usr/src/app/vendor/humanmade/aws-xray/inc/namespace.php on line 90
altis-upgrade-test-php  | [21-Jul-2022 13:55:36 UTC] PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in Unknown on line 0

Note. Activating a second time went ok. with no error. This may be a transient issue

Inform users that when using content from the Global Content Repository, that the URL's will be relevant to the Global Content Repository and not the site it's being displayed on.

The Altis About page has 2 tabs, but they have no relation to their contents. e.g. the credits tab has no credits, but instead lists composer packages. The about tab doesn't say anything about Altis and just lists the modules and their versions. The credits tab actually has a sentence about Altis. A graphic would also make this page a little friendlier

Suggestions:

• Put an Altis logo on "Powered by Altis"
• re-align the main/sub headings and the table so they align horizontally better to the left
• Rename the About tab to Modules
• Rename Credits to Packages
• Add an initial Altis tab with a logo and a description of what it is, the paragraph on the credits tab is already most of the way there

I'm getting the following warning in WordPress dashboard.

Currently happening in Orgvue development but I haven't gone to the bottom of the issue and I don't know exactly why it complains about it because Local Chassis is not installed in development or production

When running Composer 2.3.0 released today the Altis installation breaks with the following message:

In class-plugin.php line 124:
                                                                                              
  [Error]                                                                                     
  Cannot access protected const Composer\DependencyResolver\Operation\InstallOperation::TYPE 

We need to fix this asap as Travis builds are all using the latest version and breaking.

There seem to be problems with some other projects too:

• composer/composer#10672
• composer/composer#10671

Updating Altis requires running composer update twice, due to our use of the installer location overrides and the load order of Composer plugins. This subverts user expectations, and often leads to fatal errors which aren't necessarily caught.

Steps to reproduce:

1. Install Altis v4
2. Upgrade to Altis v5 using composer update
3. Observe humanmade/post-cloner is installed to the wrong location
4. Run composer update again
5. Observe humanmade/post-cloner is installed to the right location

(Repeat for any major versions as required)

Users should not need to install twice, and files should be placed into the right location after running composer update once.

Acceptance criteria:

• ...

Currently I believe there's nothing to stop telemetry data being sent to Segment in automated testing. Because those automated tests will typically use a fresh DB on run, with new users, we are blowing past our MTUs in Segment, costing us a lot.

We should probably at least detect if the php_sapi_name() is CLI, or alternatively only fire Telemetry on web-requests (by looking for $_SERVER headers etc).

Needs a defined() check: https://github.com/humanmade/altis-core/blob/master/inc/namespace.php#L130

Steps to reproduce:

1. We updated a dev site to Altis 12, with all dependencies, which upgraded psr/log from 1.1.4 to 3.0.0.
2. We deployed this branch to a dev environment still running PHP 7.4, per the docs page which states that v12 should support both PHP 7.4 and PHP 8.
3. Login stopped working on Development, with an error,

syntax error, unexpected '|', expecting variable (T_VARIABLE)

• That error occurred in file vendor/psr/log/src/LoggerInterface.php within psr/log v3.0.

psr/log versions since 2.0 specifically requires php: >=8.0.0, per packagist and the package's composer.json.

composer why output showing that psr/log evaluates to v3 in Altis 12:

composer why -t psr/log
psr/log 3.0.0 Common interface for logging libraries
└──monolog/monolog 2.8.0 (requires psr/log ^1.0.1 || ^2.0 || ^3.0)
   ├──altis/cloud 12.0.4 (requires monolog/monolog ^2.5)
   │  └──altis/altis 12.0.0 (requires altis/cloud ^12.0.0)
   │     └──humanmade/project dev-php-8-compat (requires altis/altis ^12.0.0)
   ├──google/apiclient v2.12.6 (requires monolog/monolog ^1.17||^2.0||^3.0)
   │  └──humanmade/project dev-php-8-compat (requires google/apiclient ^2.0)
   └──maxbanton/cwh v2.0.2 (requires monolog/monolog ^2.0)
      └──altis/cloud 12.0.4 (requires maxbanton/cwh ^2.0)
         └──altis/altis 12.0.0 (requires altis/cloud ^12.0.0)
            └──humanmade/project dev-php-8-compat (requires altis/altis ^12.0.0)

Manually pinning psr/log to 1.1.4 in the Altis project's composer.json appears to resolve the issue, and I can now sign in again on that project's dev environment.

I would expect a subdependency of Altis 12 to support PHP 7.4, because 7.4 is listed as deprecated but not incompatible on the Updating PHP docs page.

Acceptance criteria:

• ...

Currently the following will produce a fatal on install, and requests to wp-admin/install.php if you put this in your .config/load.php:

add_action( 'plugins_loaded', function () {
    var_dump( get_site()->public );
} );

This is because multisite is not turned on pre-install, and not loaded on install.php even if the site is installed. This leads to bad fatals, as if someone has the site setup, the above will work without issues. We also need to fix the wp-admin/install.php requests, as that's currently is what Cloud uses for a healthcheck.

php_1            | [23-Aug-2019 20:42:32 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function get_site() in /usr/src/app/.config/constants.php:24
php_1            | Stack trace:
php_1            | #0 /usr/src/app/wordpress/wp-includes/class-wp-hook.php(286): private_sites_require_login('')
php_1            | #1 /usr/src/app/wordpress/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
php_1            | #2 /usr/src/app/wordpress/wp-includes/plugin.php(465): WP_Hook->do_action(Array)
php_1            | #3 /usr/src/app/wordpress/wp-settings.php(329): do_action('muplugins_loade...')
php_1            | #4 /usr/src/app/wp-config.php(67): require_once('/usr/src/app/wo...')
php_1            | #5 /usr/src/app/wordpress/wp-load.php(42): require_once('/usr/src/app/wp...')
php_1            | #6 /usr/src/app/wordpress/wp-admin/install.php(36): require_once('/usr/src/app/wo...')
php_1            | #7 {main}
php_1            |   thrown in /usr/src/app/.config/constants.php on line 24
php_1            | 172.19.0.13 -  23/Aug/2019:20:42:32 +0000 "GET /wordpress/wp-admin/install.php" 500

Description

Add the altis-consent package to altis-core module

• Add to composer.json
• Load module and base config options
• Add configuration defaults and options

Related #87

To note: Changing the scope of this issue a bit to focus on simply integrating the consent module into Altis Core. Integrating with our analytics services will be handled separately in humanmade/altis-consent#33. While it wasn't explicitly stated that the alternative was part of the acceptance criteria, it was part of the initial direction that this ticket/PR took. We're scrapping that for this issue and iterating on things once this is merged.

The content repository should be for internal use by default, with the option to allow for authenticated API requests. We also want to keep the ability to turn this off and make the site public in the future, so this should not be enforced to be private.

(While it's possible to also edit the URL when changing the public flag, any issues with that are not in scope for this ticket.)

Acceptance criteria:

• As a developer, when I view the documentation about the global content repo, I should see that the site is private by default
• When the global content repo is created, it should be marked as private and require login
• As a user, when I edit the site in the network admin, I am able to make the content repo site public

This list inc/composer/class-installer.php#L26 of plugins we exclude from normal type-based path determination is not alphabetized, and organizing it could improve ease-of-maintenance going forward.

We'd like to use some of Google's services as they're more feature complete & battle tested compared to the AWS equivalents in many cases, particularly the ML ones.

First step is to bundle the SDK and perhaps some basic integrations / functions for getting translations for example in WP.

Steps to reproduce:

1. Have WordPress be installed to /opt/bitnami/wordpress
2. Have /opt/bitnami/wordpress/wp-content be symlinked to /bitnami/wordpress/wp-content

Altis\fix_plugins_url() will create malformed URLs, in the form of https://example.com/wp-content/bitnami/wordpress/wp-content/plugins/altis-accelerate/vendor/altis/aws-analytics/build/accelerate.css

I can't work out exactly which part of the URL replacement in

As @rmccue pointed out, WordPress has special handling for symlinks in things like https://developer.wordpress.org/reference/functions/wp_register_plugin_realpath/.

This is an issue because altis/core is used in the Accelerate plugin, not just Altis Cloud.

We have functions to get environment name, type and architecture. We should also have one to get the region.

Acceptance criteria:

• Add a function called get_environment_region() that returns HM_ENV_REGION if set, otherwise null
• Function has a return type hint of : ?string
• Function is documented in functions section of docs/readme.md

When running Altis v11 beta 1 I see the upgrade notice in the admin telling me to update to v10.

Acceptance criteria:

• Upgrade notice does not appear when current is greater than current stable version

The altis.config filter fires prior to project specific config files being loaded in /.config/load.php. This prevents the ability to alter the config via PHP.

Steps to reproduce:

1. Create an Altis project
2. Add the following to your /.config/load.php file:

add_filter(
  'altis.config',
  function( $config ) {
  	var_dump( 'config', $config );
  	exit;
  	return $config;
  }
);

3. Witness Altis loading despite the exit.

It's quite likely we may need to account for per site overrides of certain config values, things in the SEO module for example re. setting facebook page ID, twitter URL and so on might be different for individual sites on the network.

My proposal is to use the same approach outlined for per environment overrides, for example:

{
  "extra": {
    "platform": {
       "modules": { "...": "..." },
       "sites": {
         "subsite.example.com": {
           "modules": {
             "...": "..."
           }
         }
       }
    }
  }
}

The config would be matched on the keys under sites and the current host name. We could quite easily support wildcards or full regex matches too.

We should port across the autoloader helper, as it significantly improves usability when developing. The alternative currently is to use classmap autoloaders via Composer, which requires regenerating constantly with Composer, and also requires you to do more setup.

Description

All options available for the Altis consent module should be configurable from the composer.json file. This means that before including into Altis, we'll need to make sure to check the config and update the options on Altis init.

Some decision should be made about the behavior of the options that defined in the config vs. in the admin. There may be cases where we want to disable any user-facing UI (or disable the user-facing UI with the exception of the privacy and cookie policy pages) but there may also be cases where we just want to define intelligent defaults that can be edited on a site level.

I am migrating a site to Altis v8.

When I run wp altis migrate the global media repository site is created. However I have set the following in my composer.json, so I would not expect to see the site created.

"altis": {
	"modules": {
	"workflow": {
		"publication-checklist": false
	},
	"media": {
		"global-media-library": false
	},
},

It looks like there are no checks to see if this feature is enabled in the migration command, which is where the site is created.

See: https://github.com/humanmade/altis-core/blob/master/inc/global_content/namespace.php#L107

We should display a prominent warning on the admin home screen above all other widgets if a customer is running an unsupported version of Altis.

This should not be dismissable, and it should clearly be a warning that they are running a potentially insecure version that is out of support. This should pull the data from https://github.com/humanmade/altis-dev-docs-site/issues/81 so that support information can be updated remotely as needed, and the warnings triggered at our discretion.

Steps to reproduce:

1. Switch all packages to v6-branch: composer run module 'git checkout v6-branch'
2. Confirm that the privacy module is on the correct branch: cd packages/privacy && git branch --show-current
3. Start the local server: composer server start
4. Go to the Altis About page: wp-admin/about.php
5. The Privacy module displays dev-master instead of dev-v6-branch

Acceptance criteria:

• Privacy module should display the correct version

Note: I'm not sure if this is related to the Privacy module being a new addition and it will work itself out but it seems odd/not right...

There's no helper function for getting the current deployed code revision, which used to be available via HM_APPLICATION_REVISION. Rather than the constant rename, we've moved to using functions so we should add one for that.

It might make more sense to have this in the Cloud module, not sure!

WP has a built in privacy page feature including the ability for a user to request all their data. We should document how to implement this and any special additions we add to the default behaviour in this module.

In some cases it'd be useful for a module to be able to filter the default AWS SDK params in the Altis\get_aws_sdk() function.

Acceptance criteria:

• Add a filter altis.aws_sdk.params to the get_aws_sdk() function just before $params is passed to new Sdk()
• Filter is documented in the filters section on the readme

When using HTTP Basic Auth on a site requests to the global content site fail as the basic auth cookies / headers aren't forwarded.

Altis should detect when this feature is in use and forward basic auth cookies along with the WP auth cookies.

Acceptance criteria:

• Basic auth headers forwarded in requests to global content site
• Global media works on sites with basic auth enabled

In another project we use a similar approach to configuration to dictate sites that must exist and some settings they have. This feature also detects changes in the config and provides hooks for responding to those changes - think activation / deactivation / migration steps.

The core module is the ideal place to handle a feature like this so any platform code or project code can respond to those changes.

For example, a site is added to the property specified in #8 - the CMS module could ensure that the site exists.

I've noticed if you have an error in your config, we don't die, and if that goes unnoticed, it's very confusing! I think we should a big bad red error for this!

Acceptance criteria:

• Change E_USER_WARNING to E_USER_ERROR in get_json_file_contents_as_array() on line 123
• Add text to the error message before json_last_error_msg() saying "composer.json could not be parsed\n"
• Validate module names under the modules property against registered modules and allow unknown modules if they have an entrypoint property, trigger an error if invalid module found
• Check module names against top level config properties eg. extra.altis.<module> and trigger an error if a module name is found with instructions to move it under extra.altis.modules.<module>
• On local environments instead of just triggering an error throw an exception with the same error message

Use Altis\Module::get_all() to get all registered modules.

Examples of invalid configs:

Unregistered module with no "entrypoint" property:

{
  "extra": {
    "altis": {
      "modules": {
        "enhanced-search": { "enabled": false }
      }
    }
  }
}

Registered module config not under "modules" property:

{
  "extra": {
    "altis": {
      "search": { "enabled": false }
    }
  }
}

Custom module at top level with "entrypoint" property:

{
  "extra": {
    "altis": {
      "custom-module": { "entrypoint": "path/to/file.php" }
    }
  }
}

Description

Our Getting Started guide starts essentially with "Install Composer", but it doesn't even mentioned that you'll need PHP installed, or what version of PHP. In humanmade/altis-dev-tools-command#34 we had one reported case where someone is using PHP 7.2 for example which doesn't since we switched to PHP 7.4+. It seems currently we don't acknowledge or guide people on installing PHP 7.4 which is a prerequisite to composer, which is a prerequisite to altis.

Acceptance Criteria

• Documentation explains how to install PHP for Mac, Linux and Windows

Repo - https://github.com/humanmade/altis-documentation/tree/master/other-docs/getting-started

Ready

• Is the title clear?
• Is the description clear and detailed enough?
• Are acceptance criteria listed?
• Have any (potential) dependencies been identified?
• Is an estimate/timebox assigned?
• Is a priority label assigned?
• Is this ticket added to an epic? (Optional)

It would be useful to have a wrapper import command which handles importing an SQL file, search-replacements, ElasticSearcfh indexing, flushing cache etc. At the moment these are all separate steps one need remember, beyond importing the database. I think we need a "smart import" command that can handle many Altis-specific tasks and functionality.

The telemetry setting on the profile page is unclear about what it affects. It should clarify that opting in/out only affects personal data, and that business-/environment-level data is always collected.

Suggested text:

• Opt in to personal data in Altis Telemetry

Altis collects business-level telemetry data about the performance and use of your site. Opting in to personal data helps us improve Altis and develop better tools for you.

Original description:

Steps to reproduce:

1. Visit your user profile editing screen at wp-admin/profile.php
2. Ensure the "Opt in to Altis Telemetry" checkbox is unchecked
3. Observe that a JavaScript file is still loaded from https://cdn.segment.com/analytics.js/v1/<snip>/analytics.min.js
4. Observe that a request is still sent to https://api.segment.io/v1/p with a payload that includes an anonymousId parameter that appears to remain static between page loads

No cookies are set for either of these domains, but given the above it appears my usage of Altis is still being tracked by a third party despite my opting out.

Query Monitor contains a PSR-3 compatible logger, but isn't always available. It also doesn't implement the interface.

We should expose one that implements the interface, and is always available. If the dev tools are available, we should log to QM by default, otherwise we should do nothing and allow additional loggers to be registered (e.g. bring-your-own Monolog/Wonolog).