8
There is a known issue where if you use a variable name 'entry' in any template involved in a Live Preview request (including layout templates), then it can cause the behavior you're seeing.
Some examples are:
{% set entry = craft.entries. ... .find() %}
or
{% for entry in craft.entries. ... .find() %}
The workaround is to rename that variable to ...
7
Live Preview will be available when the following are true:
The section’s “Entries in this section have their own URLs” setting is checked
The section’s “Entry Template” setting points to a valid template path
The entry has been saved
It doesn’t matter if the entry is enabled or not.
7
Not sure what your end url is but I think you'll need either a "/" or {{ siteUrl }} before "assets" in "assets/bootstrap/css/bootstrap.min.css".
so (for all references to css etc.)
<link href="{{ siteUrl }}assets/bootstrap/css/bootstrap.min.css" rel="stylesheet">
or
<link href="/assets/bootstrap/css/bootstrap.min.css" rel="stylesheet">
6
Just want to mention for anyone running across this thread that if you're having a problem with live preview and seeing dev tools errors of the nature of cors or crossdomain then the first thing you might want to check is that if the domain you're serving the site (the control panel, specifically), is the same as what you have set in "Settings | General ...
6
Another cause of Live Preview not working that can be a pain to debug, because there are no 'errors' as such is your .htaccess setup. For example, on one site we had the following .htaccess entry to force trailing slashes (at server level, not Craft's config option) in order to prevent duplicate listings in the client's analytics:
# Force trailing slash:
...
6
Craft 3.2 introduces Headless Preview which works a treat with SPA's. Essentially Craft exposes tokens which you can forward on to subsequent Element API requests and Craft will do the rest. The interesting thing to note with this release is that Live Preview isn't actually "live" rather draft entries that are saved and accessible by tokens generated to ...
5
It's definitely a bug in live preview but looks like you can work around it.
This doesn't appear documented at all—so be careful—but you can use .status() to get the block's status. It looks like an IF block is enough to get a matrix block to refresh the live preview.
{%for block in entry.matrixBlock %}
{% if ( block.type == 'supertable' and block....
5
I noticed the same issue with live preview, but using the type property on the Matrix field: Issue with Matrix type property and Live Preview? According to Brandon's answer this is a current bug / limitation of the Matrix field that you have to find a workaround for.
In this case this is rather easy, get all the blocks and use the slice filter to loop over ...
5
Live preview have gone through a major refactoring for Craft 3.2, which addresses this issue. For Craft 3.1 and below see solutions below.
This is happening because Matrix will only show the non-live blocks so long as you don’t set any Matrix parameters in your template. As soon as you tell it to only show blocks of a certain type, it no longer feels ...
5
Craft's Request service has a built-in method for this, isLivePreview.
Here's how to only display content in the live preview view:
{% if craft.request.isLivePreview %}
<p>Only appears in live preview.</p>
{% endif %}
4
We just changed this behavior in Craft 2.3.2616:
Live Preview and Share links will now show the unpublished entry/category changes wherever the entry/category are being referenced in the templates (even areas where the entry/category was fetched from the database).
So now Live Preview (and Share links) should work as expected for you.
4
Accepted answer helped me, my issue was Ajax related as well! Here is an example of the code I ended up using in my template.
{% extends (craft.request.isAjax and not craft.request.isLivePreview) ? "_ajaxLayout" : "_layout" %}
4
Site title - This is set with HTML meta tags and not really anything to do with Craft specifically. It depends how you "switched" from wordpress to Craft. Inside your document head, you need to include a title tag, like:
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en-US">
<head>
<title>Website title goes here&...
4
I'm not completely sure, but would setting site_url to always be whatever the server host is work in this case? In my general.php I use the following before the config array:
$protocol = (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] == 'on') ? 'https://' : 'http://';
$base_url = $protocol . $_SERVER['HTTP_HOST'] . '/';
define('CRAFT_SITE_URL', $...
3
Only setting headers in .htaccess doesn't fix the problem.
As Marion Newlevant points out in her answer the cross domain works with the headers set. But you still get a white page as a preview.
Looking further into the problem, I've found that the page tries to do a post request to the other domain.
It calls upon the action function actionPreviewEntry() in ...
3
Change:
{% for entry in craft.entries.section('flashback') %}
To:
{% for entry in craft.entries.section('flashback').status(null) %}
The 2nd one will grab all entries regardless of their enabled/disabled status.
3
If you're using SEOmatic - no. It's built in that the GA doesn't get spat out for the preview. If you're using a regular template - yes; you may want to wrap your GA code in a conditional so that it's not spat out when requested via the live preview.
{% if not craft.config.devMode and not craft.request.isLivePreview %}{# GA code here #}{% else %}<!-- ...
3
CORS (or Cross-Origin Resource Sharing) issues usually occur when you are attempting to load a resource such as a font, a stylesheet, or a script from a remote location that does not give your domain explicit permission to access it. Thinking the resource is unsafe, your browser will block it.
Are these pages attempting to load any resources from remote ...
3
Ok, so after going through the logs in craft/storage/runtime I found the problem.
I'm using environment variables for my sites url and had it set to:
mysite.com
However when going to the site using Safari or Firefox it was tacking on the www subdomain so I was actually at www.mysite.com. I guess according to that CORS thing the subdomain of www didn't ...
3
In order to get Live Preview to work across different subdomains on a single install, you'll need to setup a few extra things as outlined in this support article: https://craftcms.com/support/cross-domain-live-preview
3
Update:
As of Craft 3.2 there is native support for headless previews. Please
see Cue's extensive answer for a detailed
explanation.
Original answer
I managed to do this, although I'm still not quite happy with it.
First part of the solution is figuring out whether this is a live preview. To do so, I decided to append data attributes to the HTML element. ...
3
Since Craft 3.3.1, you can create a custom alias that resolves to your frontend base URL, and add that alias to the relevant preview targets' "URL Format" setting.
For example, assuming you put something like the below in your config/general.php file:
'aliases' => [
'@previewBaseUrl' => 'https://domain.com',
],
...you'd be able to use that @...
answered Dec 28 '19 at 20:55
Mats Mikkel Rummelhoff
18.8k3 gold badges26 silver badges59 bronze badges
2
Be sure to look for JavaScript errors as well! I was having the same trouble with a CloudFlare-enabled site, and it turned out that the Rocket Loader feature was choking and keeping previews from working properly. Otherwise no entry variables in play.
2
The problem was my attempt to ajaxify the page.
I had my block content wrapped around
{% if not craft.request.isAjax %}
the page also gets loaded in via Ajax into the control panel, I changed the code to:
{% if not craft.request.isAjax or craft.request.isLivePreview %}
Now it works.
2
Looks like it's generating a 500 Internal Server Error which means the underlying error message should be getting logged into your craft/storage/runtime/logs files. Just reproduce the problem and check for an entry with [error] severity.
2
Update:
Thanks to P&T this workaround is not necessary any more with Craft 2.3.2616!
This was my temporary solution / bugfix:
I think you're right, Live Preview seems to only update if changes to the automatically provided entry EntryModel are detected.
So this causes problems with Live Preview:
{# Get `entry` manually #}
{% set home = craft.entries....
2
It is (currently) not possible to set an Entry Template without selecting "Entries in this section have their own URLs" in the settings.
So to make Live Preview available on your "slides" entries, you have to register the URLs.
But if you use hidden / pseudo URLs (i.e. hideme/{slug}) that you don't link to and nobody knows of, this shouldn't be that bad of a ...
2
If you define your base site URLs using the siteUrl config setting (using the array syntax), then clicking the “Share” button should bring you to the appropriate locale’s URL.
2
There is currently no out-of-the-box way to do that.
You might be able to pull it off with something like the CP-CSS plugin, but I'm not sure how you'd just target the tab when the Live Preview pane is open.
Otherwise, you can always make a feature request!
2
Another possible source of Live Preview not working is your siteUrl config setting pointing to the wrong environment in a multi-environment setting.
I had this problem when I'd set siteUrl globally in the config but had forgotten to override it for the staging environment that Live Preview was failing in. Adding a siteUrl for the staging environment fixed ...
Only top voted, non community-wiki answers of a minimum length are eligible