typo3-headless / headless Goto Github PK

Instead of inventing an own JSON structure, please think about using the JSON:API standard that is widely supported by JS frameworks: https://jsonapi.org/

We have made good experience using the standard for our own JSON REST API for e-commerce:
https://github.com/aimeos/ai-admin-jqadm

A REST API also fits better than GraphQL for a CMS because a CMS frontend has to read a lot of data but don't need to write large data sets. We've published an article about the pros and cons of JSON:API and GraphQL: https://aimeos.org/tips/graphql-vs-jsonapi-for-ecommerce/

Dries from Drupal also made a good article why Drupal prefers JSON:API over GraphQL:
https://dri.es/headless-cms-rest-vs-jsonapi-vs-graphql

Hi,
when adding a new error handling inside a site configuration and set the handler to "Show Content from Page", the output of this page is of type text/html; charset=utf-8 because the page TypoScript doesn't apply here.

In a project where we used our own headless extension before, we used a Middleware to set the Content-Type-Header always to application/json; charset=utf-8 for every request. This also would make the additionalHeaders part in PageConfiguration.typoscript and MenuConfiguration.typoscript redundant.

Is this something you consider having in this extension as well? I could open a pull request for this, but wanted to ask here first and to see what's your opinion on this.

This has to be tested very well for sure as I don't know yet what happens to Exceptions that occur after the new Middleware. Maybe they are also set to application/json. 🤔

Additionally we could extend the errorHandler selection with an option to also select a JSON file. Just like with the "Fluid Template" option.

What do you think?

best,
R

Related to #84, functionality from #84 breaks v10, but this change removes processing images based on given height or width

Hi,

I use a custom DataProcessor to output an object that implements \ArrayAccess. Currently it appears that such data will not be processed by the JSON-View (only if you convert the object to a plain php array).
I thinkt this would be a useful addition to allow for outputting objects that implement \ArrayAccess. What do you think?

