Flexible Web Services Info Tech Support

AceSEF has a very frustrating interface. It appears almost clumsy. I have been trying to straighten out the numerous SEF links it's created and the absolute catastrophe of a sitemap. My problem is the dynamic sitemap likes to add unpublished articles but the xml sitemap follows the assignments in the SEF management pages. Due to the several unpublished pages it placed in the dynamic sitemap, have had to run around trying to get rid of the search engine cache that keeps pointing to pages that weren't cached. I suppose I should start with how I ended up with this module.

I only needed to fix the SEF portion of Joomla. AceSEF didn't fix that or even point out where there might be a problem. I'm not that good with Apache or PHP so I stumble around a bit. I finally found where Apache2.conf was missing information. The site never loaded the .htaccess file and therefore never read the rules for re-writing the mods. Once that was fixed, I already had AceSEF which had a nice metatag engine and sitemap generator. As I've already stated, those both exploded in my face.

Now my problem is the frustrating i have with the concept of published (within the context of AceSEF) and deleted or trashed. Apparently, Unpublished in the SEF tab means that it won't publish in the static sitemap.xml file. I'm sure that's not what they intended, but that appears to be the way it works for me. The 404 page has no explanation that helps at all. Unpublished doesn't seem to mean a thing. When a link shows up in the 404 pages it is registered as unpublished. If you use the button at the top of the 404 page to move it, it only gives you a empty move page. This was frustrating, but now I realize this button really means new 301 page (but why have it on the 404 page). Even checking the item and clicking the 301 button does nothing but give you a blank form. I found that clicking on the actual link gives you a 301 form with the link in the old URL slot. Never would have figured that out from the tutorials or the helps.

I bought the VIP but I haven't called. I really want to make sure I've read all the helps before I waste someone's time. If you use that 301 creation page, you cannot leave the 404 page in there. Even though it's unpublished, it still redirects to a 404 error page and the 301 page never gets loaded. All these left overs seem to cause other problems. I had one page that I would get an error, "too many redirects" even though I couldn't find where it was getting an additional redirect. I have wiped out the SEF database 3 times now. I have made changes to the SEF format because I realized I really don't want duplicates and I have to figure them out. Well that causes another problem because the new SEFs don't match the old SEFs so now I have to deal with even more scattered crap. 

None of this would happen if the program didn't generate stuff I didn't want or if it was documented well enough to figure out how it worked. Even the web site gives no help. The web help is an exact duplicate of the help that comes with the module inside Joomla. They don't even bother with additional explanations. I might add that the online videos are also only partially helpful. The fact that they go through every little option is the only help they add, but it's almost the same as if you went through every little option yourself and read the little pop up links that explain each option which goes something like this: Generate new SEF URLs - this generates new SEF URLs. Well it is a little more wordy. "If set to NO, no new URLs will be generated and only those already in database will be used."  I can't tell you how often I want to turn that off. The pages actually seems to load fine without it, but one must be careful if cache is enabled. I had been looking at the wrong page for hours when I discovered that it was the cached page. I cleared the cache and found the page was a 404 error issue. 

Another buggy problem is 404 errors do not show up all the time. It seems that if it hits the SEF 404 page, you will never see what caused it. Hmmm. I just had a thought that I might turn that off so I can see the real 404 pages which give a little more info and may show up in the 404 locker.

As I look through the many templates that have the word Postgresql on it, I note they have a familiar phrase which just happens to be copied directly from the Joomla announcement page for Joomla 3.0.

MySQL 5.1 +; MSSQL 10.50.1600.1 +; PostgreSQL 8.3.18 +

Don't believe it. Joomla 3.0+ is compatible with a few issues, but for the most part. Meaning you can install the base package. I have not found a single template that is compatible right off the web. They have all required some modification to get them to install. The problem is MySQL syntax. MySQL's current versions are more compatible these days with standard SQL statements, but developers of these templates insist on using the MySQL specific syntax which renders the statements useless in other SQL databases and therefore the templates can't be used.

Here is a recent error message that I got while trying to load T3 Frameworks which has the compatibility phrase above:

