Sergeirichard

I’d like the same thing!

Thanks a lot, Michael. That certainly is well hidden!

Can you tell me, does child theming still work as before?

I had the same issue, so for what it’s worth here’s what fixed it in my case.

The update to Sydney that converted icons to SVGs required changes to the files header.php (for the burger menu) and footer.php (for the up arrow). After some frustrating changes to CSS that achieved nothing at all, I finally remembered that my my child theme had its own versions of both these files – versions which of course lacked those changes.

Simply copying a single line from each of those files in the parent theme – the change is pretty obvious – into the child ones fixed the problem. You will also need to adjust any CSS that styles these items as the selectors are different now, as has been mentioned above.

Hope this helps someone.

(As these PHP files are in use you may need to switch to another theme while you’re editing or – as I did – upload the new versions using FTP.)

Thank you. Has that behavior changed recently?

Switching to export (as file) saves the backup as a download. Which is great, but the Backup function I remember saved the file on my hosting server. When I’m on a slow connection, that’s much more useful.

Could my web hosting be preventing the file being saved on the server?

I have the same error – or the same error with different arguments:

DateTime::__construct() [datetime.--construct]: Failed to parse time string (9 d) at position 0 (9): Unexpected character

It was working fine before, but it’s been like this now for over a week. I’ve tried it with two “Rolling” apps from two different Dialogfeed accounts, both of which work in Preview.

Using only a Twitter stream in the feeds.

WordPress version 3.9.1

After some more testing I have a better idea of what’s happening. I’m using this entry in Register Helper:

//define the fields
$fields = array();
$fields[] = new PMProRH_Field(“url”, “text”, array(“class”=>”url”, “profile”=>true));

I find that this actually does add the URL to the user profile, but to a table called wp_usermeta – rather than wp_users, which is where WordPress normally puts user URLs.

The custom URL field is populated, and if you select the field and hit enter it does sent the content to wp_users – correctly formatting it on the way.

So what my Register Helper entry is doing here is not so much adding a URL to the profile as populating a field in preparation to add it. Is there anything I can do to make it submit that data automatically?