SCDIT Blog

We have used this plugin in the past and had great success with it; however, this past couple of times we have struggled. We got access to a client’s Facebook Page as an “Admin“, so we should be set. We logged into Facebook under our account, went to the clients’s page, and verified we could manage the page. In WordPress we started our “feed“. We clicked on the “Login and Get my Access Token“.

We get the login for our account. We hit “Continue as Esceedie” our Facebook account.

The screen would appear to be working and would return to the “Facebook Access Token” page as before. The plugin instructions said below this “Facebook Access Token” there will be a list of the pages/accounts we have access to and to pick one. We had no accounts showing.

If we left the plugin settings page and came back into the plugin’s feed section, we would see the “Access Token” wasn’t working.

So confused we jumped over to Developers.Facebook.com and started creating a new App to try to get an “Access Token” the only way we knew how to create one. Once we had an access token we used the following URL to verify the Access Token, which did not verify.

https://developers.facebook.com/tools/debug/accesstoken

We used this video to create our “Access Token”.

https://www.youtube.com/watch?v=RMLcmDdOSxw

This was good because it got it the Page ID, and User Name. We used these two pieces in the “Settings” tab, and then generated the access token. In the App we went to Tools >> Graph API Explorer. We selected the “Meta App” we are working on and added the following “User Page“.

Then generated an Access Token. We copied that Access Token and went to Tools >> Access Token Debugger. Pasted the access token in the debugger. Then Extended the token expiration date.

It took a couple of tries and we ended up getting a green bar to “Create Facebook Feed“.

We clicked on the green bar, and now got the following screen.

Now we pasted the feed shortcode into the page; however, nothing showed on the front end.

We went back to “Feed” settings to generate the access code again, and somehow this caused it to work better. We were notified there was an issue and to remove “slickremix” from the app. Once we did everything was working. Still not exactly sure how to we got it to work.

Let us know if this helped you….

We had a customer with an old Joomla 2.5 site that we got upgraded to Joomla 3; however, we wanted to go to Joomla 4 and couldn’t find the “Joomla Update” menu item under the Components menu. We were able to find it here.

• Go to Extensions -> Manage -> Update
• Hit the Options button in the upper right
• On the left side menu you find “Joomla! Update“, and here you can set the “Update Channel“

Let us know if this helped you…

We suddenly started getting the Joomla4 error page while building a new site in XXAMP. Our first search on the web lead us to fixing the “data” directory in the “C:\xampp\mysql\data”. We used the following article to help get us started. They offer 3 different methods. We didn’t have “Administrator” privileges on the machine, so we started with method 2 and coping the data. At first this got the MYSQL working again.

https://kinsta.com/knowledgebase/xampp-mysql-shutdown-unexpectedly/

We couldn’t get into the website via the Administrator so we need to change the configuration file manually to get us some error messages to debug the site. We used this article to change the permissions on the “configuration.php” file to not be “read-only”.

https://docs.joomla.org/Special:MyLanguage/J4.x:FatalError

This lead to a new error message

https://stackoverflow.com/questions/38759870/xampp-mysql-table-doesnt-exist-in-engine-1932

None of the methods worked for us. We needed to reinstall XAMPP.

Well this happened again where MySQL won’t start. The error was different. Here is the solution we needed.

https://stackoverflow.com/questions/18022809/how-can-i-solve-error-mysql-shutdown-unexpectedly

We discovered an issue on the customer’s website when someone submitted the contact us form. We would get a bounce back saying the auto responder email address was sent not from the website’s domain. Since the first email from the form went to the customer we knew it does work, but just won’t send the second email.

We contacted the developer and said it was SPF, DMARC or something in that realm that was causing the issue. We didn’t want to mess with the customer’s DNS setting, but something needed to be done. In the customer’s SPF record was one “include” already so we looked up how to add the second. It was very straight forward.

“v=spf1 ip4:192.168.0.1 include:mail.first.net include:secureserver.net ~all”

The IP is in the example as a reference.

Let us know if this helped you….

With a older website we needed to fix some Fontawesome issues where the icons stopped displaying correctly. We needed to match their old Fontawesome version 4. The template was set to use Fontawesome 4. All of this needed to be set in the CSS. Here is what we needed in our CSS file.

font-family: FontAwesome;
content: “\f061”;
font-weight: 900;

We have to use “Font-weight: 900;” or nothing would show.

Let us know if this helped you…

Okay, maybe not a full blown tutorial just some lessons we have learned. We recently got asked evaluate a website. The site seemed very plain Jane; however, when running Google’s page speed insights we were blown away by the performance. It scored above 90% on everything. We tested a new version of our website and was crushed by the disappointing score. It was time to get to work and learn how to lower the load times, increase the accessibility and SEO scores.

Here are the first test results for mobile and desktop.

The performance scores were terrible. The SEO was so disappointing.

Keep your <h> tags in order

Digging in deep with the browser developer tools. We realized that a simple module we had at the top of the page as an attraction had the text was in wrapped in a “<h3>” tag. This seemed so simple but Google wants your page <h> tags to be in order starting with “<h1>” and working way through the higher / smaller <h2 – 6> tags. Simply moving this module below our “<h1>” tag greatly raised our SEO score. Oh yeah!

Make it link

The other small issue was the navigation bullets in front page slide show didn’t have a destination. The module’s code knew what to do, but the link wasn’t visible to the browser. Simply not having the destination url in the “<a href=””>” tag. We didn’t have a way to control this so we choose not to show the dot-navigation. We switched it to showing arrow on the hover for the user to jump ahead in the slideshow. Time to run another test in Google’s Page Speed Insights.

The results are in

These two small changes super charged our results. Here are the results we got.

We were so please with the results. We still have some work cut out for us, but is good to know we are not so far off. We dug in deeper. We really wanted “Accessibility” and “SEO” to reach 100. “Best Practices” we could work on, but is “Performance” based on the CMS platform? Is that why “Performance” isn’t reaching 100?

Going Deep

We followed the details in each section of the Page Speed Insights and eliminated a few small problems. One of the issues we had was “contrast“. It was pointing to a red button we had on the screen that had white text in it. We thought the contrast was strong, but we used this following link to check the contrast ratio between the background and the text. We needed to change our background color just a little.

https://dequeuniversity.com/rules/axe/4.9/color-contrast

We took some the images into Photoshop and got the resolution down. We also cropped the images to fit the space they occupy better. We lost a little quality but took it down to a quarter of their size. Not fantastic, but lets see how it could help.

The next run we are finally hitting the numbers were are happy with. We had to eliminate just a couple of small features, but we are not really sacrificing user experience. Take a look at the results.

Let us know if this helped you…