Hi
I had links 2.0 installed and
i did a upgrade to Links SQL 1.1
everything is working fine just two things
are doing me problem.
1.Before upgrade i had 14 categories,
now sudenly there is 176 of categories.
2.add.cgi its not working when i submit
new site ,i am redirected to add.cgi again.

1.I wonna delete all categories and links
and import old data from 2.0.
2.I am using old templates "scrool menu"
can this be a problem?

Regards
o

just delete all the tables from setup.cgi and reimport..

see if anything changes.. as for add.cgi .. it does that if you just press the submit button? (without entering anything)

jerry

widgetz thanks
problem number 1 solved.
I found out ,what i did wrong
When i was importing first time i did that
4-5 times
and script generated 4 mirrors of each
category / links.

2nd problem if i dont enter anything
its the same,it redirects me back to add.cgi

any idea ?

Excuse me for being brief. The add form + add.cgi variable should match. Now that you found it......

Just to give you a small helping hand further.

Normally I use a function which I think without it would be very difficult and that is :

Multi File find / and replace

So one makes a project which contains a listing of files which is nothing but a directory tree. Then you can simply enter a search term and it will look into all the files within a directory tree. This kind of utilities are extremely useful for trouble shooting and replacing for e.g. spelling mistakes of replacing of changeing of colour codes of fonts in the entire website design, etc. So with my utility, I would have to simply enter - search - &process_form and it will shout loud where it is! I have done this thousand times to chase where all over Alexes sub_routines have been playing. Alex has conviniently done a lot of calls from every where "Freely", that it becomes inevitable sometimes to understand those complicated calls.

There are or may be many many utilities of this kind and playing with Links SQL you "really" need such utilities to handle such situations.

Hello!

Check in the form the value of the button should be

if ($in->param('The form submission value, for e.g. add')) {
&process_form ($in);
}

If the add.cgi does not know if it should process then it will not. Both should be the same, the value of the form and the routine in the add.cgi to redirect the add.cgi to process the form!!! I think.............

About this import, it has been truely annoying. Some of the users have had this and me too. But it may be very good if in the future, there is a routine which checks during the imports if there is an existing data in the table based on certain values.
Alternatively, you can also use phpMyAdmin utility from www.phpwizard.com to make some of the values UNIQUE. If you do not have php, then use SQL commands through editor.cgi. If those values are there in the field data, then DBSQL will crash into a fatal error and reduce confusions of duplicating the data.

rajani
where do i found that line


if ($in->param('The form submission value, for e.g. add')) {
&process_form ($in);
}

i am not such a expert
still dont understand what i must do ?

ok solved
thanks widgets and rajani

Regards
o

yes thats usefull.
but i check in readme.txt and it was explained there what i must do )

can someone tell me why are file attachments
for ?

ex: if someone attach one pictures that script uploads it in directory i define
and then ?

i have no idea where to use attached stuff?

Regards
o

Attached files can be for anything... one use would for uploading a logo or picture for a classified ad.

They should be turned off by default though? You should only be presented with an add attachment dialogue if you actually set the upload path.

Cheers,

Alex

I noticed they appear to be turned on in the Admin area.... unless something weird happened to me. I don't have them enabled... but noticed with the upgrade I'm seeing the path.

I think that's because they were on by default in 1.1b3. If you do a clean install of 1.1, they shouldn't be on?

Cheers,

Alex

The FAQ site is running 1.1 vanilla (except for the change to the days_old and new/cool pages. The file upload is off.

I guess it was a 1.1b3 version I still have that I just noticed was 'on'. Which would make sense, since I wasn't adding sites to that install, just working on templates.

By Mon or Tues I should have all the sites at 1.1 with the days_old and new/cool display mods installed.

At that point I'll be able to report bugs that are _definitely_ in the 1.1 version.

punkdog
(Attached files can be for anything... one use would for uploading a
logo or picture for a classified ad. )

i am interested in that classified ad
are there any modules for Links SQL
soo the pics will be nicely sorted.
Or i must buy or get for free some classified
script and link it with these pics?
Are there any examples i wonna see how
this works?

regards.
o

There was a classifieds ad mod for links 2.0

I think it just changed some fields and incorporated the expirator mod.

I haven't played with the image upload, but once I do I'll have more feedback on that. I've been working on the implementation of a file upload system since I really need to be able to upload and preview and image before loading it into the database.

I want to add a few twists to it, and now that 1.1 is here, this is probably my #1 priority.

Hopefully with all the preliminary work I've done I'll be able to hack something worthwhile together and start to polish it.

he called you "punkdog".. hehe

i've added a few things already.. i'm now deciding whether or not to add them to page.cgi because when you make a change to nph-build.cgi you need to do it for page.cgi too!

anyways.. just a friendly reminder punkdog..

jerry

Actually, my mods are really targeted to admin use, so it doesn't affect page.cgi (since the output is the same).

page.cgi still has some problems, many of which go back to a "global definition table."

There needs to be some data structure that when the program is invoked, begins to start keeping track of all the "tags" and things that should be available.

I can hazily visualize how this would look, but I wouldn't even begin to think about doing it until I hadm ore time to look over the changes in 1.1 that already have been made. A lot of things have moved around or changed.

This would allow any 'global' value to be available in all calls, and any local values to be available on each level.

What's happened is that the parts of the program developed, and only incorporated what they needed to actually run, rather than a good conceptualization of they should have available to the site developer -- especially with page.cgi.

I find a _lot_ of things don't work with it, and it's main value is as a good way to test templates. To roll it out is a little premature if you have done any level of customization and need a stable presentation.

The program is finally stable enough for me to move the original Links 2.0 site over to the SQL version. POSTCARDS.COM is running LinkSQL in all it's sub-levels now, not just the 'Portal.'

By this weekend, it should all be running the same versions.

After the file uploads, which is half-way there, what I'm going to play with is giving each link a way to determine how it looks by using a different template, with the default being link.html What this will do is allow records to have a different look, but come up in the regular search order. Rather than running different databases and installations, just have a default template that can be overriden at the link-level.

Of course this can get ridiculously complex, if taken out 2 or 3 generations, but with the categories allowing it's own template, the next logical sub-unit is to let the link pick how it will look. If each link.html is encapsulated inside it's own <table></table> tags, then mixing various links on a page should work.

This weekend is the milestone I've been working towards --- the move to an entirely SQL backed site. It should be much easier to start making the fine-tuning mods now.