Database query failed (error # %s): %s SQL=UPDATE m2eij_extensions SET `enabled`='1' WHERE `type`='plugin' AND `folder`='system' AND `element`='t3'

One support web site that claims to support Joomla 3.x, complained that the client wasn't providing the error message so he couldn't fix it. The problem is simple. No one but MySQL uses accent marks to enclose any value that represents a field name. The accent marks are not required, yet developers continue to use it. The accent marks are only around the field names and would be an easy fix. Just search and replace every accent mark with nothing and both MySQL and Postgresql would work fine. Of course, that's only the tip of the iceberg. Postgresql is case sensitive and problems crop up with field names that have mixed case. Another problem is usernames. Those would be case sensitive also which can cause problems if the web didn't force the case on that field. Obviously that could have impact on other fields and searching blogs for information.

The problem is that developers are not using the features provided by Joomla when creating queries. There are functions which ensure database compatibility, but it's just easier for developers to write out the SQL statements and execute them without going through the function breakdown. They claim they are "extending" MySQL features when they do this, but I think it's just plain laziness.

I like one client's comments on the support page I read.

"There are two ways to fix this. One is to stop advertising that the template is 3.x compatible if it won't load in Postgresql as well as MySQL. And the other is for Joomla to stop supporting Postgresql."

Certainly the template designers are not supporting it.

I just purchased the love factory plugin. When I bought, it was version 4.0.0 for Joomla 3.1. Right away, it was not ready for Postgresql. I made several modifications myself and got it installed. This is the normal double-quote and accent marks issue that I've been running into. While I got it installed in a couple of days, I will say the tech support from the guys at thefactory.ro revamped the entire plugin and made it Postgresql ready in an amazing 4 days.

I didn't agree with all the field mods and defaults they made in the process of converting, but I was very impressed, the system installed cleanly and all the items have been working so far.

Some issues that I wasn't aware of in the process of building my PHP server. I needed to install GD Library which is required  to create thumbnails from uploaded files. In fact, the photos wouldn't finish uploading. I got a bar across the screen showing it completed, but then it just stopped without an error message.

I'm on a Ubuntu server. Installation of the Library was easy: apt-get install php5-gd

I also needed the CURL PHP plug in for Google maps. that was also easy to install: apt-get install php5-curl.

At this point I am working through setting up the templates. I did a search on Google because there is not documentation sent with the module (note: love-factory is a module not a template. It plugs into whatever template you have running and I'm still using the one that initially came with Joomla without sample data). The documentation on the thefactory.ro's web site talks about using Smarty Templates. It states that it must be enabled in the settings General tab, however; there is no such setting in my version of this module. I'm still trying to find it.

This one is a big fail for use with Postgresql. On the initial install, none of the web page would load due to the use of double quotes. I was able to find and fix that. One odd thing. I wasn't able to find the location in the template I downloaded that was causing the problem. I can only assume that they downloaded additional files during the installation of the template that I uploaded. I had to modify the PHP files on the server itself and I could only find the problem but using the trace file after setting debug on. There was only one helper.PHP file in the template and no other zip files. That helper.PHP file didn't have the lines that were causing the problem.

Once the problem was fixed, the web site displayed fine, but there was no data. When it came to installing the sample data, there is just no hope if getting the site up and running. In fact, it was broken beyond the ability to uninstall the template. I had to scrape the entire site and reinstall Joomla from scratch.

Installing the sample data is done from the template manager in Joomla using a java script totally designed to function outside of the Joomla template world. You can install the sample data from a button which, from what I can tell only downloads a xml file. This means there is a library of files installed already which know how to process the xml file. Any attempt to fix the xml file only results in being overwritten when try to install again, since the file is downloaded... fresh with all the broken items in it.

This template suffers from interchanging using double quotes to delimit fields and using single quotes. It also uses the WHERE 1 clause. And the xml file queries all used accent marks to delimit field names which doesn't work in Postgresql.

I would like to add that this is a very sleek and nice template. I wish I could have used it. They claim the template is Joomla 2.5 and 3.1 ready, but i don't think you should be able to claim that if your template is not database independent.

This template can be found on Joomlashine's web site. I used the free template. If the free template doesn't work then the Pro template won't work either.

Well, I didn't mean to get into this, but every Joomla template addon I have checked so far is not ready for Postgresql. I not sure how this will develop but for now, I will make comment on each designer I test. I will also test various templates from each designer and if I find one that works, I'll list it. Otherwise, I will just list the failures.

My biggest issues today is the interchangeability of the designers work. One where clause with open with double quotes and use signal quotes to delimit the fields. This works fine with Postgresql. But in the same file, the next time I see a where clause, the start the where clause with a single quote and delimit the fields with double quotes. This does not work with Postgresql. It seems that it doesn't matter which way they do this and it will work fine with MySQL.

The other issue I just ran across is the use of WHERE 1 and a where clause. This makes not sense at all. One comment I read is that it makes it easier to build conditional where clause. I won't comment on that, but any where clause should always return a true or a false. I could understand doing this in the case mentioned above, but are we trying to save space? Could the clause just say WHERE true? or WHERE 1 = 1.

So far, any addon that has to create new tables has failed and I mean horribly failed. As in, no tables even come close to being built. Where I found this to be an issue is in the installer.xml file where they specify the database to build the tables from. Joomla doesn't care that you don't have the one they want to install. It just pretends that the job was done and the failures starting showing up with exceptions that say such and such a relationship doesn't exist. In the xml file, it specifies that the tables to be built and the language to use is MySQL or Postgresql where you can have both in the same file, but they point to different SQL files to actually build those files. Then you can build tables using specific syntax for that database manager. That is not the case in the normal run. Instead, the designers of Joomla built the query interface to be generic on the one hand and they will build the query (using JFactory and JDatabase), though they say queries can still be submitted via a string as it has worked the past, but I can almost guarantee that any designer who does that will be formatting the query for MySQL alone which is guaranteed to fail.

I will make more specific comments on other templates as I go along. 

I've been working on several projects involving Joomla, all of them with Postgresql as the database backend. The projects include a construction contractor web site, a blog, a dating web site and a model's portfolio web site. None of them are working.

It might not be surprising, but most of the Joomla component and template makers have no interest in addressing the database backend issue. So far, 100% say, use the MySQL backend. No one (and I mean NO ONE) has requested anything to do with the database backend. I've spent several days now working out issues with accent marks and double quotes, not to mention the database types that simply don't exist in Postgresql.

I stayed away from Joomla because of the MySQL backend. I didn't want to use it and I didn't want to learn it. When Joomla 2.5 came out addressing MS SQL and Postgresql, I thought I could finally dive in. I didn't do so until 3.1 thinking at least some providers would be addressing Postgresql by now. Not happening. 

I just completed a Joomla 3.1.1 fresh install and had some issues with installing to Postgresql. First, I was running my Postgres on a old Linux box Fedora 11 which is no longer supported. Joomla requires Postgres 8.3.14 or above and I was running 8.3.x not 14 on that box and couldn't install the Joomla files. So I am updating the server and the database, however; before that goes into production, I am testing so as to resolve problems before it goes live.

So my test environment is completely clean. Ubuntu 12.0.4T 32 bit and Postgresql 9.1 (I couldn't get 9.2 installed on that box, but 9.1 meets the requirements). 

At this point, I have managed to get a working version of Joomla installed on the Ubuntu box. In the production environment, the Postgres database will be on a different server from the web site. I have been trying to add templates and haven't been successful. I initially ignored the warning in the extension manager because until I tried to add a template, I had no problems at all. The error message i was getting was on on the *_associations table stating the field id was not type INT. That isn't a type in Postgresql that I know of. I found the query with debug turned on and cut and paste the query to see what info was actually being presented. Here is the query that was failing: 

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_name='*_associations'  - note: the * is a replacement for the actual value.
AND column_name='id'
AND data_type='INT'

I took out the data_type line. The resulting query is: id, integer. Postgres is very particular about case and length matching. The command to alter the table in 3.0.3.sql statement kept failing also. After reading up on others who had similar problems at this link, I was able to locate the file and removed it. After that, the databases all checked out, but I'm still unable to add the particular template I'm working with. 

The issue was actually the id numbering. After the fresh install of Joomla went in, the id in the template_styles table was left at 8 and the increment control file was also at 8. It should have incremented to 9 and added, but the error message in the Postgresql error log was that the unique id 8 already existed. I could see no reason why it would insist on that number. To fix the problem, I added a dummy record to that table manually and then deleted it. Adding the template from within Joomla worked with the new id being 10.