Macrotone Blogs

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

sh404sef

Subscribe to this list via RSS
Geoffrey Chapman

Converting Joomla Discussions Forum to Kunena revisited

kunenaWe previously wrote about converting a Discussions Forum to Kunena and it was now time to revisit the topic as we prepared to perform the task again and this time make the final step to make it live on our site. Since then the Kunena version has moved on to 3.0.3 so we were expecting a few changes.

We must also take the opportunity to state that our Discussions forum did not make use of images/attachments, hence it was not necessary to consider these in the migration. There was also a know opportunity with the Discussions component in that although new user were synchronised between Joomla and the component, when users were removed from teh system for any reason, their details remained within the component. It was thus necessary to run an additional SQL script to clean out these old entries.

The installation of Kunena 2.0.4 and the Importer worked fine, as did the import of the Discussions items (posts and categories). Unfortunately the ‘live update’ to version Kunena 3.0.3 gave us a blank screen, so we resorted to the standard update mechanism which worked fine. (Perhaps the live update implementation needs some work?)

Then we started running our SQL scripts (See previous post for details, which are didn’t require any changes):

  1. Create the  view.
  2. Updated the topics table. We observed the message ‘1364: Field 'params' doesn't have a default value’.
  3. Update categories number of topics count. We saw a number of messages ‘1048: Column 'numTopics' cannot be null’.
  4. Update the last_topic_id, last_post_id and last_post_time fields.  Again we saw a number of ‘1048:Column xxxxx cannot be null’ messages. We were not too worried about these messages as they reflect the empty categories in our original Discussions source tables.
  5. We then updated the category hits.
  6. We then recalculated the statistics within the Kunena Forum Tools.
  7. As mentioned above, we run an additional script to remove 'old' users from our Kunena users table.

