tamia

Thanks Steve. I inserted your code as directed but unfortunately, that didn’t make any difference to how the search results were displayed. I refreshed the browser and tested, but still no URL link to posts. But you gave me an idea, and this is what did work:

.search .post .entry-title {
    display: block;
}

.search .page .entry-title {
    display: block;
}

Can’t explain why these worked but they did! Thanks a bunch!

I don’t use tag clouds but in checking the Twenty Twelve Changelog today I noticed this:

Version 2.4
Released: November 14, 2017
– Remove “called called” and “can can” dittography. (#41836)
– Change tag cloud format to a list (ul) for better semantics and accessibility. (#40138)
– Make sure new gallery widgets look good in themes. (#41969)

Note the second item in the log. It seems that list view is now the way this theme displays tag clouds.

Hope this helps.

Thanks for posting this oavs. I’ve been wondering how to manage that task, also. Cheers.

Thanks for your advice, Steve. I pulled off all the parent css I’d copied into the child style.css.

It took a few days of on-off work, but I finally managed to make my Twentytwelve child theme work.

First, I’m not sure if this is that important, but I’d gotten the incorrect Version number for the parent in my child stylesheet, so corrected that.

Second, referring back to the Codex…

If your child theme style.css contains actual CSS code (as it normally does), you will need to enqueue it as well. Setting ‘parent-style’ as a dependency…

…I realized that I had the incorrect lines in my child’s functions.php. So, I replaced my original functions. My ignorance of PHP makes working on the functions.php a rough proposition for me, but after making these changes, I was able to alter the child theme’s style.css to modify how blockquotes and links appear. Now it seems the child is performing as it should. If I understood PHP better I’d have had no trouble to begin with.

Thank you to WordPress folks and forum members who take the time to help neophytes like me.

Thanks James! I’ll be posting static images on my website. I was a little concerned that if sometime in future I change themes, I might then have some headaches maintaining internal image links, thus my thinking that an images folder at a higher level might make sense.

It’s great to have such knowledgeable folks willing to help a newbie like me. Maybe I can return the favor someday to others.

Thanks folks.

• This reply was modified 7 years, 2 months ago by tamia.

Thanks for helping me, Keith. Much appreciated. I’ll be trying my hand at creating a child theme this week, so I’ll find those links useful

Thanks again.

Thanks for getting back to me so quickly, James. Does this mean I can move the uploads folder out of the wp-content file? In other words, can I do this”

https://www.example.com/uploads

I appreciate your patience. I’m “self taught” (ie, I tap the knowledge base of more knowledgeable WP folks) so am a bit shaky on this kind of detail.

• This reply was modified 7 years, 2 months ago by tamia.

Just an update to say that I’ve fixed my website, and to tell how I’d done so in case anyone runs into this problem themselves.

Summary: The syntax error essentially locked me out of my website. I could not log onto the dashboard using another user’s account on another computer. The public site brought up the syntax error.

The fix: With FTP, I logged onto the website successfully. Then I downloaded the backup file from the website (thank goodness for backups!) to my computer, unzipped it, and then uploaded the backup functions.php file to the website. This overwrote the existing functions.php file with one from a backup I’d run yesterday. My site was repaired. I could log on and out of WordPress, and the site is visible again.

Observations:

1. Make backups! I was glad I’d done so.

2. I’d copied the relevant document from the Appearance > Editor > functions.php page, then pasted it into a Text Wrangler document on my computer. Using the theme author’s help guide mentioned in my original post, I commented-out the portion of code that I thought should allow me to use html code in post titles. Then I copied this edited document and pasted it back into the edit window. When hitting the Update button, I got the parse error. I then restored what I thought was the original php document into the edit window and updated, but the parse error remained.

I’ve repeated myself here, I know, but this seems critical. It would seem possible that in using a text editor application (TextWrangler) I managed to unwittingly introduce a character or spacing not found in the original “pure” document created by the theme author. I’ve still not figured out how this happened — soft wrapped text? line breaks? — but there it is. People much better at this than I might have the answer.

The takeaway lesson? Be very cautious about making changes. And use a child theme. I’ve not yet uploaded a child theme (graciously provided by the theme author right in the Tiny Framework theme itself). Hubris let me believe I could do this one seemingly simple change to the main theme’s functions.php file.

Thanks for sitting through this long-winded explanation. I hope this helps someone else.

Thanks very much barnez. Done. I appreciate the support.

YAY! Looks like WordPress.com-Stats is back up and running. Thanks Automattic and WP!

@ipstenu:

When I logged into my self-hosted website before the failure of WordPress.com Stats, all I had to do was click on STATS in the Dashboard in order to bring up the stats page. When WP Stats broke, I tried Jetpack, as suggested. I went through the installation with no trouble, configured stats on Jetpack after logging on to WP.COM, opted out of all the other bits of Jetpack which I don’t want, viewed stats, then logged out of WP.COM and logged out of my website’s dashboard.

Next time I went onto my website, I then clicked Jetpack Stats, and discovered I had to log into WP.COM before seeing the stats. I did that, and then saw that all of the non-stats bits that I had deactivated the previous time had been reactivated. That was a nuisance in addition to the nuisance of having to log into WP.COM to see stats. Moreover, I had two days when no data came in on the Jetpack stats, so I wrote to Automattic to ask if it was necessary to remain logged into WP.COM in order to maintain my preferences and to keep the stats coming in. Here was the reply I got from Automattic | WordPress.com:

The plugin was designed to keep it connected all the time. That’s the way it was built…. Jetpack depends on a connection to WordPress.com. I’m sorry but we don’t have plans to change that.

@ James: I’m glad that WordPress.com Stats plugin is not to be replaced and hope that whatever the problem is that it’s fixed soon. I’m not going to use Jetpack, and yearn for the simplicity of WP.Com Stats.

I agree with alseymour. Communication would be wonderful. If Automatic is dropping WordPress Stats, JUST SAY SO!

The biggest problem I can see with Jetpack is that I have to remain logged in to WordPress.COM in order for it to continue collecting data. I do not want to remain logged in 7/24/365 to any account. This would seem a very bad idea.

With WP-Stats, all I had to do was log into my self-supported site and then click on the stats in the dashboard.

So come on, WordPress. Why no fix for WP-Stats? Why is everyone being funneled to Jetpack? I chose WP.org because it’s so easy to use and is well supported, and I appreciate it a lot. But this failure to offer an official statement about WP-Stats, and the lack of progress on fixing that super plug-in, has me scratching my head.

I’m glad I’m not alone in this. I’m having the same problem.

I resolved my own problem and maybe this can help others…

What had to be done was to update/upgrade the WP Stats plug-in, then enter the API key, and finally to select the “Recover Stats” button (which wasn’t available in the previous version). My mistake was to assume that the previous version of WP Stats would have to be functional before I upgraded.

Hopefully my experience will help others.