How to show Allowed types on Content Area – Grzegorz Wiecheć

Nice solution for EPiServer editors to be able to see which kind of content types that can be added to a content area in EPiServer. This solution is for older Episerver versions e.g. around 2015.

In EPiServer 11+ the js is minifed and inside a zip file at this location:
[EPiServer root folder]\modules\_protected\CMS\CMS.zip\11.4.6\ClientResources\epi-cms\contentediting\editors
I wont touch that for now but if someone does, please let us all know.

Content References list with allowed types

Read more here: How to show Allowed types on Content Area – Grzegorz Wiecheć

Open Source JavaScript Test Runner | Cypress.io

For end to end testing of websites, should be really simple to use and easier to setup than Selenium. Write javascript to execute tests.

Until now, end-to-end testing wasn’t easy. It was the part developers hated.
Not anymore. Cypress makes setting up, writing, running and debugging tests easy.

En example:

This will visit the Cypress example site, look for an element with the text “hello world” and fail the test if it doesn’t exist.

Source: Open Source JavaScript Test Runner | Cypress.io

cors-proxy-server – npm

I wanted to try out some Angular code against a demo odata service, but when requesting data from another domain in a web browser (the angular context) you might get:

Access to XMLHttpRequest at ‘http://services.odata.org/V4/OData/OData.svc/Products?$format=json’ from origin ‘http://localhost:4200’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: Redirect is not allowed for a preflight request.

To get around this problem you could use a node proxy like this one:

Source: cors-proxy-server – npm

Install and start it up. Now we can call the odata service by prepending the proxy url before the actual api endpoint like this:
http://localhost:9090/http://services.odata.org/V4/OData/OData.svc/Products

Notice the double http://

The entire CORS problem can be summarized like this:

The web browser will prevent javascript to get a response from the service at domain x if that server does not explicitly say its ok to respond the remote caller. In our case our source domain is ‘localhost’ and the services.odata.org haven’t added that as a valid domain to respond to according to the web browser.

More info regarding CORS here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS