Support community for TTG plugins and products.
NOTICE
The Turning Gate's Community has moved to a new home, at https://discourse.theturninggate.net.
This forum is now closed, and exists here as a read-only archive.
You are not logged in.
Hello community,
I just updated Backlight & Pages, followed the instructions in the readme including the database updates and clearing of the template cache.
I now miss the fontawesome icons on my pages, in the menues and also in Backlight admin.
What could have gone wrong?
A fine weekend to all of You
Michael
edit: I compared the .htaccess file in the update line by line with the one on the server. All the webfont related lines are present. I even renamed my original .htaccess and uploaded the version from the update for a try.
Hello all,
I have registered my site with google's search console and in the section about structured data I am presented a number of errors in relation with the hentry format. The entry types "author" and "entry-title" are marked as missing.
I already learned that this does not effect the search ranking.
Is there a potential benefit in adding the types e.g. in a child theme?
For example to have multiple URLs that are related by a common criteria in bog taxonomy listed under one search hit?
In google's testing-tool at https://search.google.com/structured-data/testing-tool these are not even marked as warnings.
Yours
Michael
The child theme approach gives you a central place to add other features like sharing links for social media, display of author name and creation date. This method will give you a fair chance not to interfere with future updates.
You have to create the child theme and put a subdirectory "template-parts" into the child theme directory. There you put a copy of the original Backlight Theme's file "./template-parts/content.php" that you can edit to fit your needs.
The link is also broken when You access the gallery directly with javascript disabled.
6+7 might be of interest in case you have cross referencing links from one post to another. Also if you have taxonomy and archive links to existing posts.
You might also search for old "http:" occurrences with PHPmyAdmin if it is installed on your hosting platform.
1. Log into backlight admin via a https-URL.
2. open the templateon which your wp-theme-template is based on in the designer, apply some change ans save.
(3. revert that change and save again)
4. export your wp-theme
5. clear template cache and browser cache
additionally
6. get the wp plugin "Better Search Replace" and use it to search the wp_posts and wp_options tables of your wp installation for the string "http:" (the prefix wp_ may vary)
7. replace them by "https:"
8. live long and prosper
The code Ben posted is for Backlight.
If You have set up the site with https form the beginning, everything will be fine.
If You have installed the certificate after installation of backlight, it would serve as good measure to paste the code to enforce use of https over http just for the case You missed changing some internal link to the https form. Also if a visitor types http that will redirect the request and prevent the visitors browser from complaining about Your site being less secure because of "mixed content" which means both encrypted and unencrypted.
It must be somewhere between RewriteEnging On and </IfModule>
the whole aould look like
<IfModule mod_rewrite.c>
RewriteEngine On
###################################
# Redirect all traffic to HTTPS
###################################
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
############################################################################
# Edit this section for servers using FastCGI
# For FastCGI (or seeing the error message 'No input file specified.':
# add # to the start of the next line
RewriteBase /
RewriteCond $0#%{REQUEST_URI} ([^#]*)#(.*)\1$
# For FastCGI (or seeing the error message 'No input file specified.':
# add # to the start of the next line and remove # from the line after)
RewriteRule ^.*$ - [E=BASE:%2]
#RewriteRule ^(.*)$ - [E=BASE:]
############################################################################
###################################
# Adjustments for Backlight
###################################
RewriteRule ^(.*)$ - [E=QS:mod_rewrite=on]
RewriteRule ^([^\/.]*)-single.php$ %{ENV:BASE}single.php?%{ENV:QS}&id=$1 [QSA,L]
RewriteRule ^([^\/.]*).css$ %{ENV:BASE}index.php?%{ENV:QS}&extension=css&name=$1 [QSA,L]
RewriteRule ^([^\/.]*).js$ %{ENV:BASE}index.php?%{ENV:QS}&extension=js&name=$1 [QSA,L]
RewriteRule ^([^\/.]*).gif$ %{ENV:BASE}index.php?%{ENV:QS}&extension=gif&name=$1 [QSA,L]
RewriteRule ^([^\/.]*).png$ %{ENV:BASE}index.php?%{ENV:QS}&extension=png&name=$1 [QSA,L]
RewriteRule ^([^\/.]*).jpg$ %{ENV:BASE}index.php?%{ENV:QS}&extension=jpg&name=$1 [QSA,L]
#RewriteCond %{QUERY_STRING} !mod_rewrite=on
#RewriteRule ^index.php$ %{ENV:BASE}index.php?%{ENV:QS} [QSA,L]
RewriteCond %{QUERY_STRING} !mod_rewrite=on
RewriteRule ^mobile.php$ %{ENV:BASE}mobile.php?%{ENV:QS} [QSA,L]
RewriteCond %{QUERY_STRING} !mod_rewrite=on
RewriteRule ^(.*)download.php %{ENV:BASE}download.php?%{ENV:QS} [QSA,L]
RewriteRule ^$ %{ENV:BASE}index.php?%{ENV:QS} [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ %{ENV:BASE}index.php?%{ENV:QS}&page=$1 [QSA,L]
</IfModule>This will be okay to enforce https connections to be used, but the pages created with the backlight designer require some additional rules to work. You can consult the .htaccess file in the top directory of the backlight distribution for comparison.
As You also use the wordpress theme, you might use a contact form plugin in wordpress instead an have that protected by a captcha. I have "Contact Form 7" from Takayuki Miyoshi who also offers a "Really Simple Captcha" alongside. I believe that was even included with the CE4 package.
http://community.theturninggate.net/vie … hp?id=7335
If You have the choice: A new setup is easier than switching a running site from http to https. Especially if a Wordpress blog is involved.
Thank you.
Code in first post has been corrected.
Edit:
Ah got it. I hope it's better now.
Can You please check it once again.
I don't even have a FB account myself, so I did not see the mistake first.
Thank You.
Michael
In another thread I asked if it were possible to display the author and creation date in a blog post.
Rod and Matthew pointed me to creating a Wordpress child theme.
Thanks again for the help.
I now enhanced my child theme with social media sharing links that help my visitors share a link to the post in Facebook an Twitter.
This is all that I had to put into my child themes content.php (the file content.php is a modified copy of the original in the parent theme and the taxonomies-section is retyped only to identify the place where I inserted the new code):
<?php
...
// Taxonomies
echo '<p class="taxonomies">';
the_category(' ');
the_tags(' ',' ',' ');
echo '</p>';
// Social Media sharing links
$connectURL = 'https://api-ssl.bit.ly/v3/shorten?login=my_bitly_username&apiKey=my_bitly_ApiKey&longUrl='.urlencode(get_permalink()).'&format=txt';
$bitly = file_get_contents($connectURL);
?>
<p>
Share with friends:
<a target= "_blank" href="https://www.facebook.com/sharer/sharer.php?u=<?php the_permalink(); ?>" title="Facebook"><i class="fa fa-fw fa-facebook"></i><span>Share</span></a>
<a target= "_blank" href="https://twitter.com/intent/tweet?text=Found at @kannznichkaufen: <?php echo $bitly; ?>" title="Twittern!"><i class="fa fa-fw fa-twitter"></i><span>Tweet!</span></a>
</p>
...Of course the Twitter and Bit.ly usernames and key must be edited.
Feedback and ideas on improvement are welcome.
I post this in the support section rather than in Tips&Tricks because there might be negative implications I did not see yet.
Michael
Yes, I realized this from what Matt wrote in another context and I took care to have the single image pages included in my xml-sitemap.
But I also will see to get these populates with more text than there used to be. I will be able to evaluate the effort in two or three months.
Share links on the single image pages will not be hard to have, but I prefer if the majority of the visitors land on the blog pages and therefore would like to offer the share links there.
That one in particular loads elements from their own servers to track my visitors. I don't want to loose the privacy concerned portion of my users for the benefit of those who like sharing.
The type of links created by CE4 were just links and thus the fairest way to offer sharing.
My hair has been gray for years anyway. :-)
edit:
I believe I did it.
After having read and thought about SEO in the last days, I decided to change my routine and start making image titles and captions more verbose. On the single image pages there will be more text that will offer more individual information for search engines to evaluate.
I do not want to bloat my gallery pages with to much text under the thumbnails, but could it help search engines if the metadata were rendered invisibly to the human visitor? Just for the case I configured my album template to put the verbous caption into the alt-tags. This should be done anyway to improve accesibility for visitors with screenreaders. But in the past I was to lazy to create individual titles and captions. With ~100 photos per gallery that is a serious amount of additional work and I'm not certain if I will stick to my resolutions.
It is the sharing links in blog posts I'm missing.
I don't even have a facebook profile myself. But most of my visitors do. As I do sports photos for a regional team, the majority of my visitors are a rather homogenous crowd of mostly but not exclusively local people who like to inform each other via facebook.
After every match I upload a publisher based gallery and write a blog posts with some words on the game and link to the gallery from there. But the blog is the hub of my site.
When my site was CE4 based I had around 30% more visits with facebook as a referrer than today.
As soon as I find the time I will have a look at my child theme (with the author name/published date) wordpress has all kinds of constants If there is one for the author name and previous post, there will as well be one for the actual post as well. Should be possible to use one of those.
That would be excellent!
Could that also be adressed by a child theme?
Or by a PHPlugin-Hook in the WP-post?
I read Matt's thoughts about social media icons and understood that the decision, which platforms to include and which not may develop into further discussions.
I believe, Wordpress has constants for the URL of each posts that might be used to build sharing links.
It might be an open approach that can be adapted by those who feel the need to integrate future platforms.
There might also exist a Wordpress plugin that can be recommended for creation of sharing links. But the ones I tried out so far all route some traffic to external servers to fetch a button from facebook or elswhere and thus track my visitors.
Anyway, I also would like to have sharing links on my blog posts as I had with CE4.
At the moment your css-file is still loaded via http.
<link rel="stylesheet" type="text/css" media="all" href="http://www.kurth-dueren.com/backlight/publisher/resource.php?template=6&extension=css&name=style">Have You been logged into backlight via a secured connection already?
Whatever You try or do, don't forget to clear both the Backlight template cache and your browser cache after every change.
You will certainly have to re upload the image files e.g. your masthead image and images used on Backlight pages.
The same might apply for your custom.css
Until you will have sorted it all out, you will have to load each page and also your blog pages, view the source code of the page and do searches for the string "http:"
When you have identified an item that still loads via http:, you can inspect it in Firefox by picking "Element untersuchen" from the contex menu (or "untersuchen" in Chrome)
There may be links stored in wordpress tables that still contain "http://".
I did a full backup of my wordpress database before. Then I did a lot of searching in my database using PHPMyAdmin from my hoster's admin area.
I can also recommend a plugin like "Better Search Replace" for your wordpress blog for that purpose.
@Rod:
May I ask how you implemented the social media share buttons under each post in your blog?
Did you use phplugins or are they managed by a wordpress plugin?
I have tried some wp plugins already, but many of them bring lots of ballast. And what I don't like about some is that some of them embed icons and or other elements from external adresses where my visitors get tracked even if they don't click the buttons at all.
In my eyes the way you have solved it appears the fairest possible solution towards visitors.
Yes. I understand Your Point. In the meantime I found several other sources where the concept of data - * attributes is explained and those are clearly on Your side. Ignoring those tags would definitely be an improvement to sitemap software. I will discuss that with the author.
Again a big Thank you for Your patience and explanation.
Michael
The author of the sitemap crawling scripts had a look at it. I bought the locally installed scripts from https://www.xml-sitemaps.com.
He confirmed what You said: the crawler does not see the lightbox but finds the photo's URLs in the album page. It also follows the link to the single-image/permalink pages, but only to add the page to the pages sitemap. For the separate image sitmap it takes the first occurence and that is on the album page.
The first occurrence of each photo's URL in the grid is not within an <img>, but in a data-href="" attribute.
Since the crawler keeps only the first occurrence and ignores all the come later, it puts the photo's URL into the image sitemap without any further information.
I hope You won't mind; I had a look into modules\standard-album\fragments\classic.php. (and masonry) The data is all at hand and stored in variables. I gave it a try and enhanced the "pswp_go" class with an alt and a title. In the browser it looks OK. Right now the crawler is running so that I can see, if it makes use of them.
If it works and won't raise problems in other places, would You consider making it persistant?
Thanks for Your patience.
Michael
Hello,
there are some things I do not understand right yet.
Background is that I'm still busy getting my xml-sitemap configured.
I have most of my photos in albums that use photoswipe for presentation.
The album grid contains links to the large presentations and builds <img>-tags with title and alt attributes.
I can configure Backlight what to put into the title="" attribute in the Album Setings under Image Setings --> Photos Title.
The title="" is used by the browser to build the tooltip for the image whe the mouse hovers over the thumbnail.
I can configure the caption that Photoswipe will display under the large image in the lightbox under Image Settings --> Photos Caption.
So far so good.
When I open the large image in the Photoswipe lightbox, and examine the sourcecode, I see an
<img class="pswp__img" src="..." style="display: block; width: 1349px; height: 900px;">
No alt, no title.
As far as I see, that is exactly the <img> my sitemap crawler looks for alt="" and title="".
When I switch over from Presentation Type = Photoswipe to Presentation Type = Single-Image Pages, the alt-attribute contains what I configured at Image Setings --> Photos Title what I find perfectly right.
Is there a way to have Photoswipe use the metadata in it's <img>?
Hmm.
Themeing the admin pages seems to be something completely different.
According to https://codex.wordpress.org/Creating_Admin_Themes it should by done via a plugin (that makes use of "wp_enque_style()" nevertheless ...)
I looked around a little:
Currently, the file "style_admin.css" is enqueued by the Backlight parent theme via the file "inc/theme_posts.php"
There is a passage
function backlight_post_meta_setup() {
wp_enqueue_style( 'style_admin', get_stylesheet_directory_uri() . '/style_admin.css' );
add_action( 'add_meta_boxes', 'post_meta_post_options' );I don't really understand why it is searched in the child theme directory then. Shouldn't "get_stylesheet_directory_uri()" from the scope of the parent theme insert the path to the parent theme?
Seems not ...
Or should perhaps "inc/theme_posts.php" use "if ( is_child_theme() )" to test if "get_template_directory_uri()" should be used instead?
I believe, this could perhaps better be changed in the parent theme to make it child-proof.
If I copy "style_admin.css" to the child theme's directory everything is fine of course.
Hi Matthew,
thank You for the hint.
I will have to do that codex research part. Confidently trying it out did not eliminate that 404 error ;-)