CUNY Academic Commons

Hi Diane - It appears that you've sent a modified version of the colormag theme, rather than a child theme. Generally, if you're only making minor modifications, we'd prefer you to create a true child theme. This way, when we update the main Colormag theme in the future, you'll automatically receive those updates.

As for the specifics, it appears that your only changes are in the function `colormag_entry_meta()`. The way that functions in Colormag's inc/functions.php file are written is what WP calls "pluggable". Because they're wrapped in a function_exists() checks, you can put a modified version of the function into your child theme's functions.php file, and it will be used instead of the version of the function that comes with Colormag. So you child theme would like this:

1. A style.css with nothing but a header (defining theme name, parent, etc) and an import statement for the Colormag CSS file
2. A functions.php file with nothing but your own version of the `colormag_entry_meta()` function

https://premium.wpmudev.org/blog/how-to-create-wordpress-child-theme/ is a pretty good guide on getting a child theme set up. Let me know if you have questions.

Hello,
I am new to creating child themes, so I have to admit I am a little confused. Actually, I thought what I had sent was a child theme. Can you tell me what specifically would have to be different about what I sent vs. what I need to send? Would the style.css and functions.php files replace the files currently being used? Also, what would the import statement for the Colormag CSS file look like? I know it's not your job to write the code, but I could use a little help with this.

The child theme would consist only of the style.css and functions.php file.

In general, child themes contain only the template files that you want to override. Those that are absent are inherited from the parent theme.

I recommend reading through the article I sent, especially the section "How Child Themes Work And Why Use Them" - it gives a fairly brief summary of the mechanics.

So, should I only submit those two files in the ZIP file?

Hi Diane - I'm afraid that WordPress's theme structure only allows you to override individual template files in a child theme, not arbitrary PHP files. The change in functions.php is possible because of the "pluggable" nature of the function in Colormag. And the related-posts template should be overrideable by placing it in an /inc/ directory in the child theme (as it's loaded with get_template_part()). But the widget change cannot be made in a child theme without some more advanced techniques (unhooking Colormag's versions and rehooking your own). The most straightforward technique is to register a copy of the widget in question, where your copy has the necessary changes. Here's more about how to register a widget in WordPress: https://code.tutsplus.com/tutorials/creating-your-own-widgets-using-various-wordpress-apis-introduction--cms-22460 You'd basically be copying over the widget class from the function, and then registering it in the way recommended by that page.

The alternative to this is to ship a modified version of the full Colormag theme (which is what you originally attached when you opened the ticket). But this requires that you and your team take responsibility for backporting all fixes from future Colormag releases (especially security fixes) to your forked theme. This is a fairly large amount of work on an ongoing basis, and I don't recommend it.

Hi Boone,
Thank you for the info. What would be required to backport all fixes from future ColorMag releases to our forked theme? Sorry - again I am unfamiliar with how some of this works. I may be able to get my team to approve this amount of work, since I know that this change in code is very important to them. I would just need to understand what exactly would be involved so I can give an estimate of the hours.

I will also look into registering the widget in the meantime. If I get approval for the first option, would it be possible to implement this on Tuesday, Feb. 13th? At least for the functions.php and related-posts.php files?

Thank you again for your explanations.

Yes, for the 13th, I can put up a child theme that includes the overrides for the related-posts.php template, as well as the pluggable function that you've modified in functions.php.

The option of backporting future fixes from ColorMag is likely out of the question. It's not just that it would require a great deal of time and effort. It would also require that a member of your team had the deep knowledge of PHP and WordPress themes in particular to be able to identify and correctly perform the backports. At worst, an incorrectly done fix could result in data loss on the Commons, so it's something we need to guard carefully against.

Please have a look at the documentation for creating WordPress widgets, and let me know if you have questions.

Hi Diane - Yes, the ColorMag theme is registering its own widget. But your child theme will have to register its own widget, which will be a duplicate of the ColorMag one, except with the minor changes you need made. So, briefly:

