Introduction of a credit function in the theme

I would like to propose the introduction of the credits function in the CP core. This would make it possible to standardize the introduction of credits in the theme and avoid errors even in defining the name of ClassicPress. For any customization it is sufficient to use the filter. The theme developer would be required to use the feature to introduce both ClassiPress credits and their own credits (using the appropriate filter).

// return with filter
get_footer_credits() {
      $cp = sprintf( esc_html__('Powered by %s'), '<a href="">ClassicPress</a>' );
       $html = '<div class="footer-credits">' . $cp . '</div>';

        * @param string $html html output
        * @param string $cp html link to ClassiPress
       $credits = apply_filters( 'footer_credits', $html, $cp );
       return $credits;

// output
footer_credits() {
      echo get_footer_credits();

Any improvements to my script are welcome.

It’s not a big innovation, but I’ve found that when creating themes, this creates correction requests during reviews.

I don’t like having those credits in general, and my clients don’t like it in specific, so I would be against this.
There’s no reason that front end content has to be standardized.
The way this is coded makes it very difficult to filter, so anyone using it would simply replace it completely, so why have it?

If you want the name of the software, make this function a little more general (as is, it only returns something to a filter or action):


Obviously, if you refer to commercial themes, or themes created on request of a customer (as in your case), the matter is different. For these, you can do whatever you want, even simply not inserting in the site footer any footer_credits() or inserting a direct html code.

Instead, I’m referring to standard themes, the ones that will be placed in the official theme repository, for which the introduction of credits on who made the theme and on the script that is used for the website is a rule if not a required element, subject to standard rules, in default of which the theme is not approved. This is because these themes must have certain standard features precisely.

The filter is instead, for me, an important element, because it helps to create clean code in the template files and allows to create customizations of the theme, concentrating the customizations in one place, without spreading them all over the theme files.

I am not sure where, but I clearly remember to read that “CP Child Themes” (such as provided in the fresh install) “Do not put any footer credit notices on your sites”.
And yet they do. I must have been dreaming.

Partially, the brand protection is already implemented with capital_P_dangit() | Function | ClassicPress Documentation

It works on Title and Post body, but it works only if you use Classicpress, not if you use classicpress, so IMO that should receive an update.
Also this will not catch eventual stuff echoed elsewhere with PHP.

Perhaps, that function could be used as a template to return the proper name of CP?
So a developer (and our child themes) could use it to then echo the proper name.
I do not agree that a full HTML div + href should be part of the function, but on the other hand why not, if it is a bit more controllable (the current implementation would ask you to run regex or str_replace on the HTML to actually alter that)
I think since it allows to echo unescaped content after filter application - which might be suboptimal - this at least should be clarified in the function description that the HTML returned by it might be unsafe as filterable, or avoided altogether.

If HTML, then things like footer-credits probably are a bit broad. I think it should be prefixed, just to avoid any clash with eventual other broad CSS classes?

when creating themes, this creates correction requests during reviews

I am not sure to understand. You have been asked by CP reviewers for themes (which literally do not exit afaik) to add CP footer credits? We do not even have a Theme Dir yet, and as far I know, no review is done on themes, you cannot even submit some. And clearly asking a dev to add such notes would be totally unacceptable.

1 Like


I am not sure to understand. You have been asked by CP reviewers for themes (which literally do not exit afaik) to add CP footer credits? We do not even have a Theme Dir yet, and as far I know, no review is done on themes, you cannot even submit some. And clearly asking a dev to add such notes would be totally unacceptable.

No. I made the example based on what happens on WP. Since CP doesn’t have a repository yet, there is no experience that can be used. Maybe, on CP things could be organized differently or with totally or partially different rules.

On escaping, right. But I only proposed an example function. Javascript should probably not be allowed through the use of the filter. In any case, my idea is to create uniformity and give a precise directive on how credits should be inserted, if you create a repository of themes and these credits are considered essential requirements. Equally, my idea is also to ensure that the name of ClassicPress with the correct url is returned correctly. I’m always talking about standard themes to be included in a hypothetical official repository (which isn’t there yet) and not commercial or non-standard themes not intended for the official repository and for which, customers maybe don’t want a link to ClassicPress or the theme creator.

In any case, it’s just an idea and many of the objections and perplexities you have raised, have their own reason anyway. :slight_smile:

1 Like

This is just forcing standards on something that shouldn’t be standard at all.

  • People who want credits can add them however and wherever they like
  • People who don’t want credits don’t even bother with that, and don’t need to have bloat on their CMS

Less is more.


I think you might have misunderstood what happens at WP. I’ve reviewed a lot of themes there, and there is no requirement to use footer credits. There is a requirement to use the correct capitalization of WordPress, but only if you want to output that. And there is a requirement to give credit if you used other code, but only in the readme. And there is a requirement to only use one reference to the author on the front end (in the footer), if you want to put one, and that must be able to be disabled by the user.

I can see how you might misinterpret those requirements to mean that you have to put a credit link in the footer, but that is not what they mean.
I hope that the CP requirements are similar, and don’t require a footer link.

1 Like

Yes, true. WP doesn’t require the display of author credits or its as a requirement. But that’s still not the point. Maybe I’ve been misunderstood, because not being a native english speaker I might have expressed myself wrong. I simply mean that if you decide to insert these credits, it would be interesting to offer to those who want to do it, a function easy to use.

As for the rules of publication, well … whether there is an obligation or not seems to me to be a matter beyond my proposal. This was not the point anyway.

But again, at the end of the day it is still a minor proposal that can be dispensed with.

This time I got help from an automatic translator to be sure not to make mistakes …!!! :sweat_smile:

I suggest you create a pr.
There’s no bloat in this, not used == not loaded.
A few bits more code isn’t going to slow down a site.

Then, people can suggest edits thru actual code contribution or feedback.

Next it will be a slider or action button, and then blocks!

The function doesn’t belong in core because it doesn’t use anything unique to core except apply_filters, and that should be done by my suggested code.

1 Like

I do not understand how that resolves what’s proposed and exposed here

Also, if the person here has the capacity to write this code - and if review passes, which it won’t at this stage - let people please be free to contribute and let contributions that do something go over meaningless discussions that do nothing.

As it stands it’s still a free world and everyone’s able to commit to core. if that code ever gets included is another question.

Having a PR standing increases the chances for this person to get his idea done, as the person can contribute to it. It doesn’t mean it gets done.

I’m all for doers over talkers, to be honest. You got an idea? Provide it and let both community and actual contributions decide.

A handy and unified brand oriented tiny echo has nothing to do with blocks or swipes, and by all means, if someone wants to pr blocks or swipes or whatever, go ahead

Maybe it’d resolve the whole bunch of “cp is dead” :poop: going around or the “make it compatible with wp 5”

Just my opinion, of course

1 Like

My code is from a petition that was already voted on. It contains a way to filter all the HTML that is output (but it has to be called).

I’m not against contributing, but I obviously value discussion (and design before coding) more than you do. I consider discussion as a way to contribute.

My point was that core shouldn’t be providing front end HTML unless it is handling the core data structures, doing the logic in one place so everyone gets the correct results. There is no point in a function that simply outputs HTML, just to be “unified”. Most users want the front end to be unique, not unified. (This is one of the problems with blocks.)
And every function added to core is bloat that has to be maintained / tested (considered for backward compatibility too).

1 Like

Here we go:

Use the “ClassicPress TwentySeventeen” child theme instead! This is a parent theme that says “Powered by WordPress” in its footer.

That is what’s written in the CP parent Theme thumbnail.
That is what mislead me to believe that our theme does not do that at all, instead, it just means it does it, but changes the name.

Just for the records, nothing that contributes to the issue itself I think.

Hello everyone.

Granted that I have understood everything you have written (I am not a native English speaker), I didn’t think to create a controversy with my idea that I found useful, nor on the opportunity or even on the method.

About the opportunity, I believe - and I confirm it - that in a young community like CP any proposal should be always welcome, to encourage more and more users to participate, to intervene and therefore to make their proposals. Whether these proposals are accepted or not is a different matter. This epilogue depends on many factors, that certainly no proposer can control, also because he himself could have the doubt - hearing the opinion of others - that his proposal could be good or appropriate (and I have some doubts about my idea). But it is certain that everyone must have the full freedom to express and propose them, without being subjected to angry and almost annoyed criticism. Even the smallest and most insignificant proposal should always deserve RESPECT and attention, especially if we aim at the growth of a development community that today - let’s face it - is lacking in oxygen. And if we reject even that little bit that comes… we can also put a stone on the project, because it is certain that it will not go ahead!

On method. Personally, I’ve never claimed that my proposed solution is the best. I’m not a great expert of core, I know what is necessary to create plugins and themes (sometimes I find myself digging in the core to find solutions for my plugins), and maybe I reasoned as a developer of themes and plugins, more than as a developer of core. So, for me, always assuming the proposal as valid (and apparently it is not), any solution proposed by others, perhaps more experienced, would have been fine. But always respecting the person making the proposal.

In any case, given the situation, I will withdraw. If anything, I’ll just propose themes and plugins for CP (or compatible with CP), leaving to others ideas and methods of core development. I don’t want to make “useless” proposals or create more controversy!

Thanks for your attention and sorry!


As I said, I dont think this proposal is useless.
It will need some changes - such as I counter proposed and maybe more.

Thus, imo you are very welcome to further pursue this.

I’d start by not outputting full html but focusing on something more just for the „correct name“ echo or even a return, that the developer then can echo.

The method could be with an option to just return name or link, for example, perhaps with an array for, if with link, some link attribute values.

The next step imo can be a pr ( a fork of cp with the changes proposed) so we can look at it and amend, and propose as code.


This is for theme developers to use, so would be nice to hear from a few more.

@timkaye @benlumia007 @tradesouthwest you’ve built themes for ClassicPress, would you use a credit function proposed in this petition? I would appreciate your input, even a quick yes/no.

generally speaking, as a developer… i would never use footer credits, so my answer is no, and is definitely not needed as a CP core functionality. This footer credit should only determine if the theme developer sets it or not…

Don’t add core functionality if it doesn’t make sense or doesn’t need to be in the core itself. again, any credits should be controlled by the theme itself.

1 Like

I agree completely with Ben.

1 Like

I will and always have add a one field options/mods box in the Customizer so the person using the theme may (or may not) choose what text to put in the footer. Otherwise there will almost ALWAYS be a copyright with the date('Y') which goes to either side of the text.

Keeping it simple and not pushing anything new or core related.

Lately I have been going one step further with the text liberties and add a third box in the header—similar to footer box—so users can add “lead” text to supplement site-title, site-descripion, with site-lead text. relation/customizer.php at 922da18d7113bf24d756f9b0b5a25a4a78fb2187 · tradesouthwest/relation · GitHub line 42

As theme developers have stated, this function isn’t needed in the core. Thank you for sharing your idea.

1 Like