Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.
Categories
Tags
Archives
Calendar
Categories:   All Categories
Suggested keywords
x

SEF

Subscribe to this list via RSS
Geoffrey Chapman

Newsfeeds display – solution to an enigma

b2ap3 icon joomlaWe have always displayed a few relevant newsfeeds upon our web site, but it has never, to be honest been very high on the visitor list, or upon our own priority list. We long ago noticed that the default display for the ‘Newsfeeds Categories’ in the front end of our site comprised merely of two lines, one for each of the two newsfeed categories we use, which also acted as a link to the underlying newsfeeds in the respective category.  There was no page header, no display of the breadcrumb information, and no details of the category descriptions.  In short  a very barren page.

Originally it was suspected that it might be a template or CSS type problem.  Attempts to change the menu settings, resaving module specifications etc.,  all proved fruitless.  It didn’t matter what the menu settings were, they were silently ignored.  One is tempted to say it was a cache type problem, but bearing in mind that this has been the situation for several months, if not longer  and the various caches’ had been manually cleared several times during that period, it was obvious that something else was amiss.

With the change to a new site template, the situation remained unresolved and it was starting to get a little bit annoying.   So given a hour or so spare we decided to investigate further.  Inspection of the PHP code underlying the display revealed no clues, and despite retrying all our previous steps we were no further forward.

Searching the web for similar reported problems drew a complete blank, apart from a link to a very strange problem we had ourselves encountered with the display of breadcrumbs on a previous occasion.  Looking back we found out previous blog entry. [So keeping a blog can prove useful.]  We thus decided to clear all URL entries from the sh404SEF component for the com_newsfeeds component.  Low and behold on refreshing our web page the correctly formatted page was shown, complete with headers, breadcrumbs, descriptive text etc.

We realise that sh404SEF keeps track of URL links, but why this should impact the page display is currently a bit of a mystery.  It doesn’t itself cache pages, but must somehow also keep track of which modules and what the ‘previous’ settings were for a page ,for which it is keeping a record of the link.  I am sure that I have never read anything of this sort in the component documentation.

What we learnt gain from this is that sh404SEF seems to have some strange characteristics which impact what is displayed upon a screen, far and above just converting non SEF URLs to a SEF format.  So it you are ever seeing a similar type of problem and every thing else seems to failing to resolve it, it might, if your site is using sh404SEF be worth clearing your entries and seeing if it resolves the problem.  Certainly stranger things have happened.

Tags:
components joomla SEF website
Geoffrey Chapman

Handling Googlebot URL detected errors.

GoogleWe tend to use Google Webmaster Tools to monitor our main site and in particular the Crawl Errors that it detects.  Sometimes we are a little confused as to where the errors are coming from since the 'source' URL is sometimes the self same page indicated as in error, and others indicate pages where we fail to find the link referenced as in error.

That said it has proved generally useful and mostly they are trivial to fix.  What it has been difficult to discover, is a good reference guide to the topic of Search Engine Friendly URLs known as SEF. Whilst acknowledging that the subject of SEF can be quite involved, our searches have yet to reveal a good comprehensive article upon the best design and implementation mechanisms. It is even more difficult to discover a good guide to resolving problems. Having found nothing suitable we decided to create this post as a record of our investigations and perhaps act as a guide for others.

Continue reading
Tags:
htaccess joomla SEF Tools
Geoffrey Chapman

Discussions forum migration to Kunena (Part 4) SEF links

kunenaWe anticipated our last post being our last on this topic, but we have enough information for an additional post.

First we discovered that the first topic id had not been correctly set up.  Not quite sure what went wrong here, but the topic title had the wrong name and pointed to a non-existing category, even though the topic text (message) was our submitted text.  We edited the the table entry directly to correct the category and title and this seems to have resolved the problem.

Much more of a concern has been the relentless number of ‘invalid URL addresses’ we have encountered that have required redirection since we moved forums.  These links seem to have a number of variations as follows:

  • index.php/link_name/cat id/thread id
  • index.php/components/discussions/cat id/thread id

In addition sometimes the category id is expressed a numeric values, sometimes as a text string and sometimes both are included.  Likewise the thread id is similarly expressed is a variety of forms although usually the thread id and title text are provided, separated by a hyphen.

Sometimes the menu id is provided (we changed our menu title from ‘Macrotone Forums’ to ‘Forum’), sometimes the language string ‘lang=en’ is also in the link.

Sometimes the link seems to have the index.php missing completely and consists only of a cat id/thread id.