- Find the classes responsible for creating the widgets in question in ColorMag's widgets.php
- Copy somewhere in your own child theme (functions.php should be fine)
- Change the class names of the widgets, so that they're unique, otherwise you'll get a PHP fatal error. I also recommend you change the name of the widgets as displayed in the Dashboard, so that it's obvious which one you should be adding. Eg, instead of "TG: Featured Posts (style 2)", call it "NLF Featured Posts (style 2)" or something like that
- Ensure that you are registering your own copies of the widgets. The way ColorMag does it around line 195 of widgets.php is something you can emulate in your own child theme.

Sorry, for the previous comment I meant to add this: I have updated this file with changed widget class names. Would you be able to tell me if this is what is needed? Do I need to change all of the class names, or just the ones which alters from the original widgets?

Hi Diane - The goal is not to make modifications in an existing file. It's to provide your own widget-registering code, in your own child theme file. Copy the relevant code into functions.php in your theme.

Are you doing this work with a local WordPress development site? If so, be sure that you're running the child theme on that local installation, so you'll be certain that the code you've provided is doing what you expect it to be doing.

Hi Boone,
Thanks so much. It looks like many aspects of the child theme are working, but I am a bit confused about the widgets.php file so far. Would it be possible to package this file with the new theme, or tell me what I need to do to make that happen? In the original Colormag theme the widgets file is separate from the functions file, so I'm confused about why these tw couldn't be packaged together in the child theme.

Hi Diane - We cannot include the ColorMag widget file. It is already being included as part of the child theme inheritance, and including another version modified in the way that you've done will cause fatal errors due to duplicate function and class names.

You will need to register your own widgets in addition to the ColorMag ones. Your widgets can be mostly copied from ColorMag. Please see the instructions at https://redmine.gc.cuny.edu/issues/9175#note-13 for more details.

Oh I see, so the new widget classes should be included in the functions file, not as a separate PHP file, correct? And submitted along with the original widgets.php file that was included with the original theme?

Yes, loading them in the functions.php should be fine. You could put them into a separate file and include them if you wanted to, but that'd only be for your own organizational purposes. No need to send me the widgets.php file from the original theme - it's already loaded when your child theme is active.

My test site only seemed to inherit the style.css and functions.php files from the child theme - and nothing from the wp-content folder.

I'm not sure what you mean about wp-content - do you mean that there's nothing from colormag's /inc/ folder?

I have included a screenshot of the interface to show you what this looks like, for reference. Also, I have attached screenshots of the test site and the live site, which points to where the differences are. The test site is doing what the live site should be doing: including the guest authors as bylines, rather that the post's author.

I just took a few minutes to look at the source code. If I understand Co-Authors Plus correctly, it automatically filters post author listings if you put the following line in your functions.php:

add_filter( 'coauthors_auto_apply_template_tags', '__return_true' );

So, if I understand what you're trying to do, it should be sufficient to have nothing but that line in your functions.php - no other code necessary. This is something you should test locally.

I don't know why you're seeing the filtering happening locally. My guess is that you have modified your ColorMag parent theme locally to call the coauthors functions in the widgets.php file, while the version of the theme on the Commons does not have those mods.

Boone Gorges wrote:

My test site only seemed to inherit the style.css and functions.php files from the child theme - and nothing from the wp-content folder.

I'm not sure what you mean about wp-content - do you mean that there's nothing from colormag's /inc/ folder?

Yes, I did not use the files that I had sent you from colormag's /inc/ folder, and this seemed to work just fine for my test site.

I have included a screenshot of the interface to show you what this looks like, for reference. Also, I have attached screenshots of the test site and the live site, which points to where the differences are. The test site is doing what the live site should be doing: including the guest authors as bylines, rather that the post's author.

I just took a few minutes to look at the source code. If I understand Co-Authors Plus correctly, it automatically filters post author listings if you put the following line in your functions.php:

[...]

So, if I understand what you're trying to do, it should be sufficient to have nothing but that line in your functions.php - no other code necessary. This is something you should test locally.

Thanks for the feedback. I did test this locally, but that code did not seem to take. What did work in the functions.php was the original code I had included, which was:
<span class="byline"><span class="author vcard"><i class="fa fa-user"></i><a class="url fn n" href="" title=""></a></span></span>

