donpedro

Initial setup finished with success for TIKIWIKI on TCH (based on FANTASTICO). GOOD - I will try to find the time to add this good news on the TIKIWIKI-site of recommended hosters. REMARK_1: TIKIWIKI did not work perfectly for the server configuration of serveral other hosters (in all cases PHP version 5.xx of late 2007). (problems with new-unser registration - the main program everywhere working fine). REMARK_2: Apparenty, the execution of a shell script setup.sh is NOT required. (This is rectification of my preceeding mail about TIKIWIKI.) REMARK_3: TIKIWIKI combines extreme power. I test-installed everything but will remove soon for the current case of shared hosting : Chat, Video uploads + other functinaliities tending to spikes or requiring significant server resources or server CPU occupation. REMARK_4 To make it run properly : Login as "admin". In the menu column go to 'Admin" / "groups". Each group has a Button ,,permissions". You hae to set ON in this long list permitted functions bfore inviiting users to your site.

First: TIKIWIKI is now one of the best choices. - Here the "but be aware of": The TIKIWIKI manuals, doc service and so on say: - If you update TIKIWIKI over FANTASTICO, some part of content may be (or will be) lost. - So this has to be checked before doing updates. Back-ups of content may be helpful in theory, in practice diffidult to restore prior state of all the reciprocal pointers, DB iids etc. Possibly, FANTASTICO settled thsi aspect meantime. So check it before making decisions. A different problem is : On TCH the very newest TIKIWIKI version 1.9.8.3 will be installed by FANTASTICO - very good. - This had some basic config problems for PHP, or so. - TCH apparently just settled some such basic PHP configuration problems - at least, me new install of approx. 17 Dec. did not accept user registrations, but started to accept them since Dez. 19. (the only stated fault of 1.9.8.3: user registration impossible when server config's do not fit.) A different current aspect is that TIKIWIKI apparently requires for extended features to execute a shell script /tiki/setup.sh . As far as I remember, we (mostly working in shared hosting) do not have SSH access on TCH (in fact a bit risky for shared hosting). - There are work-arounds for it, but do not count on them if you are not experienced for this. The additional aspect is up to which level the individual site (shared hosting) can opt for individual configuration of Apache, without affecting global configuration for all accounts on the same server. As far as I could see in /tiki/setup.sh , Tikiwiki requirement there is still on the "free of problem" side, concerning this. A further aspect to observe: Current Tikiwiki as by FANTASTICO only installs a very basic level (now, for TIKIWIKI v.1.9.8.3 from October 2007). Far more then CMS TYPO3, but practally all functions switched OFF. - Even user registration and WIKIs still not yet activated. - It is not too difficult to switch all the featutes to ON. But this apparently requires just those complications mentioned above. - While when installing on your own, you could opt for an extended initial configuration, with many functions already switched to ON, So that is my current state of testing. - Some of the aspects here above have been brought into discussion on the TIKIWIKI forums. May be, I will soon have more clarity about it. May be that a new TIKIWIKI "stable version" willl soon provide better solutions. (The currnt TCH Tikiwiki is the newest "stable" version, very recent, TCH i top service. :-) ) The underlying more general problem is that PHP had now an evolution without thinking enough about backwards compatibility and consequently without enough behavior similarity from hoster to hoster. A problem for server configurators, for software providers and for site owners. The generated problems will accompany us still for a while... I think, 6 to 12 months...

The total problem with OSCOMMERCE is as follows: There are 3 major versions in frequent use: ============================= - (1a) OSCOMMERCE (from oscommerce.org since summer 2007 compliant with PHP 5.x and MySQL 5.x - (1b) OSCOMMERCE by Fantastico - in the TCH version not yet compliant - the specified patches will probably settle this (I imagine that this is probably meantime done on the pre-installed version). Extremely easy for programmers, but I guess that average shop owners will have some difficulties with it. - (2s) Variant CRE-LO (not named in full here in this forum, due to some competition aspect in the field of hosting) I have THIS one in use on TCH, it has 30++ extension packages inside, and has far more PHP 5.x probllems in old verions 2004 or so - (2b) CRE-LO 6.2 / current download : should be compliant, was implemented just now on TCH server, dides NOT work properly, I cancelled the efforts for debugging, but think it is o.k., just a strange single config problem. - (3) XT-Commerce / current 3.04 , apparently already based on current original OSCOMMERCE 3.x alpha test. I just implemented this on TCH. It works but has various set backs. - (4) and there are some other variants with own names. Resume + Opinion ==================== Oscommerce has become old and has problems, doesn't matter from which side you try to take it. Apparently, lack of financial user support (hence shop owner egoism) has discouraged the programmers. The marketing for the derived variants is of much higher quality than the programmers' add-ons - perhaps the marketing people did not leave enough money for the brains? Consequently, I will soon leave OSCCOMMEWRCE and close this chapter forever. Update support is below the minimal needs but this is caused by shop owner egoism. While definitely replacing OSCOMMERCE here (probably by some own software /will become freeware), I am trying to enable for others the creation of coherent shop owner support service for OS-COMMERCE I have implemented a starting point for this on the Wiki : infos7.org Type there into the search field : ENXEN MENU OSCOMMERCE (If such an information is not wanted on this forum, this post can be wiped out by the administrator.) There shop owners and developers can add experience with the goal of step-by-step creation of a handbook for the major current shop owner problems with all major variants of OSCOMMERCE. This is the last thing which I will do in favor ot OSCOMMERCE, in order to pay my thanks for the many years of service for one of my business partners.

Good news, I got it settled for the past version of OSCOMMERCE. ====================================================== My preceeding 3 posts here show the way: - Adapt OSCOMMERCE for new MySQL (a manual source code patch). - If necessary, adapt .htacess and php.ini so that PHP gets increased backwards compatibility for YOUR part of shared hosting. (I did not check if this is really required for TCH hosting) - Believe in God and trust him for the rest. :-) It helped. The proof, the shop is up again. The OSCOMMERCE version within Fatastico (in the Cpanel of TCH) ====================================== It is specified as OSC 2.2 , version from 2006-08. It requires as PHP configuration: globals ON (OSC 2.2 from summer 2007 is the first working also with globals OFF) I could not find out if v.2006-08 will already work with MySQL 5.x. If there are problems, then please send a message through this forum because I have now the solution for this kind of problems. Thanks to TCH. =============== The server updates was announced in time - many hosters do not. So I had already prepared the possible solutions. And the server updates have been done with much care - everything works. And no compromise in favor of parallel use of old PHP versions - I agree with this - never to look backwards in computing

Current state of troubleshooting / OSCOMMERCE ( ========================================== First it should be said that the update strategy of TCH is how it should be done. The valid reasons have been stated above, and I fully agree. The problem is due to lack of backwards compatibility for PHP and MySQL. It is not the place here to discuss this. For OSCOMMERCE is the special additional problem the slowness of ongoing development, a probleme already since 2003 or so, perhaps due to lack of financial user support. There are some commercial service providers distributing OSCOMMERCE, but their offers (own brands) would for various reasons be a difficult choice. Past OSCOMMERCE will not any more work with new PHP 5.x and MySQL 5.x ============================================================== The difficulties with MySQL had finally been resolved here, in these hours. Meantime on the server also PHP had been updated, and now far more difficult problems occurr. The best might now be to re-install - but which shop software to re-install? ==================================================== I am just checking how to optimize this decision, espec. if OSCOMMERCE now works properly with current PHP and MySQL. It is sure that OSCOMMERCE 3.0 will conform (announced this way on oscommerce.org). OSCOMMERCE 3.0 is in preparation since approx. 2003. - so far no stable version. If anybody has a good idea - please add it here.

Oscommerce can have major problems with new MySQL 5.x on TCH. ========================================================= Worldwide, there are probably now hundreds of OSCOMMERCE shops down with the message 1054 - Unknown column 'p.products_id' in 'on clause' Place this message into the Google search field, and you will find 30 or so from them. The very ugly problem is that there are so many variants of OSCOMMERCE - many with other brands - , and that individual modifications have been applied for most shops (re-writes of layout segments in the source code). So it is a bit risky to apply standard OSCOMMERCE update patches. I am just settling this kind of problem for an OSCOMMERCE Shop on TCH. So I suggest that others with the same problem add their experience or Howto. As far as I understand the problem, the modification of the definition of the ========================================================= "join" command of MySQL is mainly concerned. The current OSCOMMERCE 2.2x fixed it and can be downloaded. So I will do this now, un-archive on the local LINUX PC, will then compare the main file index.php (top level directory) with the help of diff program. As far as I could already state, my version of 2004 is enough recent for this way. There are probably only some small precise differences in the source code - like replacement in MySQL commands: FROM: join xxxxxxx where INTO;: join ( xxxxxx ) where Hopeful that it settles the problem. ================================= I stated in forums that the many OSCOMMERCE variants in use will perhaps require some further small modifications - is variant-depending. So I am opening here an opinion exchance about this. (Or is this already done somewhere here in this forum? My keyword search for it did not supply results).

The real task of adaptation / PHP 5.x ============================ I already had to do it on other hosting accounts and for various software. I do not want to go into details here and for now. There is not so much to fear for PHP souce code. But here the ugly problems: === empty=== has been redefined between 2 relatively recenct PHP versions. I do not know, which ones I NEVER use in my own prgs such commands. Many or most prgs do, I removed in a major freeware software a while ago hundreds of them (replacement by if isset or if 0 or so. ) Since the time of COBOL, computing engineers are in the philosophical battle against the various types of NOTHING or NOT-BEING ( see Heidegger, the NICHT-SEIN... ). See the NULL etc. in MySQL - a heritage of this - I would never work with such features. if your PHP programs do not stay away of the old empty for variables, you might get nothing-works-any-more problems. === Some other problem is if the hoster sets for PHP now GLOBALS OFF (default of newer PHP versions, was ON earlier) As far as I could state, TTC has after the updates left : globals ON If the server is set to OFF , you could set them to ON in .htacess - normally. If some security utilities are installted on a server for PHP, it will not work like ''normally''. You will have to configure on your account something witth php.ini and .htaccess. No need for details - looks like no need for all of this at TCH, at present. == An additional possible problem is the disabling of error message display. This can "normally" be settled with .htaccess , creating an error log (I am fetching all error logs automatically every day with curl directly into my LINUX editor KATE..) But probably not needed for TCH, at present. === This information tries an answer to various messages what might happen. So this opinon might be helpful, and the kind TCH experts can comment it if there is any important rectification to add to this text or if there are errors - I am not an epxert of this subject and are therefore interested, too, to get rectification of errors here above, if any.

Thanks! Yes, basedir problems can require to ask for help from the support service, to modify the way how security aspects are configured. It was settled this way. Thanks, all help was fast and perfect.

In fact, there should normally be no problem, because at TCH, =================================== the ,,restriction'' is evidently defined that the whole customer site belongs to the allowed paths (within basedir ). But I stated since today such a rare problem on a site =============================================== (the problem is possibly up to 4 weeks old) The software, an OSCOMMERCE variant, worked well since 9 months. Only image uploads do not any more work. - Error message (part): ### Warning: move_uploaded_file(): open_basedir restriction in effect. ### File(/home/ladenxc/public_html/ccr/im.../rec....jpg) is not within the allowed path(s): ### (/home3/ladenxc/:/usr/local/sqmail/:/usr/lib/php:/usr/local/lib/php:/tmp) ### in /home3/ladenxc/public_html/ccr/.... /.../xxxxxxx.php on line 100 Probable Reason: ============ All past configurations had been done with /home/ladenxc/ based on automatic path detection during INSTALL - and all is now, too, working well, excepted image uploads - Apparently basedir wants instead: /home3/ Is this a problem from a recent server reconfiguration? Or is there some other simple explanation? ---------------------------------------------------- Before studying this problem in detail, I am waiting if somebody knows a helpful simple way how to settle this. Thanks for any help!

Thanks for the welcome messages! By the way, in German it is: Willkommen in der Familie. In French (I think): Soyez le bien-venu dans la famille. Helpful info for new users of MySQL data bases at TCH: Once that the data base and the DB user are created, the admininstrator should be aware that he has to link both together by using the lowest of the buttons on the MySQL menu. The automatic install methof of OSCOMMERCE works well, too (no need, in this case, to modify configure.php by hand.) There is a general silly difficulty with PhpMyAdmin for MYSQL data bases. The data import menu does not show any reaction when accepting and executing the import job. For bigger data bases and slower connections, this can take 15 and far more minutes... So do not interrupt - continue waiting. ''Don Pedro''

Difference between binary / ascii ----------------------------------------- One of the difficulties was due to the need to obsere for FTP uploads now more precisely the differentiate properly between binary and ascii. The automatic recognition features for this may differ between hosters. So if the image display does not work on a new server, this is one of the possible reasons. - ''don pedro'' - Thumbs Up

Implementation problems with OSCOMMERE ? ... ... I am porting a running shop in OSCOMMERCE ------------------------------------ to a site on a TCH server. Here some helpful information for those who want to do this, too: I downloaded my (a bit modified) OSCOMMERCE code from the former site (not TCH) und uploaded the identical file set to the new site (TCH). I dumped / re-inserted the MySQL data. (Requires .gz and - better - ''complete'' inserts. Otherwise 'some 'magic character conversions'' for French, German creates ESCAPE char conflicts.) I updated by hand the files configure.php (files from OSCOMMERCE). There were some time-consuming problems, but all were due to my specific modificationss of OSCOMMERCE and so on. So if you have problems porting an OSCOMMERCE shop to TCH, try to find the reasons in your specific code and data und verify your import method and thie files configure.php . The original OSCOMMERCE, as well as extension modules, all should work with absolutely no need of modification on TCH servers. - ''don pedro'' -

MySQL data base and user creation: Many users had a same problem - read the forum messages - which could be eliminated by several lines of minimal instruction: The created use and the created DB name have to be linked together. This is evident if you did it once. Otherwise it is not evident, and it can take hours to find the reason why OSCOMMERCE or anything else does not work, the error messages are as usual for MySQL and PHP, hence good guidance, but sometimes no clear error location...