nr2012

Thank you. I will try out soon and get back here.

Ok. My bad. I have a local and a remote WP installation. I was changing code on the local but checking the API with the remote. Of course the changes would not appear.

Anyway, the code above seems to do the right thing:

type: "events"
link: "https://domain.com/events/2019/der-veranstaltung-von-heute/"

Ok thank you. I read that as well, but as I said I did not really get their proposal how to deal with the problem. Anyway, thank you,

I got it to work with this:

add_filter('rest_url', function($url) {
	// removing /wp at the end of site_url
	$pattern = '/(\S+)(\/wp\/?)$/';
	$siteURL = preg_replace($pattern, '${1}', site_url());
	$url = str_replace(home_url(), $siteURL, $url);
	return $url;
});

Because I am serving wordpress from /wp I had to replace the /wp part in my site_url as well using a regex.
I don’t know if I have to assume that this is a final solution, but reading the before mentioned issue on github, this was marked as no-fix. Unfortunately I also did not get their proposed solution.

If anyone has an idea how to handle this in a better way, please let me know.
Cheers

Hey @nabil_kadimi thank you for your input. I got one step further. I realized that the underlying problem is not not only a CORS thing, but rather that Gutenberg tries to access the REST API. But it tries to access it on my WP_HOME and not on WP_SITEURL – which is totally wrong. So in my case Gutenberg wants to access the REST API on localhost:3000, or on my netlify domain. But there is only the frontend, and no API – enabling CORS on the frontend side will not help either.