Most do not have any ‘calling’ URL to check. Look with a tool such as Google web tools for a registered website sometimes show calling web links, and often the referring links are ‘unpublished’ or invalid.

This is despite us removing all ‘old’ existing SEF entries on our site.

We had expected a few since it can take a while for ‘robots’ from the likes of Google etc. to get up to date, but some six weeks after we moved, they are still being found on a regular basis, often > 10 a day.

We have created ‘redirect’ links within Joomla but the wide variety is something that we had not expected, and are sure we are not alone in this.  When could one safety remove these ‘temporary’ redirection links, since one would have expected at the most a few weeks.

We ourselves have a ‘modest’ number of forum entries, but for a large site constantly creating redirection links would become a major headache. Yes one could modify the ‘.htaccess’ file to place a 301 redirection pattern, but the number of patterns required seems to be more than an odd one or two, and is not something I have ever seen described in detail.

Definitely something to be aware of for others migrating from one forum to another, not just for the Discussions forum.

Whilst on the subject of SEF, there doesn’t seem to be a definite solution or suggestion as to how one should really deal with items such as ‘old’ articles.  If the ‘article’ is ‘unpublished’ then any existing links immediately become invalid. How long should one wait (or expect) to see these invalid URLs?  Should the articles be ‘archived’ instead and would this be a better approach? Any item whether it be a web article, a forum entry or whatever has a useful life, so what is the best way to handle their expiry?

Perhaps this is the suggestion for a new definite work on the topic.  It definitely seems to be one of the ‘black arts’.

Tags:
Codingfish Discussions Forum joomla Kunena SEF
Geoffrey Chapman

Problems with a SEF component

We are currently trying to track down a strange problem with an installed SEF component.  The problem fortunately only occurs on our Development site but it has some very strange symptoms.

First we created our development site with a backup of our live environment.  Everything in the back end works fine but in the front end some pages display completely blank, with no tags what so ever.   Fine one would say, there must be a PHP error, (although why this should only occur on a restored system rather than the live site is another question), so we turn on ‘Site Error’ reporting to Maximum (or Development) and it makes no difference to the front end displays they still shown blank pages.

Perhaps a cache problem, but no, clearing all the caches, in the system, browser etc., still makes no difference.  Nothing is reported in system or error logs what so ever.

Then a break though, we disable our SEF component and the pages display OK. So if must be something with the SEF component!  We reinstall an older version of the SEF component and it all works perfectly.  Re-install the current version of the SEF component and the blank pages re-occur.  Re-install the ‘older’ version and the pages are fine.

At this point we report the problem to the component author’s support forum.

Now frustration starts to kick in.  The support from the vendor says that there isn’t a problem, since there is no PHP error, and it doesn’t occur on our live site!  Exactly what sort of support is it they are offering? And this is a component for which we pay for support!  I will withhold the name of the vendor for the moment, perhaps they will improve, and it might be a problem at my end, although it is not looking likely.

I am starting to hate SEF with a vengeance, and this is just another straw that is ‘starting to break the camels back’.

At least we have a mechanism to enable us to continue testing our components for a forth coming release, but we really need to resolve this at some time, so it will be revisited when we have some more time.  Watch this space.

Tags:
components joomla SEF PHP
Geoffrey Chapman

Problems getting a front end wget/curl cron working.

joomlaIn completing the testing of our ‘cron’ addition to a Joomla component we experienced a small problem, which is worthy of noting especially as we have not seen any mention of the problem anywhere else on the web.

The problem manifested itself as the apparent ‘inactivity’ when a front end web page was accessed via wget, curl or lynx.  This was very puzzling since accessing via the usual web browser appeared to be working.  After much testing we discovered that wget, curl etc. were indeed accessing the page but the underlying actions that the page was intended to run were not occurring.

To cut a long story short, we discovered that the pages were being served up by the ‘page cache’.  In the normal course of events this is what one wants to occur, however with a ‘cron’ page we want the underlying actions to occur.  It was necessary to disable the caching of the specific accessed page and this completely resolved the problem.

What was interesting was that this specific problem was not mentioned on any sites on the web, despite extensive searches. Either everyone else is aware of the problem, possible but unlikely, or equally unlikely no-one else uses page caching.

As part of our investigations we also tried out a well known ‘free cron’ service.  This didn’t help us resolve our problem, but did make us aware of possible ‘redirections’ that may be caused by the use of ‘SEF’ components on a web site. It was necessary to specify the ‘redirection URL’ rather than the ‘original URL’ to the service. Not a specific problem but one of those things to be aware of. 

Tags:
joomla website sh404sef SEF Cron
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries