cameronterry / dark-matter Goto Github PK

• Add one domain mapping: this becomes the primary
• Add a second domain mapping: this unsets the primary setting
• Workaround: hit the Make Primary button for the first mapping

Expected: As long as I add mappings that are not the primary, the setting should not be changed.

Version: 1.0.0 rc8

Odd one considering the pre_option_home filter should cover it but apparently not. Every other link seems to be mapping properly, so this one is standing alone for whatever reason.

It should include information on the plugin very similar to the readme.txt for WordPress / WordPress.org but also contain information for contributing and issues in general.

For example; the direction of the plugin's development and some of the things which Dark Matter would not consider implementing.

Perfect case-and-point would be someone requesting the ability to switch from a single admin-domain to all websites running off the primary (mapped) domain for the admin area as well as the front-end instead.

This console error happens on chrome type browsers when the user is not logged in, as an empty file is returned and no content type is set in this scenario, but is still called within a script tag.
Working on a fix.

I'm currently using this, happy to provide a PR? Perhaps this can be a npm run script.

origin_version=$(git describe --tags origin)
git fetch --tags
git checkout $origin_version
composer install --no-dev --optimize-autoloader && npm install && npm run build

# replace the plugin folder with selected files:
rm -rf ../html/wp-content/plugins/dark-matter
mkdir -p ../html/wp-content/plugins/dark-matter
cp dark-matter.php ../html/wp-content/plugins/dark-matter/
cp -r domain-mapping ../html/wp-content/plugins/dark-matter/
cp -r dark-matter ../html/wp-content/plugins/dark-matter/

Only on pages where the sso status is checked are we seeing this error, it seems the sso code doesn't set a correct status header and code

When the primary domain is deleted it pops up a message confirming this, however the page is not reloaded. As a result the Visit Site link in the admin toolbar points to the primary domain that's no longer there.

Based on the guide here; https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/

Need four assets put together at some point which are;

• Normal Banner: banner-772x250.(jpg|png)

• High-DPI (Retina): banner-1544x500.(jpg|png)

• icon-128x128.(png|jpg)

• icon-256x256.(png|jpg)

Ability for Super Admins at a Network-level to be able to put in a set of Reserved Domains.

This list would prevent all but Super Admins of a WordPress Network from being permitted to map the domains to websites and would prevent other Administrators from being able to map them.

Trivial one. Doc block comment the same for map():

* Map the primary domain on the passed in value if it contains the unmapped
* URL and the Site has a primary domain.

and unmap():

* Map the primary domain on the passed in value if it contains the unmapped
* URL and the Site has a primary domain.

The Snyk workflow in Github Actions is returning a peculiar error and not working at present.

Note: I've removed the at symbol from babel/runtime so someone is not unnecessarily notified about this.

Dependency babel/runtime was not found in package-lock.json. Your package.json and package-lock.json are probably out of sync. Please run "npm install" and try again.

And yet ...

Not 100% sure what the discrepancy is that is tripping up Snyk...

Several requests have been made for supporting domain mapping to individual pages within a site.

Currently Dark Matter only supports mapping a domain to the entire site, whereas this is to map it to any of the content under the Pages post type.

The function get_rest_url() is returning the primary mapped domain rather than the admin domain, when utilised on WordPress /wp-admin/ area.

This in turn is affecting window.wpApiSettings which is used by plugins and sending their REST API requests to the primary domain, which in turn causes this error in the browser's console.

Request header field X-WP-Nonce is not allowed by Access-Control-Allow-Headers in preflight response.

Noticed the issue primarily with Yoast SEO and it's dashboard widget. An issue does not appear to be lodged on their issues list by any one yet, but that could change.

