Woooooooohoooooooo!!!!!!

If you installed a plug-in it won't magically delete itself from your server. So no sites will break.

It's up to the maintainers to remove Timer v1 from the WordPress plug-in directory. However it would be a bit too soon to do this imho. Even if they delete if from the WordPress plug-in directory, that won't delete it from your site.

I have a few sites using the Timber plugin version on WP and today i found the time to transition on my local env. one of them from the plugin to using composer. I can say it wasn't such a big task, but i guess that depends on your own implementation. So far all runs as before, but too early to really commit all this to the staging then live env.

The rest of my sites that are deployed run fine with the plugin version of Timber so unless i delete the plugin they will work fine. I do have the latest version of the plugin somewhere safe just in case.

Hi @claudiugubernu , did you directly update to v2 or to did you move to the composer v1 version? I would recommend to move to the composer version and in the long run update to v2.

Hi @Levdbas , initially i have moved to composer v1, but after the comment spent a few hours and updated to v2 on a different branch.

It was a bit of a search&replace but so far ( for the site i have chose to migrate and update to composer Timber v2) all works as before.

Had some issues with CPT that mixes ACF with native thumbnail image but i managed to resolve that by doing the following:

changed this :
{% include 'atoms/image.twig' with { 'image' : TimberImage(services_post) } %}
to:

{% for services_post in services_posts %}
  {% set post = get_post(services_post.ID) %}
  {% services_post.title %}
  {% services_post.description%}
  {% include 'atoms/image.twig' with { 'image' : get_image(post.thumbnail) } %}

{% endfor %}

thinking of adding this into php where i set the $context['services_posts];

Not brave enough to go live with all this so will test furthure on a staging env. but must reiterate this project is a brochoure car valeting site. Thank you

@Maffsie you are good to keep doing exactly that. With the supported version of Timber (2.x) we will continue development, issue resolution and patches changes in Twig, WordPress and PHP versions — this is what we mean by "support."

Version 1.x and the deployment to WordPress.org still exist and we intend to keep them there as long as the good people at WordPress.org will allow it (indefinitely, as we understand) so you are good to keep using it for both existing and new sites.

Hi @addedlovely , thank you for the suggestion! @jarednova , I just committed the correct link in wp-plugin branch. Could you push the readme.txt file to SVN?

This is now complete. Thanks so much for the fix @addedlovely + @Levdbas !

... this is now complete ✅

See https://timber.github.io/docs/v1/getting-started/switch-to-composer/ and https://timber.github.io/docs/v2/upgrade-guides/2.0/ to update to the latest version.

Thanks. I am not a developer and running those codes it outside what I know to get that done. How long would it take someone to get those updated?

Really depends on the size of the website, how old the codebase is, how much the site relies on Timber.
My projects usually take around 5 hours up to two day to update.

You could use the timber/post/import_data instead to import the data on the build method.
Use the ->realize() or ->to_array() functionality to directly instantiate the post with all the data. This is probably the solution to directly access all the post data instead of lazily. Read more about this here: https://timber.github.io/docs/v2/guides/posts/#post-collections

Furthermore, our solution highly depends on the presence of the ACF fields on the post instance, as Timber 1 provided them earlier. To avoid the enormous changes in the existing code, we decided to extend the Timber\Post class keeping the ability of the usage of constructors and providing the ACF fields.

This seems like a reasonable approach for your use case.

Upgrading to Timber 2 doesn’t necessarily mean you have to do everything in a way that is proposed in the documentation.

In Timber 2, we tried to make it possible (and maybe easier) to extend Timber for use cases like yours. So if you load all custom fields into a property custom, then that’s totally fine and should also work in the future.

I’d say eventually, it would be better if you used Timber::get_post() instead of directly instantiating posts and worked with a Class Map to select the right class for your post to be built with. Because changing the visibility of __construct() to public in your child class is not a best coding practice.

But, you chose a compromise here, which should work for now.

Could other approaches and solutions be mentioned?

Other than what @Levdbas mentioned, I wonder whether you could ditch your custom get_post_custom() method and use meta() instead. If you don’t pass a field name to meta(), it should all fields.

And maybe you would have to enable transforms as well, see https://timber.github.io/docs/v2/hooks/filters/#timber/meta/transform_value.