I don't know why you're seeing the filtering happening locally. My guess is that you have modified your ColorMag parent theme locally to call the coauthors functions in the widgets.php file, while the version of the theme on the Commons does not have those mods.

I will re-download the re-install the ColorMag parent theme locally and see what happens. Do you have any other ideas on what the problem might be?

Hi Boone - yes, the screenshot that you attached is exactly what I am looking for! I don't know what I am doing locally that's different either, but whatever it is, I'm really glad to see the live version works. Would it be possible to implement your change, or have you already?

Awesome!! Thank you, I appreciate all your work on this. We noticed one small bug in the code: when you click the author's name in the byline, it links to the admin's author page, not the co-author's page (i.e. if you click "Joshua Sperber's name on this post: http://newlaborforum.cuny.edu/2018/02/16/making-the-grade-rating-professors/ it directs you to this page: http://newlaborforum.cuny.edu/author/svalente/. It should link to this page: http://newlaborforum.cuny.edu/author/joshua-sperber/). Is there an easy fix to either have these link to the correct pages?

I can try to figure this out through the child theme and my local site, but of course if you have any ideas on an easy fix that would be great. Thanks!

Hi Diane - At a glance, it looks like the reason is that the ColorMag theme uses the following code to generate the href:

 get_author_posts_url( get_the_author_meta( 'ID' ) ) 

Co-Authors Plus filters 'the_author_posts_link'. If ColorMag used `get_the_author_posts_link()` instead, then it would be properly filtered.

In theory, you could filter 'author_link' to fix this (this is the filter that's used in `get_author_posts_url()`. But this might be too general of a filter; it might modify values that you don't want modified. The other option is to override the ColorMag markup, as we discussed above, to replace the calls to `get_author_posts_url()` with a more appropriate function call.

Hi Boone,
Thanks. How would I be able to filter the "author_link" ?
Alternatively, would we able to use an additional widgets file, as we discussed not long ago?: https://redmine.gc.cuny.edu/issues/9175#note-14. I already began working on this file (labeled nlfwidgets.php), and can complete it, test it on my local site, and send it to you to upload if that is what you think would be needed. Please let me know if that sounds like a good idea. Thanks!
Diane

"Filters" are one of the basic concepts in WP theme development. Here's a good resource to get started thinking about it: http://www.wpbeginner.com/glossary/filter/

Reproducing the widget code would also be a fine alternative. Please let me know when you've got a version for me to have a look at.

Hi Boone,
Thanks for working on this! I do not see a zip file attached to the comment, and when I attempt to visit the GitHub URL it shows a 404 error. Would you mind trying to re-send?
Best,
Diane

Boone Gorges wrote:

Hi Diane -

I have implemented the widget override code, as requested. As described in https://redmine.gc.cuny.edu/issues/9175#note-13, I copied the relevant widget code to the child theme, into renamed widget classes, and then replaced Colormag's widget with these. In order to avoid unnecessary code duplication, I chose to extend Colormag's widget classes rather than replacing every single (unmodified) method. The Commons changeset is https://github.com/cuny-academic-commons/cac/commit/8d07afa80296ea71b40233e21705aa752a27e37f.

A zip file is attached. Please download it and have a look, both at the code and also to see that it does what you're expecting on your local installation. My impression from the discussions above is that all you're trying to accomplish is to override the text and link of the author attribution in various places to account for Co-Authors Plus, but this is largely implied from looking at the code that you originally provided. If it looks like there's something missing, please let me know.

Let me know if you've got questions or comments. If things look good, this will be part of the next release later in the month.

Excellent! I tested this on my local site tonight and it works seamlessly. If you could implement it on the live site in the next batch of updates that would be great. I really appreciate all the work you have done for me on this site - you have been extraordinarily helpful! I will be in touch if there are any further technical issues, but I think with your update, the site should be good to go.

Best,
Diane

Great, I look forward to it! What date will that be?

Tuesday March 27. More details can be found at https://dev.commons.gc.cuny.edu/release-schedule-and-procedures/ and https://dev.commons.gc.cuny.edu/hosting-partner-handbook/

Excellent, thank you!