But could be a cause of this issue noticed by Redirection plugin as well (although the reporter seems to have a separate issue of a similar nature.

This would suggest there is a problem and / or a step is missing in the setup of Dark Matter. So therefore it would be good to put a "nag" notification that if the plugin is enabled, it warns Super Admins that something is wrong or missing.

NPM run build warnings:

> [email protected] build
> NODE_ENV=production webpack --mode production


✖ Webpack
  Compiled with some errors in 25.72s



      ./node_modules/scheduler/index.js 197 bytes [built] [code generated]
      ./node_modules/scheduler/cjs/scheduler.production.min.js 6.65 KiB [built] [code generated]
  modules by path ./domain-mapping/ui/ 97.8 KiB (javascript) 529 bytes (css/mini-extract)
    ./domain-mapping/ui/index.js + 45 modules 97.7 KiB [built] [code generated] [1 error]
    ./domain-mapping/ui/App.css 50 bytes [built] [code generated]
    css ./node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[2].use[1]!./node_modules/postcss-loader/dist/cjs.js!./domain-mapping/ui/App.css 529 bytes [built] [code generated]

ERROR in ./domain-mapping/ui/Components/DomainRow.js
Module Error (from ./node_modules/eslint-loader/dist/cjs.js):

/var/www/amasan.co.uk/dark-matter/domain-mapping/ui/Components/DomainRow.js
  30:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  32:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  34:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  35:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  36:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  37:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  38:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  39:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  40:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs
  42:2  error  Mixed spaces and tabs  no-mixed-spaces-and-tabs

✖ 10 problems (10 errors, 0 warnings)

 @ ./domain-mapping/ui/Components/DomainMapping.js 20:0-36 205:52-61
 @ ./domain-mapping/ui/index.js 3:0-55 10:41-54

domain-mapping (webpack 5.65.0) compiled with 1 error in 25726 ms

When called through rest_output_link_wp_head() (link) it returns the primary domain (correct). However, when called after using switch_to_blog(), it returns the admin domain (incorrect).

Discovered whilst adding the unit tests, which works with multisite through the switch_to_blog() / restore_current_blog() mechanism: #88.

This will be to bring in PHP 8.x.x support to Dark Matter. For note: WordPress is considered currently - as of 5.6 - to have only "beta compatibility".

Also worth noting that WP Local Docker and VVV do not seemingly have PHP 8 support yet, so would require a custom environment - or another dev environment tool - for development. At a guess, these two projects will track WordPress compatibility as a timeline for adding PHP 8.

On a multisite, when trying to manage domains on the root domain (when no --url is specified) the following error message is returned:

Error: Domains cannot be mapped to the main / root Site.

My expectation is that in this scenario instead of the error message, domains on all sites are considered. As it is not possible to assign the domain to multiple sites, it should be irrelevant what site is specified, when managing existing mappings.

The exception to this is when adding a domain and no site is specified, not sure if an interactive prompt would be useful there or if the error message could be clarified to mention how to prevent the error condition.

Would be good to be able to filter the permission regarding who can manage domains.

currently it's the following, despite the settings menu being part of the site (logic then dictates site admins should be able to do this).

public function create_item_permissions_check( $request ) {
		return current_user_can( 'upgrade_network' );
	}

Discovered an issue with WordPress.com and being unable to control the settings of a self-hosted blog.

As this is likely communicating over the XML-RPC library and other issues of this were related previously to Dark Matter going onto http://demonszone.com, I need to find out if its related or something else.

Several reports of Dark Matter causing unnecessary updates for primary domains and then subsequently running multiple SELECT queries for the primary domain in release 2.3.0.

Initial suspect would be the changes introduced in #94, which altered the way cache / database updates for primary domains were handled.

Screenshot of atypical local setup adding to illustrate the issue through Query Monitor.

It's possible to paste in a http URL into the domain field, which then happily screws up the domain mapping. Because this plugin can be used by devs in a local setting it would make sense to either add validation or sanitization.

This is because currently Dark Matter is only attempting to rewrite the domain to the primary mapped domain on a per site level, with no awareness at the Network level.

This one is a bit more interesting as the Network screen contains not one site, but all sites. So need to be a bit clever here and ensure that we do not load all mapped domains for a network.

A pre-launch option on a per blog basis will allow someone to map all the domains as per their pre-launch check list but still have access on the root domain.

Essentially this would change Dark Matter to function either the primary mapped domain or the admin domain whilst this option was utilised.

Once switched off, the option will revert Dark Matter to the current implementation which is all front-end views are redirected to the primary mapped domain.

This will be handy for viewing all mapped domains for all sites at a glance. There is likely to be a scenario where someone wants to look for something based on a mapped domain rather than the admin domain.

One scenario is multiple non-primary domains being mapped to a single site and the administrator wishes to create a standalone website on one of these domains. Therefore they will need to know which website has the domain currently for it to be removed and used elsewhere.

The table on this screen would need the following information (one row per mapped domain);

• Site Name
• Type (Primary / Auxillary)
• Actual mapped domain
• Options (possibly Delete)

Jetpack creates a bunch of new endpoints through the REST API v2 which are all mapped to the mapped domain.

This is fine if both are HTTP or HTTPS but not so good if the admin domain is HTTPS and the mapped domain is HTTP.

Dark Matter currently does not fully support a scenario where some one has configured WordPress to use a different root, but defining a different value for BLOG_ID_CURRENT_SITE.

define( 'BLOG_ID_CURRENT_SITE', 1 );

If this is done, then Dark Matter may present options to map domain for the Site ID 1 (the most common "root" site) and then no longer offer options for new "root" site in WordPress. The fix is likely to change the principle of the plugin's architecture to no longer treat the "root" site as a special case and to provide full domain mapping options across all site's regardless.

This would directly impact the resolution for the enhancement requested here, #45. As the all individual sites could have mapped domains, to view all domains would require a flag on the CLI to distinguish between controlling mapped domains for a site versus mapped domains across a WordPress network.

Version: 0.5.0

It is hard to know if its a problem with Jetpack and EasyEngine.io (https://easyengine.io/) or if its Jetpack + Dark Matter, but the chart graphic on the Admin bar (part of the Stats module) which shows traffic in 2-hour intervals; breaks.

Command used to install WordPress with EasyEngine (performed on Ubuntu 16.04);

sudo ee site create [domain] --wpsubdir --wpfc

Furthermore, because it is redirecting to the /wp-login.php screen, WordPress is invalidating the session and forcing administrators to login again.

It is possible for the issue to be one of the following;

1. an incompatibility between Jetpack Stats + Dark Matter when used with EasyEngine.
2. an incompatibility between Jetpack Stats and EasyEngine.
3. an incompatibility between Jetpack Stats + Nginx cache + Dark Matter combination.

For note; tested on a vanilla Ubuntu 16.04 virtual machine and installed Nginx and PHP manually (using the Ubuntu 16 packages) and Jetpack Stats / Dark Matter worked as expected. So on the surface it looks like something in the configuration of EasyEngine which is upsetting something in Jetpack but this is unconfirmed.

Discovered whilst adding the unit tests, which works with multisite through the switch_to_blog() / restore_current_blog() mechanism: #88.

The affected code is:

This can cause an error:

Fatal error: Uncaught error: Attempt to assign property "new_version" on bool

Its getting confused between the admin domain and the primary mapped domain when using the Jetpack debugger.

It's not unique to the new version and was present in Jetpack 4.1, so something weird going on that needs fixed.

Redirect is fine but it should be once ... from HTTP to HTTPS. This is occurring on my own personal Dark Matter test site at Linode.

Chrome Dev Tools > Network with "Preserve Log" checked screenshot below. It is constantly redirecting between HTTP / HTTPS and weirdly ... between [domain]/dark-matter/wp-admin/ and [domain]/dark-matter/dark-matter/wp-admin/.

I have just stumbled upon this code in Jetpack plugin;

https://github.com/Automattic/jetpack/blob/5.2.1/3rd-party/domain-mapping.php

It could be possible to get Dark Matter and Jetpack working together if this is examined and some new code put together to handle it.

Only to be done as the final task for milestone v1.0.0

Versions Affected: 0.11.0 and 1.0.0 RC1

This is because the global $current_blog is not updated as part of the process which runs inside switch_to_blog() and restore_current_blog().

Judging by WordPress Core ticket #14190, this is by design.

This mainly affects the Network Admin part of the Admin Bar. Listing the websites that a user is mapped to displays a link with the text "Visit Site" which goes to the homepage of each website. Sadly, on the front-end this displays the primary domain for the currently viewed website and not the homepage for each one.

On the admin side, it displays the admin domain version of the homepage (which then subsequently redirects to the mapped domain version). This is because a hacky check prior to setting the home option in the admin side in commit f23ce26

As of WordPress 4.5 the global variable $current_blog has been set to an instance of WP_Site object rather than just an stdClass. In truth though, it should return a WP_Site object if the version of WordPress is 4.5 or above rather than rely on WordPress Core's backward compatibility / checks.

It may require reworking the way things like HTTPS is detected as this is currently a property of the $current_blog object. This likely have to move into the return of WP_Site->get_details() through the blog_details or site_details filter.

In fact ... we will need to make a decision on whether this change detects WordPress 4.5 or 4.6 before implementing it, as some actions have been moving around as part of the work to change from "blog" to "site" as a naming convention.

This is likely an oversight from using Donncha's Domain Mapping plugin as a bit of a loose template for Dark Matter.

The set() and unset() methods in DarkMatter_Primary update the database record for a domain but does not update the update or invalidate the caches used by DarkMatter_Domains, causing a discrepancy in the cache records.

Discovered whilst adding the unit tests, which works with multisite through the switch_to_blog() / restore_current_blog() mechanism: #88.

A recent change introduced in 2.1.4 that ensures the post_content stores unmapped domains where appropriate, is now causing issues with Yoast's JavaScript implementation of counting internal links.

• Editor: Classic Editor
• WordPress: 5.7.2
• Plugin: Yoast SEO 16.2 / Yoast SEO Premium 16.0.3
• Since: 2.1.4

And the irony of the screenshot isn't lost on me either ...

It would seem that if the following is set as the primary domain - www.example.com - then the example.com auxiliary domain will not redirect as expected.

This will enable better support and remove some weirdness with plugins such as More Privacy Options which can end up in redirect loops because of the redirect / logged in (admin domain) / not yet logged in (primary domain) logic.

At least if the check for the blog_public option was in place it would behave "nicer". Albeit debatable on whether than translates to "better".

• More Privacy Options on WordPress.org; https://en-gb.wordpress.org/plugins/more-privacy-options/
• Option Reference on WordPress Codex; https://codex.wordpress.org/Option_Reference#Privacy