Would not it be an advantage if the unique ids of the navigation points in the JSON output were also output when retrieving the navigation (http://www.domain.de/?type=834)? Or do we have a bug?

Hi,
there are some fields that are missing in my opinion.

In "lib.page":

• files (array of objects): The files added to a page in "Resources -> Files"
• socialMedia (object): The fields og_title, og_description, twitter_title, twitter_description, twitter_image combined.
• noSearch (bool): The output of the field "Include in Search"
• categories (array of objects): The categories the page is assigned to.

In "lib.contentElement":

• categories (array of objects): The categories the content element is assigned to.

Is there a reason that these fields are missing or do you think they can be added as well? Because I think they are important for the frontend rendering.

In TYPO3 you can setup custom 404 page. Headless extension should returns content for custom error page.

Today i was testing the headless-extension but i failed at the very beginning...

Each page i call up, shows the same json-content (only navigation)
[{"data":{"uid":83,"pid":1,"tstamp":1571222872,"crdate":1571222872,"cruser_id":1,"deleted":0,"hidden":0,"starttime":0,"endtime":0,"fe_group":"","sorting":0,"rowDescription":null,"editlock":0,"sys_language_uid":0,"l10n_parent":0,"l10n_source":0,"l10n_state":null,"t3_origuid":0,"l10n_diffsource":"a:1:{s:8:\"shortcut\";N;}","t3ver_oid":0,"t3ver_id":0,"t3ver_label":"","t3ver_wsid":0,"t3ver_state":0,"t3ver_stage":0,"t3ver_count":0,"t3ver_tstamp":0,"t3ver_move_id":0,"perms_userid":1,"perms_groupid":1,"perms_user":31,"perms_group":27,"perms_everybody":0,"title":"Home","slug":"\/home","doktype":4,"TSconfig":"","is_siteroot":0,"php_tree_stop":0,"url":"","shortcut":1,"shortcut_mode":0,"subtitle":"","layout":0,"target":"","media":0,"lastUpdated":0,"keywords":"","cache_timeout":0,"cache_tags":"","newUntil":0,"description":"","no_search":0,"SYS_LASTCHANGED":0,"abstract":"","module":"","extendToSubpages":0,"author":"","author_email":"","nav_title":"","nav_hide":0,"content_from_pid":0,"mount_pid":0,"mount_pid_ol":0,"alias":"","l18n_cfg":0,"fe_login_mode":0,"backend_layout":"","backend_layout_next_level":"","tsconfig_includes":"","legacy_overlay_uid":0,"tx_impexp_origuid":54,"seo_title":"","no_index":0,"no_follow":0,"og_title":"","og_description":null,"og_image":0,"twitter_title":"","twitter_description":null,"twitter_image":0,"canonical_link":"","categories":0,"nav_icon":0,"thumbnail":0,"isSpacer":false},"title":"Home","link":"\/","target":"","active":0,"current":0,"spacer":0,"icon":[]},{"data":{"uid":82,"pid":1,"tstamp":1571222872,"crdate":1571222872,"cruser_id":1,"deleted":0,"hidden":0,"starttime":0,"endtime":0,"fe_group":"","sorting":1,"rowDescription":null,"editlock":0,"sys_language_uid":0,"l10n_parent":0,"l10n_source":0,"l10n_state":null,"t3_origuid":0,"l10n_diffsource":"a:1:{s:6:\"hidden\";N;}","t3ver_oid":0,"t3ver_id":0,"t3ver_label":"","t3ver_wsid":0,"t3ver_state":0,"t3ver_stage":0,"t3ver_count":0,"t3ver_tstamp":0,"t3ver_move_id":0,"perms_userid":1,"perms_groupid":1,"perms_user":31,"perms_group":31,"perms_everybody":0,"title":"Spacer","slug":"\/spacer","doktype":199,"TSconfig":null,"is_siteroot":0,"php_tree_stop":0,"url":"","shortcut":0,"shortcut_mode":0,"subtitle":"","layout":0,"target":"","media":0,"lastUpdated":0,"keywords":null,"cache_timeout":0,"cache_tags":"","newUntil":0,"description":null,"no_search":0,"SYS_LASTCHANGED":0,"abstract":null,"module":"","extendToSubpages":0,"author":"","author_email":"","nav_title":"","nav_hide":0,"content_from_pid":0, {...}

can anybody tell me, what i'm doin wrong?

kind regards / thx

Right now, we are removing "data" from MenuProcessor output, because we don't need this data, but if we want for example to render images for pages in menu, 'data' is necessary, so we need to keep it.

Instead of pagetype/suffix for triggering json output one could use the 'Accept' header to detect that json was requested.

We have still CE which are missing unit tests, we should provide unit tests for all elements

After having troubles to add typoscript after headless was included I drilled it down to line #14 in Configuration/TypoScript/ContentElement/Shortcut.typoscript.

If I put it into anything conditional the BE complains about a missing brace. All following typoscript will land at unintended places.

Screenshot is attached to show the place where the error seems to be. (#2490 in that case)

styles.content.shortcut.tables is set to tt_content

Method: decodeFieldsIfRequired. There are situations, when data is not json but empty string or anything that passes check with json_decode, and it gets decoded unnecessarily, also after rework we need to add tests because it's crucial)

Provide way to pass global configuration to JS application (e.g. manifest configuration)

Find way to output non-cached plugin data. We can use typoscript rendering extension, but we want to solve this without additional prerequisites. Problem is that INT_SCRIPT is hardcoded in ContentObjectRenderer to have max 32 characters, but JsonContentObject wrap INT_SCRIPT in " ", so it's 34 character long. We can also hook into ContentObjectRenderer and clean INT_SCRIPT.

Hi everybody,
good work on the extension! :) Thanks for it.

But to make it easier to install the extension via composer it should be added to packagist.
Otherwise the extension can only be installed when the repo is added to the repositories array in composer.json.

Also a proper version tag should be added to the repo so we don't have to use dev-master when installing.

See error when installing it as discribed in the README:

Could not find a matching version of package friendsoftypo3/headless. Check the package spelling, your version constraint and that the package is available in a stability which matches your minimum-stability (stable)

best,
R

Hi,
in our current project we have a custom content element where we can list pages by given page types (doktype). To get these pages we use a DatabaseQueryProcessor currently.
Now we want to use the headless extension and we we need a way to render this content element as JSON. The output should be something like:

...
{
    "content": {
        "pages": [
            {
                "id": 1,
                "pid": 0,
                ... SAME STRUCTURE AS "lib.page" FROM EXT:headless
            },
            { ... }
        ]
    }
}

Inside pages every page object should have the same structure as in lib.page.

Do you think it’s a good idea to write an own DatabaseQueryProcessor to get data from a specific table in a custom structure? Or is it better to use the CONTENT/RECORDS Content Objects for this (combined with the JSON Content Object)? And do you think this functionality should be added to EXT:headless?

best,
R

I needed sys_categories in my menu, so I tried to attach them to the MenuProcessor. The Problem is, that the MenuProcessor has no data object which passes the required fields back.

         ` menu = TEXT
            menu {
                dataProcessing {
                    10 = FriendsOfTYPO3\Headless\DataProcessing\MenuProcessor 
                    10 {
                        special = list
                        special.value.field = pages
                        as = menu
                        dataProcessing {
                            10 = FriendsOfTYPO3\Headless\DataProcessing\FilesProcessor
                            10 {
                                references.fieldName = menu_image
                                as = image
                                processingConfiguration.height = {$projects.image.height}
                                processingConfiguration.width = {$projects.image.width}
                            }
                            20 = TYPO3\CMS\Frontend\DataProcessing\DatabaseQueryProcessor
                            20 {
                                as = categories
                                selectFields = sys_category.title
                                table = sys_category
                                pidInList = root,-1
                                where = sys_category_record_mm.uid_foreign = {field:uid}
                                where.insertData = 1
                                leftjoin = sys_category_record_mm ON sys_category_record_mm.uid_local = sys_category.uid
                            }
                        }
                    }
                }
            }`

Unfortunately it seems not possible to customize the TypoScript configuration of FriendsOfTYPO3\MenuProcessor e.g. to append a new field "id": to the response. I need a unique value for each menu entry... and using the link value is hard to deal with because of type string.

Just out of curiosity I was trying this, but I guess this is not how the dataProcessing works in general^^

lib.primaryNavigation {
  dataProcessing {
    10 {
      stdWrap.cObject.100 = TEXT
      stdWrap.cObject.100 {
        field = uid
        wrap = "id":|
      }
    }
  }
}

Enable typolink hook only if headless typoscript template is enabled, because right now, we break typolink for non-headless instances

Find way to get rid of ###BREAK### when fetching content.

Not sure if this is possible already out of the box, can you as developer say something to this? If it's not possible, this would be a good feature-resquest as the user management is one of the strength of TYPO3 over other systems in my opinion, which should work especially in web-apps.

Hi,
the MenuProcessor used in Configuration/TypoScript/ContentElement/MenuPages.typoscript is TYPO3\CMS\Frontend\DataProcessing\MenuProcessor. But this outputs every single DB column of the page. This should probably be FriendsOfTYPO3\Headless\DataProcessing\MenuProcessor (like in the other menu content elements) to limit the fields that are displayed in the json.

But when changing the namespace the chained FilesProcessor is throwing an exception.

Changing the dataprocessing on the toplevel JSON (not on the fields) to something like this

• dataprocessing changes cObj->data
• fields statements then can pick their content
  Needs some more thinking for:
• nested structures like resolved flexforms, how to pick whole chunks or deep nested fields

Hi guys,
sorry for opening so many issues. 🙈

Would it be possible to add a tag to the repo so we don’t have to checkout dev-master? Alternatively (or additionally 🙂) the branch-alias functionality of composer.json could be used.

for example:

"extra": {
    "branch-alias": {
      "dev-master": "1.0.x-dev"
    }
  }

So we could simply use ^1.0 in our own projects composer.json and don’t have to bother changing the version when v1.0 is finally released/a tag is created.

best,
Ramón