can we still use this pattern if ConcreteFactory1 needs to createProductC() but ConcreteFactory2 don't?

You have some design options here:

1. Create a separate abstract factory for creating C's. It's often useful break up your abstract factory interfaces by product unlike how the UML diagram has grouped CreateProductA and CreateProductB in the same interface. I think this is the right choice if product C doesn't have much in common with the other products.
2. Keep createProductC in the same abstract factory, but change its signature to return either ProductC or nothing (in Java this would be Option[ProductC]. This will enforce clients to handle the fact that some concrete factories don't produce a product C. Alternatively throw a checked exception. I think this is the right choice if product C is closely related to products A and B and production of C is truly optional, and clients should only call it if it's available on the factory.

can we still use this pattern if ConcreteFactory1 needs to createProductC() but ConcreteFactory2 don't?

You have some design options here:

1. Create a separate abstract factory for creating C's. It's often useful break up your abstract factory interfaces by product unlike how the UML diagram has grouped CreateProductA and CreateProductB in the same interface. I think this is the right choice if product C doesn't have much in common with the other products.
2. Keep createProductC in the same abstract factory, but change its signature to return either ProductC or nothing (in Java this would be Option[ProductC]). This will enforce clients to handle the fact that some concrete factories don't produce a product C. Alternatively throw a checked exception. I think this is the right choice if product C is closely related to products A and B and production of C is truly optional, and clients should only call it if it's available on the factory.

But my question is, can we still use this pattern if ConcreteFactory1 needs to createProductC() but ConcreteFactory2 don't?

You have some design options here:

1. Create a separate abstract factory for creating C's. It's often useful break up your abstract factory interfaces by product unlike how the UML diagram has grouped CreateProductA and CreateProductB in the same interface. I think this is the right choice if product C doesn't have much in common with the other products.
2. Keep createProductC in the same abstract factory, but change its signature to return either ProductC or nothing (in Java this would be Option[ProductC]. This will enforce clients to handle the fact that some concrete factories don't produce a product C. Alternatively throw a checked exception. I think this is the right choice if product C is closely related to products A and B and production of C is truly optional, and clients should only call it if it's available on the factory.

can we still use this pattern if ConcreteFactory1 needs to createProductC() but ConcreteFactory2 don't?

You have some design options here:

1. Create a separate abstract factory for creating C's. It's often useful break up your abstract factory interfaces by product unlike how the UML diagram has grouped CreateProductA and CreateProductB in the same interface. I think this is the right choice if product C doesn't have much in common with the other products.
2. Keep createProductC in the same abstract factory, but change its signature to return either ProductC or nothing (in Java this would be Option[ProductC]. This will enforce clients to handle the fact that some concrete factories don't produce a product C. Alternatively throw a checked exception. I think this is the right choice if product C is closely related to products A and B and production of C is truly optional, and clients should only call it if it's available on the factory.