Tony Girling

Documentation (https://www.advancedcustomfields.com/resources/acf_register_block/) says Added in version 5.0.0.

When do we expect this in a stable release?

• This reply was modified 6 years, 1 month ago by Tony Girling.

FYI: I too experienced this issue today. I was running on PHP 7 so I dropped back to 5.6 which fixed the problem.
My WP version and Plugins were a bit out of date. So I did an update to all the plugins first and the problem went away (I was toggling between 5.6 and 7 and refreshing the index page). Not sure which plugin was causing the problem but I have a list of the old versions if anybody wants a reference). Finally updated WP to latest.
Strangely other sites equally out of date didn’t have an issue (different plugins).

No secret @pedro-magnifico. Just have to learn how to write plugins.

I gave up waiting for a reply and wrote my own solution. No bloatware and I know it works and if/when dependencies change I can fix it.

Simples.

Not working for me too.

Something broke since 2011?
sevenspark.com, wordpress-plugins, how-to-dynamically-set-the-recipient-to-email-address-in-contact-form-7

I too seemed to be losing settings/customisations.

I was going to do some more investigations, but as Kevin has seen a similar issue I thought I’d share what I’ve observed so far.

I’m using 18 Tags with Page Builder Premium (with all the add-ons enabled).

Some of my pages are not showing the background I set. I think (need to verify) that one customiser is fighting with another – especially if I set a value then try to unset it. The value goes to blank/empty, but IMHO should be ignored altogether.

Example is a page with a background set (body.custom-background) but is overridden with ‘nothing’ (body.pootle-page-customizer-active.

CSS generated….

body.custom-background {
background-image: url('https://www.ashbrook-build.dev/wp-content/uploads/2016/07/background_2.jpg');
background-repeat: no-repeat;
background-position: top left;
background-attachment: scroll;
}

body.pootle-page-customizer-active {
background: url() no-repeat scroll center/cover !important;
background-size: cover
}

I’m still on old version on my main dev machine (for support purposes), I verified the version fix on a spare machine.

For now my get-around is to install an old version of WP and then immediately do an update to WP 4.4

Maybe I’m a bit reticent of digging into my pocket & upgrading DesktopServer though I do have a 20% discount coupon code.

OK. This is not a WordPress kit issue.

I downloaded the other kit, overlaid it in the root that was failing and it installed OK.

After experimenting and doing file differences it appears that the install.php is being modified by DesktopServer. It’s great platform for doing quick local WP installs for testing/developing, but I’m assuming it makes it’s on mods to install.php on the fly because it sets up mySql as part of the install process. So I guess it’s pre-filling the database credentials. Great if it works.

I assume WP 4.4 install.php has changed considerably and DesktopServer has not kept pace.

I’ll either have to update my copy of DesktopServer (long overdue) or get onto their support (probably fail there because I’m not running latest).

I’ll mark as resolved.

No. Upgrading from the dashboard works OK. I upgraded a live site with no problems. It’s just a clean install that a bombs out.

It happens if I browse directly to install.php, or if I browse to default, index.php, because there’s no config file and it starts the installer.

I’ll re-try with the tar.gz kit in a while to see if that behaves the same.