ACF is a staple plugin of many Wordpress developers, and it can be a really handy thing, especially for smaller projects that need a quick turn around. But there are some problems with its use, which I have all to often seen overlooked.
To be clear from the outset, I am not saying do not use this plugin. But I am saying, do not blindly use it. There are some important things you should consider before installing Advanced Custom Fields and integrating it into a project.
Do not let this plugin stunt your growth as a developer
Using this plugin means a developer does not have to learn as much about Wordpress or its internal workings. It essentially allows developers to use a vast amount of Wordpress functionality through a WYSIWYG editor. As such it stunts their growth and their need to understand the CMS and its workings thoroughly.
To give an analogy Its like a car engineer saying "I don't need to lift the hood and see what's going on, this bit of kit does it all for me" which is all well and good. Until that bit of kit fails and you realise you have no idea how anything works without it and are unable to fix the problem.
It makes you reliant on a third party developer
One man develops ACF. I do not doubt for one moment that he is a very talented developer. But do you know this guy? Is he sitting in your studio? Can you contact him by telephone? Can you even get a direct email address?
It is simply bad business practise to rely on someone that you do not know and will probably never meet. Now imagine this person had integral code in all your Wordpress installations; to anyone with half a business brain, this is just a huge risk.
It encourages sloppy architecture
Using ACF, you can very quickly create fields, which can be used to achieve all manner of things. It encourages developers not to sit, think and plan architecture. But to quickly build and if it doesn't work, worry about it later.
It is very easy to weave yourself into a mess of undocumented fields. This can make is very hard when working in a team and can often make for a legacy nightmare.
As we all know, legacy nightmare = unhappy staff and clients.
What if the plugin breaks?
The slider at the top of the page? That relies on ACF. The text throughout the page? That relies on ACF too. Now imagine if ACF broke. It has the potential to completely take a website out if the website is dependent upon the plugin.
What if it doesn't play nice with other plugins?
In a previous role, I had to take over a project and convert it not to use ACF after it became apparent that it doesn't play well with WPML. WPML is a translations plugin; a translatable website was part of the project agreement. This caused a significant problem in the project and, in the end, I had to recode all the custom fields by hand.
Update 23/02/16: i can confirm that ACF now plays better with WPML - it works, although it is still a little buggy.
How to use ACF Safely
I used to have an outright hardline attitude of "just don't use it" when it came to ACF. But I think that was driven by the fact as the senior developer in a previous role, I had it forced upon me by management, and I had to on more than one occasion clean up the mess other people had made while being over-reliant upon the plugin.
Now, however, I think it can be a valuable tool. But only when the correct precautions are used. To be able to use this plugin safely. I believe the following should be pre-requisites.
1) Do what the plugin can do
The developer using the plugin should be able to do everything the plugin can do and should be using it only to save time on laborious tasks. NOT because they don't know how to make custom fields in Wordpress and are using it to plug holes in their knowledge. By making sure the developer could do what the plugin does manually, you are insuring yourself against the plugin breaking in the future as you know, worse case scenario it can be fixed by hand.
2) Factor it into the Functional Spec / Terms & Conditions
Try and get something in there about third party plugins and where liability lay should third party code break. Something to help cover you in the event of catastrophic failure.
3) Factor it into your risk assessment
When planning and budgeting projects. Factor in the risk of this plugin breaking, the cost to the company and the project should this happen. It may be a better idea not to use it at all if you can not afford the risk.
4) Plan before use
In your technical specification plan what fields you will create, what they will be used for, and their naming conventions. Do not make them up on the fly.
Used correctly this plugin can benefit the developer, agency and client; its a great plugin - just do not become entirely reliant on it.