(I think it is related to this: https://github.com/WordPress/gutenberg/issues/1761) But I did not find any good solution.

Is there a way to tell gutenberg where to look for those saves?

Thanks

Ah no sry, I think you misunderstood. But thanks anyway!!!
I am just not sure if the endpoint is retrieving the additional ID as well and can show in on the API.

Because just calling the WP REST API for the posts will definitely show the posts (events) data, but how will it get the additional ID.

I guess I have to connect to that table and retrieve the custom ID depending on the post’s ID, is that right?

Sorry for being a it slow here.

Cheers

Hm… Thank you for your answer!
Would this also work if I still want to use the WP REST API?
It sounds like this second database table is somehow disconnected from WP, and maybe the REST API does not have access to that?

Or would this mean that when I write a custom endpoint I will have to get that table and merge it together with the actual event data?

Cheers

Alright. No worries.
If you have any insights on your side, feel free to share. Our solution is probably still not the best.
I am just about to work on the post preview solution, where I need to get the permalink structure of the backend which should help me choosing the right template in the frontend.

Ah well, so as far as I understand you don’t know to communicate the nonce between API and frontend, right?

I did something like this:

I send nonce and ID of the page/post in the url. In the frontend I check for the router to get the queries.

// Save query strings
    const wpnonce = rootState.route.query.preview_nonce
    const previewId = rootState.route.query.preview_id

I build my preview URL:
const previewUrl =/api/previews/v1/preview/?id=${previewId}&_wpnonce=${wpnonce}

which is of course different for your endpoint.

We then make an axios call to get the data:

export function getPreviewData (backendUrl, previewUrl) {
  return axios
    .get(<code>${backendUrl + previewUrl}</code>, {
      withCredentials: true
    })
    .then(res => res.data)
}

As you see you of course have to define your backendurl to concat the right string, then make sure to set the withCredentials to true.

And of course as said above you have to create a nonce and then change the link which is called by the preview button:

Here is the link creation code:

function custom_preview_page_link( $link ) {
	$id = get_the_ID();
	// For authentication a nonce must be created
	// otherwise the REST API does not allow users to see previews
	$nonce = wp_create_nonce( 'wp_rest' );
	$post = get_post( $id );
	$slug = $post->post_name;
	$lang = '';
	$isPost = '';

	// if we preview a post, we want to add 'posts/' to the url to link to our posts site in the frontend
	// TODO this URL schould be dynamicly the same for back- and frontend
	if ($post->post_type === 'post') {
		$isPost = '';
	}

	// if we have a new page without a slug we show /preview/ as a page
	if ($slug === '') {
		$slug = 'preview';
	}

	// Get the language of the polylang custom field
	// https://polylang.wordpress.com/documentation/documentation-for-developers/functions-reference/
	$current_lang = pll_get_post_language( $id );
	$default_lang = pll_default_language( 'slug' );

	// Only add a language if it's not the default language
	if ($current_lang !== $default_lang) {
		$lang = $current_lang . '/';
	}

	/* make sure WP_HOME (wp-config.php) always has exactly one trailing slash.
	Remove if it has multiple then add one or add one if it has no slash */
	$home_path = rtrim(WP_HOME, '/') . '/';
	$link = $home_path . $lang . $isPost . $slug . '/?preview_id='. $id. '&preview_nonce=' . $nonce . '&preview=true';
	return $link;
}
add_filter('preview_post_link', 'custom_preview_page_link');

If you preview an unpublished post we don’t have a slug.
What we obviously need to build, which I just realized ?? – is that we take different templates to show the preview if it is a post or a page, because we have different vue templates for those.

I have not fully dived into the code, but I hope this helps. Otherwise keep asking.

BTW: two generated Urls on click on the preview button:
Published post with changes:
https://www.domain.org/slug/?preview_id=382&preview_nonce=79cde05647&preview=true

And a draft (new post):
https://www.domain.org/preview/?preview_id=411&preview_nonce=79cde05647&preview=true

• This reply was modified 6 years, 7 months ago by nr2012.

@mmeridyth
Hey, no we also have them running completely separately.
I don’t really understand exactly what you are asking. Your functions.php is not in the wordpress codebase?
Maybe you could elaborate this a bit. Your backend has to provide a nonce and with this you should be able to access the API via your vue application.

I indeed did get the preview for drafts to work as well.
Just tell me what kind of help you need. I did this a few months ago, so I don’t have everything present anymore.

Cheers

It was indeed the polylang plugin. It has the rights to change the permalinks, because it has to set the lang tag:

e.g.: the englisch home should have the permalink
/en/home

Obviously something in this process was fucked up. By updating the polylang plugin it fixed the problem.

Thanks for the support and cheers

Hi bcworkz

Thanks for your input. This is very helpful.
We did not set the page to ?frontpage? – it’s just a normal page.
And it has nothing to do with the frontpage anyway. I experience this behaviour on all the pages!

I will check the DB entry, but the strange thing is, that accessing the endpoint the first time after saving the slug, the REST API actually returns the correct (changed) slug. Only right after it will be switched back. It is really strange.

The good thing is that we have a completely decoupled backend to our frontend. We generate static htmls including the data, so we can tinker around in the backend as we like.

Anyway. I will try to find out what the polylangs role is in this mess.
Cheers

Thanks for your input. I made a short screen recording, which shows the impossible: https://streamable.com/8p7qy

I am also not able to reproduce the bevhavior on other pages (same WP, mostly the same plugins)
I deactivated all the plugins which I could (I need to have the plugin Polylang activated, otherwise my REST API endpoint will fail). But even then I have this automatic replacement.

The replacement only happens if this very page data is displayed in an REST API call. Meaning if I change it to ?home??and call /api/wp/v2 (which is equal to wp-json/wp/v2 in our case) there is no effect on the permalink. If I call /api/wp/v2/pages?per_page=4000 which actually displays the data, we have this strange automatic change to ?startseite?.

You are definitely right to use the page ID, but we have a bilingual page and we wanted to have the german home to have the permalink /home and the englisch en/home and then we just check for the home slug for some redirecting. Anyway, the page is built and it worked, we just now experience those problems with this strange behavior.

It can be reproduced by doing this on another computer, and we experienced it the first time when our Netlify build process accessed the api endpoint.

(Just that you are not confused, we are replacing /wp-json/wp/v2 in the url with /api/wp/v2)

I also say that it cannot be any caching issue, due to the fact, that we never had the permalink being ?startseite?. It must have changed at some point and it always takes the pages title as slug.

So is there maybe a setting that forces the permalinks to be just like the page-title?

I really have no explanation for this. At all.

Hi @maggiesadler

I got it all sorted as well.
https://github.com/airesvsg/acf-to-rest-api/issues/190
airesvsg answered with something like you are proposing. Maybe you even got that information from there.. :).

Well thanks anyway.
Cheers

Thank you very much for your help @bcworkz and @airesvg!
It’s all good now!