Describe the bug

When trying to bundle a project that has @chili-publish/publisher-interface with Webpack 4.x you receive an error message:

ERROR in ./node_modules/@chili-publish/publisher-interface/lib/PublisherInterface.js 10:32
Module parse failed: Unexpected token (10:32)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| 
| class $0370263bd5c7e7d2$export$a13915682e709c4f {
>     chiliEventListenerCallbacks = new Map();
|     // eslint-disable-next-line @typescript-eslint/no-empty-function
|     constructor(){}
 @ ./src/index.js 5:0-72 16:17-35

If you bundle with Webpack 5.1.0 or higher, you receive no error message

To Reproduce

Steps to reproduce the behavior:

1. Go to https://replit.com/@scrowe/Webpack-4#package.json
2. Run npm run build and see error
3. Change the package.json version of webpack to

    "webpack": "5.1.0",
    "webpack-cli": "^4.10.0"

The only reason we update webpack-cli too, is because the older CLI version does not work with 5.

4.Run npm run build and see no error

Solution

Use Webpack 5 (or other bundler like Parcel, Vite, etc) for you bundling needs.

Hello, I was on PublisherConnector before and my code was working, since I upgrade to PublisherInterface, I always get "EXTERNAL ERROR: Blocked a frame with origin "https://domain" from accessing a cross-origin frame." I followed the documentation and the process. I'm on symfony and front with twig. Here is my code: (async () => { try { const publisherInterface = await PublisherInterface.build(iframe); await publisherInterface.addListener( "DocumentFullyRendered", target => { $('.zoom').on('click', (e)=>{ zoom(e, publisherInterface); }); } ); } catch (e) { console.log(e); }; })();

It's not even doing the build.

Missing quote "FrameMovedFinished" on Wiki code block here:

https://github.com/chili-publish/publisher-interface/wiki/Differences-With-editorObject

window.OnEditorEvent = (eventName, targetId) => {
  if (eventName == "FrameMovedFinished) {
    console.log("Frame with id " + targetId + " was moved");
  }
}

What

Adds testing to the library.

Please review the README at ./test/README.md, as I will assume that has already been read.

This is meant to be ran on merge requests, and if accepted the Github Action will need to be modified.

Why

Playwright

Playwright was an easy choice as it allows simple testing with very little configuration.

• playwright package contains the browsers for testing
• @playwright\test package contains the testing script

The testing script we use is ./test/PublisherInterface.spec.ts

testServer.js

This file spins up a simple test server on localhost:3001. This server is very simple, and thus it seemed silly to use the many libraries that do the same but increase package dependency by times 4 or 5. This is a simple script which requires no dependencies.

The server is not configurable (outside of changing the script), but our testing is not foreseen to require configuration. The only special thing is that you can pass in the argument --url to have the server load index.html with a specific URL in an iframe.

index.html

This file will run the tests found in ./test/tests. It is a very simple file that is highly coupled to testServer.js as it expects the src attribute on the div to be replaced by the the server script.

There is one function window.runTest(), which expects a single parameter of the name of the test file to run from ./test/tests

run_tests.js

This file has snake_case to signify that something is not normal. This is a meta script which glues together the build, copy, server start, and Playwright testing.

There is some hacky stuff going on here due issue with spawn() with shell:true that I had on Ubuntu 22.04. See commit 6d2f98a7dc12ce052247cea2ebfe86cfd88faf0f - I spent too long trying to find a legit fix, but at this moment it is either a Linux configuration issue (with Node behavior) or a bug in Node v14 and v16.

This pull request provides all the rebranding for PublisherConnector to PublisherInterface.

All that needs to be done is the following:

• Reviewed by @brapoprod, keep in mind @brapoprod that this will create a new library in npm called @chili-publish/publisher-interface
  • Make sure I spelled everything correct
• One of us will then need to rename the repo to publisher-interface
• Merge the request
• publish-release-on-npm workflow should publish the new library

Let's discuss what we should do with @chili-publish/publisher-connecter on npm see: https://github.com/chili-publish/publisher-connector/issues/11

This will allow optional ability to use penpal features for timeout and debugging

This is being requested by clients to handle the situation where penpal fails to connect. The timeout would allow for an error to handle.

Bumps terser from 5.13.1 to 5.14.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Simple mistake, not caught by the tests. Tests probably need to cover more use cases of features. Who wants to volunteer to right tests?

Will bump version once approved, or @brapoprod feel free to bump versions to 0.3.x

This fixes #23 by using tsc instead of Parcel to handle TypeScript compiling and targeting ES2015. As far as I am aware there is no downside to targeting ES2015 over modern ES versions, especially when our web build is already targeting less modern JS.

Will bump version of package once approved, or @brapoprod feel to free to bump to 0.3.x

Many integrations will need to move over to Publisher Interface and all there code will use PascalCase function calls. This provides an easy alias to make it easier to those code bases to upgrade to Publisher Interface.

This does not solve the fact that these functions still return a Promise.

This meant to be merged in https://github.com/chili-publish/publisher-interface/pull/15

This is more than just a convenience feature. This is also there to allow developers to emulate the fact that certain events like DocumentFullyLoaded and DocumentSaved where fired off automatically in the current implementation.

Bit of a long shot, but I was wondering if there was any functionality that would get all the variables associated with a particular frame?

A bit of context. I have a text frame that contains three short text variables, a long text variable and a list variable. On selecting that text frame I want to get the objects for these five variables. So I can then display custom input fields for these five variables etc.

I'm able to get one of the five variables by setting the variable in the text frame's "Frame Link Settings" in the Chili BackOffice and using the following:

await publisher.addListener("SelectedFrameChanged", async target => {
     const variable = await publisher.getObject('document.selectedFrame.linkSettings.variable');
});

But this is obviously only one of the five.

I'm also aware that I can get all of the variables in the document by using the following:

await publisher.getObject("document.variables");

and then loop through etc as in the Chili Publisher documentation. But I just want the five variables associated with this frame.

I've had a look through the Chili Publisher docs, but I was curious if anything like the following exists:

await publisher.addListener("SelectedFrameChanged", async target => {
     const variables = await publisher.executeFunction("document.selectedFrame","GetVariables");
});

Or if there is any other way to possibly achieve this functionality? Or if I'm going about it in the complete wrong way.

Any help at all would be appreciated.

Cheers

What is going on?

Hello everyone, we are rebranding Publisher Connector to Publisher Interface. This will be the only and last time there will be a rebranding for this library.

The reason behind this rebranding is that "connectors" will have a new and distinct meaning with our new platform. The meaning is so distinct that we see major confusion among clients (new and legacy) if a publisher connector could mean this library or part of our connector system.

It is an unfortunately situation, but it must be dealt with.

Another reason for the rebranding is that in about 60 days, this will be the most popular library from CHILI publish. Over one hundred clients will be transitioning to using it. Therefore, it is even more important that the library standout from other similar named features.

This rebranding goes from this repo all the way to the NPM package. See PR https://github.com/chili-publish/publisher-connector/pull/12

Will this break my integration?

@chili-publish/publisher-connector is still up on NPM. So no. Will it be updated moving forward? That is what this question is about.

However, if your moving to @chili-publish/publisher-interface then the only issue will be that the unpkg file will change both in location and name. Everything else will work the same.

What to do with publisher-connector?

How should we handle publisher-connector on NPM as the rebranding will break future updates?

From the README...

The PublisherConnector build method must be called before the IFrame loads the Editor.

This part I'm not clear on. The example in the readme shows an iframe with a src attribute containing a valid editor URL. This should cause the editor in the iframe to load before the build method fires, right? Unless I'm missing something...

I'm attempting to implement it in React with a ref to the iframe, but can't get it to load the editor. Tried withholding the src URL, setting it later, etc, to no avail. When I set the editor iframe src URL I get a blank editor screen and the error:

"Uncaught DOMException: Failed to set the 'domain' property on 'Document': 'localhost' is not a suffix of ************.chili-publish-sandbox.online'."

Any ideas would be great. Thanks.