delete from #__kunena_users
where userid NOT IN (select id from #__users);

Note: There are several fields such as the number of views of a topic etc. which are not populated because this information is not retained by our source forum and we could not begin to guess what might be appropriate, so better to leave them empty. They will populate themselves over time and we are not too interested in how many people had read them.

Now we can either start configuring the component on our development site, or we can export our tables ready for loading into our live site and after loading configure the forum there. We decided upon the later option.

Inspecting the database tables if was apparent that a number of the tables were empty (since this was effectively a new forum installation) so only a small number needed to be exported and imported on our live site.  The list of tables was as follows:

#__kunena_aliases, #__kunena_categories, #_kunena_configuration, #__kunena_messages, #__kunena_messages_text, #__kunena_topics, #__kunena_user_topics, #__kunena_users, #_kunena_version

On our target (live) site we only need to install the latest Kunena version (3.0.3) and import the data we exported above.

We now disable the use of sh404SEF for the Kunena forum. Basically we have found it more trouble than it is worth, and the Forum entries are fine without the need to use the SEF translations in sh404SEF.

We now enable the Forum menu item, which is the menu link to the Kunena menu item, and after clearing out system cache, we are ready to see how it is looking.

Looking at the front end of the site we can enter our forum and see our posts etc., so all is basically sound.

The next step is to install an anti spam component for the Forum. We have chosen R-Antispam v1.3.0 by Ratmil, which uses a Bayesian algorithm to determine whether the message is spam or not. Being Bayesian it learns over time and becomes more accurate the longer it is used.

Our configuration included adding spam check API keys, changing the default Kunena menu tab, etc.  We also had to change our category headers slightly since Kunena didn’t like html in the category description.

Once done we made the new ‘forum’ available to users and disabled the ‘old’ forum.  Note the ‘disabled’ since we will monitor it over a few days/weeks before we finally ditch it altogether.

Addendum: Have to also change the SEF entries that refer to the 'old' forum entries to redirect to the new forun equivalent. Also search out 'smart search/finder' entries as well.  Note that Kunena does not currently install a 'smart search' plugin even though it is present in the installation file. See Kunena web site forum for the rationale for this.

Tags:
Kunena Codingfish Discussions developers sh404sef Forum joomla migration
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
Geoffrey Chapman

sh404SEF housekeeping and€“ shURLS

9539.png We turn our attention today to the question of shURLs. To quote Anythingdigital “shURLs — formerly called pageID — are tiny URLs automatically created by sh404SEF®. Their short length make them ideal for use in social networking sites or on print media such as business cards or promotional items.”

They seem to come preconfigured to be generated (at least we have no recollection of turning their generation on) by sh404SEF for certain Joomla components and we have observed the large number of ‘automatically’ created short URLS on our modest site.  We ourselves do not tend to use them, but what is interesting is the contents of these ‘short URLs’.  The vast majority were for subjects that have no relevance for our site what so ever and typically for subjects that would fall under the category of ‘SPAM’. They (most of the invalid/unrequired/unrelated ones) seem to be trying to ‘redirect’ or send email to external locations.

Continue reading
Tags:
sh404sef joomla links browser
Geoffrey Chapman

Website Anti-Spam


A recent comment requested some additional anti-spam option in our Issue Tracker component. That triggered much though on a topic that obviously impact all website and their components, be it blogs, commenting systems etc.

There are a number of different parts to preventing spam on a website and this is to expand upon our own particular take on the subject.

Spam is one of the many problem that face web sites today. It is basically the proverbial ‘pain in the neck’ and if not handled correctly can be very time consuming. How often have you viewed web sites where there are totally unrelated comments /registrations/ forums posts which has to make one think about the site’s reputation and credibility.

Our site is not immune to this problem and the source is not restricted to any specific country although there does seem to be a preponderance from locations such as Turkey, China, Russian Federation and more recently Ukraine and Brazil.

Continue reading
Tags:
website Tools SPAM sh404sef security joomla components Akeeba
Geoffrey Chapman

sh404SEF graphs, Akeeba Admin Pro and .htaccess

Just tracked down a configuration problem with the .htaccess file generated by Akeeba Admin Tools Pro which was causing the sh404SEF Analytics display to fail to display the generated site view graphics.

The problem was that the .htaccess rule was preventing the sh404SEF component from accessing the graphical data that it has created.  I could see that the graphical png files were being created but they were not being displayed.

Turning off the .htaccess effect by renaming the file, enabled the graphs to be displayed so it was obviously .htaccess that was at fault.

So then it was a case of finding the creation rule in the Akeeba Admin Tools Pro htaccess creator.

The solution was to add the directory to the list of exceptions:

Under 'Server Protection -> Exceptions -> '  add the path to the sh404sef_analytics directory to the list.

This then generates an exception which means that it is not picked up by the rule identified above.

Tags:
Akeeba Analytics joomla sh404sef
Geoffrey Chapman

sh404sef plugin for Codingfish Discussions v1.5

We are pleased to release v1.0.0 of an installable sh404sef plug-in for the popular Codingfish Discussions v1.5 Joomla component.

Developed internally for our own use we have decided to make it available to the wider Joomla community.

Tags:
joomla installable plugin sh404sef Codingfish Discussions
Geoffrey Chapman

Problems writing a sh404sef installable plugin - resolved

I have been having problems getting a sh404sef installable plug-in working on Joomla 2.5.  Looking around the web, it seems that there do not appear to be any at all.  Of the sh404sef plug-ins available they nearly all require that the code is placed in a sef_ext directory under the component, OR placed in the sef_ext directory under the sh404sef component on the site (along with the supplied components).   This is not quite the same as having a separate installable plugin component.

 

The Anything Digital website has an article explaining how to write one, but no matter what I tried it would not work.  They helpfully provide a 'Developer' support forum, so I raised a question.  Not very helpfully they closed it with an instruction to raise the question in another forum.  A complete waste of time.  Reading around on the web, it seems I am not the only person to experience this type of response.

Continue reading
Tags:
sh404sef installable plugin
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries