Drop advanced from logic

[sinukaarel]

Dropping advanced form generation and display. This functionality provides more complexity than the feature requires.

The feature was meant to allow customizing the form, but the average user who requires form customization doesn't know anything about customizing HTML. The tool is too advanced for non-developers and doesn't provide any extra value for a developer. The functionality can be implemented using the built-in functionality of a custom HTML block.

[sinukaarel]

@kaittodesk I need a product side approval here.

Let's drop the advanced form and find a solution that provides visual customization options for non-developers.

There are two cases here: people using classic themes (like Astra) and our widget and people using a block-based theme and the block component. We should allow customizing the basic form styles on both occasions using simple CSS logic:

• colors, border radiuses, positioning of the label, button colors and text, etc. The customization of these elements should be part of the UI that the user can manipulate.

Another thing is that these basic forms should be available to users on the free tier / not having to set up an API connection. Previously this didn't matter but currently, the setup process halts the usage of the integration for free tier users.

Users requiring any advanced functionality (CF7 integration, WC integration) that requires sending data over API must have a paid plan and therefore require API credential authorization.

This PR is "to be continued" for finding solutions for simple styling customization of the basic form. This means I would like to address the issues of styling and freemium usage in the following PR-s.

[kaittodesk]

Pulling @rahellinn into the conversation.

@sinukaarel, I think your comments regarding form widget/block customization and recent changes to Smaily's billing requiring paid subscription are valid. In its current form the plugin can only be used by customers on a paid subscription.

I think it is important to take a step back and re-evaluate the goal of the plugin.

Initially it was to combine functionality of separate plugins (Smaily for WP, Smaily for WooCommerce and Smaily for Contact Form 7). Since setting the initial goal time has passed and a) advanced form functionality has proved to be a potential source of vulnerabilities (demonstrated by https://www.cve.org/CVERecord?id=CVE-2024-54286), and my become an obstacle releasing the plugin to WordPress.org; b) changes have been made to Smaily's billing where API access is only available to paid subscriptions.

@rahellinn, how does this affect the goal of the plugin?

[rahellinn]

The change in packages was done with plugins in mind, so it's intentional that the plugins are not usable for customers with Free package in order to boost paid packages sales.
Visual customization options that can be utilized for non tech-savvy users are highly welcomed.

[sinukaarel]

The change in packages was done with plugins in mind, so it's intentional that the plugins are not usable for customers with Free package in order to boost paid packages sales. Visual customization options that can be utilized for non tech-savvy users are highly welcomed.

This didn't really answer the questions I am looking answers to. So we need the custom HTML insertion capability in our plugin? This feature seems to be redundant if we presume the plugin is made for paying customers.

so it's intentional that the plugins are not usable for customers with Free package

Do we want to communicate this in the plugin?