118 replies to this topic

[kartav]

apodigm, on Sep 21 2004, 05:07 AM, said:

Good luck.

Thank you very much Apodigm.
I will try to use your help.

[Dimmy]

I found a small bug

when you paste some html in the Default Value: field you get this result  Gax_Export.gif   4.31K   281 downloads

I paste this piece of code to get that

<IMG src="/assets/images/logo_2.gif">

it works fine but looks a bit weard as you can see in the image

Greets Dimmy

(also implemented the Spaw editor works like a charm.)

[apodigm]

hmmm...

Yeah. you might need to use htmlspecialchars to clean the raw results from the database if it has ' or " characters in it.

[Dimmy]

When making a new weblink the DCV are still ther but there is no use for them so I added this line in mutate_content.dynamic.action.php so that the DCV's are not showing in the making a weblink page.

<?php if($content['type']=="document" || $_REQUEST['a']==4) { ?>

looks like this now:

<!--//Added by Apodigm 09-06-2004- DocVars - web@apodigm.com-->

<?php if($content['type']=="document" || $_REQUEST['a']==4) { ?>
<?php
$sql2 = "select field_name, field_description, field_caption, field_type, default_text, rank, field_elements from $dbase.".$table_prefix."docvars_fields order by rank"; 
$rs2 = mysql_query($sql2); 
$limit2 = mysql_num_rows($rs2);
if($limit2>0){
?>

Greets Dimmy

[edit] Somthing whent wrong it workt but now I get a parse error:
Parse error: parse error in /var/www/html/manager/actions/dynamic/mutate_content.dynamic.action.php on line 721
line 721 is an empty line on the end of the document

So sorry I think this is not working some how.. [/edit]

[apodigm]

not sure why you are having problems.

Did you run the SQL commands in the contribution files?

You should be able to overwrite your existing Etomite 0.6 install with the changed files that I included in the contribution. Or use a Diff program (like www.scootersoftware.com Beyond Compare or WinDiff) to compare the files to see what is different in your install.

[apodigm]

dump RC2. install 0.6 ... then start over with the contribution. It was specifically coded for 0.6.

...or you can use a diff program in MAC (linux kernal?) to compare the 06/Docvars clean install to your existing installation.

...or send me the backup of your entire site, along with database and I will reproduce on my machine to correct your problem and send the files back. But I will not have the time to troubleshoot your website until Monday.

[marco]

stebrennan, on Sep 8 2004, 04:32 PM, said:

--------

forget this, wrong thread.

[jaredc]

Main site page for downloads:

http://www.etomite.com/downloads.html

[apodigm]

All... apparently not all "0.6" are created equal. I have just been noticed that there are some minor changes between 0.6 RC2 and the final version of 0.6.

Never fear. I have just downloaded the most recent version of 0.6 and updated DocVars so that it is compatible with the final release of 0.6.

.... In this roll-up, I have also included the template manager changes by stebrennan, some tweaks for the weblinks, docvar handling, and updated SQL install script.

So.... if you start with a stock install of 0.6 and then follow the new DocVars contribution, you will be set up in no time with custom document variables - associated with the templates.

Please go to the first post in this message thread to download the new version of DocVars.

[mrpif]

First I want to say I've started to use DocVar and I really like it! Great job!

I'm using it for an agenda section on my site. One of the document variables I need in this section is a date (the event's date, independent from the (un)publication dates), but I'm running across what seems to be a bug in the way dates are retrieved and displayed when one wants to enter a date on a new page or modify an existing one:

1. When setting the date for the first time, clicking on the 'Select a Date' button opens the calendar pop-up in January 1970

2. When modifying a page, whatever the saved date was, the input box show "01-01-1970 01:00:22" ("01:00:22" being the current local time), even though the date was previously saved correctly. Hence, clicking on the 'Select a Date' button opens the calendar pop-up in January 1970.

This problem occurs only for date DocVars, not for the standard date variables (publication / unpublication).

Help!

[apodigm]

mrpif, on Oct 19 2004, 05:20 PM, said:

First I want to say I've started to use DocVar and I really like it! Great job!

1. When setting the date for the first time, clicking on the 'Select a Date' button opens the calendar pop-up in January 1970

Help!

Hmmm.... I don't use the date function much. I'll do some testing on it.

Try this...

In manager/includes/docvars_fields.php around line 39...
comment out this line so it looks like this:

   //            if($field_value=='') $field_value=0;

This will remove the default value of the date field. The default value is being changed to "0" which the calendar popup interprets as January 1st, 1970. (not sure... I didn't write that control.

I noticed that Alex already had some code to set the default value to "" so this should fixe everything for you as far as the default value goes.

let me know if this works.

[mrpif]

apodigm, on Oct 19 2004, 01:53 PM, said:

In manager/includes/docvars_fields.php around line 39...
comment out this line so it looks like this:

   //            if($field_value=='') $field_value=0;

This does not solve the problem. Although, modifying that line this way:

$current_time=time();
if($field_value=='') $field_value=$current_time;

... and replacing the two

$field_value==0

conditions a few lines lower by

$field_value==$current_time

seems like it solves the problem.

But I found there's a deeper problem: if I select a date, say "21-10-2004 15:37:17" in the calendar and then save the page, the date gets stored as "21-10-2004 15:37:17" (i.e. a string) in the etomite_docvars_values table, not as "1098365837" (correct date format, i.e. an integer representing the number of seconds since Jan 1st, 1970).

So when etomite retrieves the date, it doesn't parse it correctly (actually, it just takes the two first digits --the day-- and displays it as the seconds of "1970-01-01 01:00:SS".

I'm searching the actions/dynamic/*.php files for the place where the date gets formatted wrong before it gets sent to MySQL...

[mrpif]

Oops, my mistake, there isn't any problem as long as the Date DocVar hasn't been saved to MySQL. All apologies. So no need to modify includes/docvar_fields.php, it works just fine to select a date the first time.

What needs to be done instead is to insert a condition similar to the one used for the publication date (lines 49-59 in save_content.processor.php), which would convert the date string into a date integer for all date DocVars.

In save_content.processor.php, I inserted the lines:

       }elseif($row['field_type']=='date'){
            $docvar_date = $_POST[$row['field_name']];
            if($docvar_date=="") {
           	 $docvar_date="0";
            } else {
           	 list($d, $m, $Y, $H, $M, $S) = sscanf($docvar_date, "%2d-%2d-%4d %2d:%2d:%2d");
           	 $docvar_date = strtotime("$m/$d/$Y $H:$M:$S");
            }
            $docvars[$row['field_name']] = $docvar_date;

around line 175, before the "else" part of this conditional (starting at line 128)

       if($row['field_type']=='file'){

... and now the date is stored properly in MySQL.

My next problem is: now this date DocVar gets displayed as an integer when I use its [*...*] code. I guess a short snippet will do the conversion...