not sure but I think you did not get the problem message which is

Parse error: syntax error, unexpected $end in /usr/www/users/sharon13/mydomain/folder/modules/yellow-pages/admin/index.php on line 1730

so of course I did what you suggested but it is not a matter of the cache I believe.

And there was some guy with the same issue.

the problem is still existing and it is either module related or like I mentioned before that there are different versions of cor on
sourcefourge and with the auto installers of hosting companies.

Well I really would like to get the zip file which is with the hosting companies who use Fantastico or other autoinstallers.

because with this version the module works for whatever reason.


I have two working modules with the auto installed 2.4.4


I will prepare another message to the community what I would suggest for this kind of issues later on. But since I am not a long time member of Xoops I have already probably said too much and I hope everyone understands that my critics are neither against Xoops or anyone but I simply would like to point out some weak spots in the site and system.


Thanks for your understanding.

Ok I have done everything what is human possible to erase every error on my side or on the server side.


It is either a module issue.

or it is different version of 2.4.4 on sourceforge


and with my example of fantastico installer with justhost.


I have now 4 installations of xoops 2.4.4 manual install of
2.4.4 with files from sourceforge

(the hosting company I would say professionals unzipped the file
on the server, so definitely no file is missing )


2 installations per autoinstaller where the module works but the
admin/index.php loads quite slow in comparison to other modules.

but last not least it loads


My last try would be if someone provides me with the 2.4.4 which is on justhost.com Fantastico to try this version.


but you should be the experts and tell me if this makes any sense , with this kind of error message it should be rather
a module issue because all other modules I can open the
admin/index.php

So something is wrong.

Again the message - and again the file is faultless like one of my predecessor already checked that.


Parse error: syntax error, unexpected $end in

/business/modules/yellow-pages/admin/index.php on line 1730


but there is no syntax error



a real headache

If ypu want to know the differences, do a file and database backup of the 4 sites and then do a file compare with it.

I have v 3.01 RC1 and there are only 1725 lines in admin/index.php. So, it may be that the file was edited at some time on Mac OS9. The line break codes are different and can cause problems on some servers if the codes are preserved when the archive is un-packed.

You can try re-uploading the file via FTP and force 'text/ascii' mode (not binary). This automatically converts line breaks to the correct format of the receiving OS.

Thanks. my file has also only 1725 lines, but the server announces the error.

Anyway for everyone who might experience the same problem I have found the error.

Unfortunately I was so stupid or naive to believe a previous post that the file is ok and he sees no error. So this naivity cost me two days and arguing with my web host ( as I said on another host there is no problem with the display of the admin/index.php.

Ok that is passed now the error is around or at line 917 , I have copied 915 - 917

echo "<table>";
echo "<tr><td colspan='2' align='left'><h4>"._MD_WEBLINKSCONF."</h4></td></tr>";
// echo "<table><tr><td valign=top width=45%>";

so delete " // " the like below and your headache is gone and then it works ( i am not a coder so this could have other impications but I dont dingdo.

echo "<table>";
echo "<tr><td colspan='2' align='left'><h4>"._MD_WEBLINKSCONF."</h4></td></tr>";
echo "<table><tr><td valign=top width=45%>";


and trust me your file has at a 99% probability the same command line.

It seems only that my very secure and sensitive server does not like that, where most let me say insensitive or ???? servers just swallow it.

( As I said I had the trouble only one server and the other not )

I thought it is my installation, but after I did tell the hosting company to unzip the files and I had still the problem I was really getting crazy and dubious about the error.

Will post some suggestion on another forum how to generally avoid having issues with several servers.

It could be the %> combination, which can be interpreted as a script terminator.
For being good the argument should be in ", like

It wonders me if you can introduce just like that a starting table tag, without a closing one. Use the w3c validaator to see if these tags match or are superfluous.

you misunderstood

the //

was the problem, the other argument change yes you might be right

but the line you have corrected has not been read due to

//

am I correct

So I removed the // and then it worked.


And again on another server this // did not create a problem


Plus despite the subject blank page we are not talking about the blank page.

Will post my resolution on another post where it is in fact more appropriate and I hope the guy who opened the problem with line 17.. will be able to read it and try if it will fix the problem with him as well.

Your debug report shows an error at line 1730, which is 5 lines more than the file should have. I think that by editing and saving the file on the host, you have corrected the line break error that previously existed, because the host text editor (Plesk, CPanel etc.) will do this automatically in a similar way to uploading the file in ascii mode.

You can leave the line in if you are certain that everything works, but as ghia points out, the page is invalid.

The line should really remain commented-out. It is an error that the developer has fixed.

My guess is that if you comment it out again (or delete it) the page will now load correctly.