I'm very sorry if I sounded as I am not respectful of your time, but the problem is that we are also using too much time to review your theme because it is developed in a way that does not follow WordPress' common patterns.

It is not the set of options of the theme that is the problem but the way you write it.

I understand that you would like to make a very flexible theme with many options, but you should do it using WordPress existing functions, filters and hooks. You are creating many functions that already exist in WordPress and repeating tasks already performed by core. Reading some files, I get the feeling that you are writing WordPress again.

I also understand that you have in mind some development patterns you think are better. Unfortunately, when writing a theme, it is expected to follow the guidelines.

I know almost by heart all the functions needed to write a theme. In this case, I need to read every function you write to understand what you are doing. The task is even more difficult as you give your variables some cryptic names, or you use uncommon file extensions (What is a .wxt file?). All in all, it is an extreme requirement on a voluntary reviewer.

As I said before, you have to use WordPress own functions instead of writing your owns to do the same. As an example, WordPress has many sanitisation functions available to use in the settings of the customiser, but you are writing a lot of them again. There are functions in WordPress to do the things you intend to do with aweaver_sanitize_markup(), aweaver_esc_sanitize_markup(), aweaver_esc_markdown() or aweaver_echo_safe(). Besides, you are not using sanitisation and escaping consistently. See this link for more information. https://developer.wordpress.org/themes/theme-security/data-sanitization-escaping/. A list of sanitisation functions here.

In general, you have rewritten many things that core does instead of using its own functions. Read the Theme Developer Handbook and the Code Reference. There may be new developments that you don't know. After that, revise all the files that start with lib and see how you can simplify. The way you are dealing with the settings is overly complicated and unneeded.

Regarding the amount of options. A known result from behavioural science states that having too many open options make us lose our primary objective. A normal user with a normal mind will spend too much time learning how to use all the options your theme offers. In the meantime, they will lose what their main objective is: making a website.

Don't oblige the user to take so many small decisions. It is your role as the developer and designer to decide about many of the options you push on the user, such as the size of borders, shadows, margins or paddings. The amount of possibilities is just overwhelming. For instance, I spend a lot of time looking after the setting that puts the small menu in the header, and I could simply not find it. I had to read the code to see where I could find it. That is very frustrating as a user.
(Besides, I think this setting is not working, because after finding it and fiddling a bit with it, I can not see the small menu anywhere).

Regarding the admin styles, you have .css files, such as admin-styles.css, customizer-sections.css, that modify the admin and customiser menus. Installing and using a WordPress theme from WordPress.org repo should be a consistent experience across the board for all users, which means the admin should be the same for all themes. Your css modifies colours, icons, font-size, etc., something that should be avoided. Moreover, you don't have to modify the name of core options in the customiser.

On a small note, if the name of your theme is Absolute Weaver, the text domain should be absolute-weaver and the prefix absolute_weaver. You are using different prefixes, such as aweaver, aspen and others.

You do not have to make a simple, lite theme. You need to write a theme that I can read and understand without using hours and hours.

Kindly,

Hi ,

Thank you for your response. At least I understand a little better what your are looking for.

I'm sure that you can also understand that after working for several months with the previous reviewer, it is very very frustrating to think I was at the end, but instead am still looking at several more weeks (more like months since I'm not doing this full time, and have to allocate much more time to make the fixes you're suggesting).

As I said before, I'm dedicated to Open Source, and would really like to see this as a full, non-lite theme on WordPress.org instead of some full pay commercial site.

So before I embark on yet another set of code revision, I would both like to address your new comments, and hopefully try to find some ending criteria so that I don't spend weeks thinking I'm complying with your suggestions, only to end up back at the same place.

Based on your latest comments, here is what I think the issues are, and my proposed revisions.

You said: "As I said before, you have to use WordPress own functions instead of writing your owns to do the same."

I am having difficulty seeing this. I will scan for functions only used in one place (taking into account possible use in a premium version) and fold that code into the place it is needed. That may reduce the number of functions.

But it seems the main issue is with escaping / sanitization. I think I understand the objective fairly well: a theme must escape (for some cases) or sanitize (in other cases) all output. I believe that the main goal is to be sure output generated from the database or translated strings is safe. On the other hand, if the output is generated by the theme internally by building strings with generated HTML (tags and classes), often combined with other text, that generated text is really safe to output. The problem I've encountered and tried to solve with the few output functions I've "invented" is that when the generated output has HTML content no existing WP API function handles this case properly. So when the theme is run through Theme Sniffer, any attempt to use the PHP echo function is flagged. As far as I know, there is no escape/sanitize function that will simply echo known safe text. Thus, there are many places where a safe constructed string is passed through aweaver_echo_safe(). At least it is easier to identify that case so the theme coder knows what is happening.

Question: Do you have a better alternative for echoing safe constructed HTML strings that will please Theme Sniffer? I would like to at least keep absolute_weaver_echo_safe() or similar rather than wp_kses().

The other issue with sanitization I've tried to solve comes with trying to add HTML tags to Customizer text - especially longer sections of help text that includes links. I also find using selective italics and bolding makes the help text more understandable. So I've created a few Customizer custom controls for displaying text with HTML. I also played with adding some simple markdown instead of HTML to make it a bit easier for translators. So Customizer help text that has any sort of HTML, be that links or simple Bold/Italic cannot be displayed using all the normal esc_ functions. To me, it was more readable to use something like aweaver_sanitize_markup() rather than direct calls to wp_kses_post(), which is used by aweaver_sanitize_markup(). And it also left the possibility of actually using a custom call to wp_kses() that had a really restricted set of HTML tags in the sanitize_markup() function.

Question: Is it really forbidden to add a bit of styling to help and information text in the Customizer so that esc_html() is the only esc_ mechanism? What about links? There is no single esc/sanitizer I can find that can be used to allow links (other than an underlying wp_kses()).