Re: Publishing Issue

[rm]

I have had ongoing problems ... what I found is that, beside the
timezone issue, I was not being given the opportunity to set the
"Advanced Page settings" (i.e., posts per page). If I created a new
dynamic page, there was no field to edit that value, so it was ending
up as zero. Then, though I was able to make entries, they wouldn't
appear. I have an outstanding question in this forum seeking an
answer. I resolved this issue by having to go into the database table
itself and posting a value (I used phpMyAdmin to edit the
'posts_per_page' value in the 'pixie_dynamic_posts' table). After
that, the posts appear fine.

On Nov 14, 8:47 am, piatek <piatek.mar...@gmail.com> wrote:
> Hello,
> I just installed Pixie and I am having some publishing issues. I can
> create manu pages but once i make a post into the page that specific
> post will not show up.
> This also happens in Blog, they simply just do not show.
>
> I set the time zones and did whatever i found on here.
> Any suggestions ?
>
> Thank you much
> M.

[Scott]

This thread seems to have got stuck... last message from Piatek was:

------------------
ok here is the temporary fix to this issue.
i am not a php guru but i figured it will work.

in pixie_bad_behavior go to in the filed "date" hit "change" and make
a change in NULL to NULL selection, default should be not null.

thanks
------------------

not sure why this might fix it... waiting to hear more info.

Thanks

Scott

On Nov 14, 3:50 pm, piatek <piatek.mar...@gmail.com> wrote:
> What version of Pixie are you running ?
> I don't even have posts_per_page in the pixie_dynamic_posts table. I
> only have it in pixie_dynamic_settings.
>
> thanks.

[rm]

Whoops, you are right ... the posts themselves are in
pixie_dynamic_posts table, while the change I made was in
pixie_dynamic_settings page.

On Nov 14, 9:50 am, piatek <piatek.mar...@gmail.com> wrote:
> What version of Pixie are you running ?
> I don't even have posts_per_page in the pixie_dynamic_posts table. I
> only have it in pixie_dynamic_settings.
>
> thanks.
>
> On Nov 14, 10:18 am, rm <ralph.a.ma...@gmail.com> wrote:
>
>
>

[piatek]

Let me rewrite this as it was really late and i made some grammar
mistakes. lol

Navigate to PhpMyAdmin and find pixie_bad_behavior which should be the
first on the list.
Once you click on it, find "DATE" and click on "change" icon.
In the NULL drop down "NOT NULL" will be set as default, and once you
view the drop down menu you will see another selection which is NULL.
Change it to NULL and save your work.

How did i find this ?
I was trying to figure this issue out. Some said that it has to do
with different time settings between the server and Pixie.
This did not fix it for me.
Another person mentioned that their posts show up about a day after
they are actually posted so i started playing with my post dates.
First i started changing only the hour of my post manually but this
did nothing until i changed the day so lets say it was 14th, and i put
it as 13th.
At that point they started showing up right away as i was posting.
From that t was obvious to me that there is a problem with a post date
so I went into PhpMyAdmin and started looking around and to my
understanding the date should be Null.
Luck ? Maybe ...
Like i said i am not really into php as i am a graphic designer and we
dev. and all i mostly use is css, xhtml etc.

I hope you guys can figure this out.

Scott, did you confirm that this works?


Thanks
Marius.

[Scott]

Thanks for explaining Marius. I need to do some testing on this - as
the bad behavior table is not used to store posts I would be surprised
if this was the cause of your problem.

Keep an eye on it and let me know if the problem occurs again.

Scott

[isa]

Hi all,

Hmm, there definetely seems to be an issue here! I'm running the
latest pixie release from your website (1.02) and I'm hosting on a
machine that's running on America/New_York timezone.

I'm running other software and it's coping fine with my GMT local
config.

My pixie logs are showing server time, while my blog entries are
showing my correct GMT times.
I think we need to look into this. I suggest a complete overhaul might
be useful, and either storing direct server times (without conversion
to 'timestamps') and only converting to local TZ on reading db.
There would be other ways just as good, but I think there's some
unecessary complexity and/or inconsistency here.

My blogs don't show up for around 5 or 6 hours! :)

Looking forward to your reply ..
Isa

-Small is beautiful-

[Scott]

Your absolutely right. It could do with a complete overhaul. From what
I have been looking at, timezones are easy to set with something like:

putenv( "TZ=".$timezone);

But it does not account for different MySQL times.... I found this
recently:

http://jokke.dk/blog/2007/07/timezones_in_mysql_and_php

Which seems a sensible method for handling both. One thing I am not
100% sure about is if the timzone setting should be right for the
person using Pixie or the server... which should it be?

Any thoughts?

Scott

[Sam Collett]

For me at least, the problem seems to come down to the fact that NOW()
in a MySQL query uses the timezone of the MySQL server (or whatever
you have set the timezone with (e.g. SET SESSION time_zone='+0:00'),
not what the timezone for PHP is (using putenv).

When you insert a dynamic entry, it inserts it as the date and time
according to the timezone of Pixie. Log entries use Unix time and when
you use MySQL queries, the MySQL timezone is used... these could all
end up in different time zones.

There are a few options, but they assume SET SESSION time_zone and
putenv work:

1. Always use Pixie time zone, including for log entries
2. Use UTC time, but store offset in additional field when adding
dynamic entries or events (or other things that allow user entered
dates)

The second option has a benefit of allowing timezones to be set per
user, instead of for (or in addition to) the site... then dates can be
displayed using local user time (user 'A' posts 2009/27/09 10:20 UTC,
user 'B' (in California, GMT -8) sees 2009/27/09 2:20).

It would mean using a method to display the date (e.g. FormatDateTime
($date, $format) - where $date is a UTC date, $format is the format
you want it displayed. Within the method it will use an offset -
either the timezone offset for a user retrieved from the database (if
logged in), or 0 / site time zone). Developers would also have to take
into account that anything involving dates will be UTC.

Perhaps have a utility class, with methods like FormatDateTime (and
maybe other things people may find helpful)?

--Sam

[Sam Collett]

Another solution maybe...
How about using "Europe/London" instead of "+0:00"? Not tested to see
if it will work though.

This depends on the timezone database being up to date in mysql
though.

You can get a list of timezones using timezone_identifiers_list
(http://www.php.net/manual/en/function.timezone-identifiers-list.php),
however it requires PHP 5.1. If you get a list when you use this code,
then it is supported:

<?php
$timezone_identifiers = timezone_identifiers_list();
for ($i=0; $i < count($timezone_identifiers); $i++) {
echo "$timezone_identifiers[$i]\n";
}
?>

Rather a large list, a bit to big to scroll though, so if it was used,
it would probably need to be split up when displayed, e.g. continent
dropdown, then city (have to use AJAX, or post back to page).

--Sam

[isa]

Hi scot, sam ..

I've come up with an easy solution which doesn't involve much change
to the code ..

At least, the main problem seems to be when the server and local times
are different.
Why? Because the TIMESTAMP fields in the mysql tables are stored in
UTC and in several places (in dynamic.php and others?) they are being
compared with 'now()'.

'now()' would be the server time which works fine if the server is on
UTC (same as GMT) time. Otherwise not, because you can't compare
unless they are the same timezone.

Anyway, the nitty-gritty is just to change 'now()' to 'utc_time()'.
It works! We're now comparing UTC times whatever timezone the server
OR the client is on :)

Hope this helps ...

[Scott]

That sounds too good to be true! Could it be that simple?

If anyone can play with this in a timezone out side of the UK - that
would be a big help.

Scott

[rm]

For what it's worth, I made a back-up copy of my local install, and
then made a global multifile change of now() with utc_time() and not
only did it not show the most recent entry, it did not show any
entries at all (everything breaks: archives, popular posts, tags,
etc). Mind you, I have incorporated Scott and Sam's prior suggested
timezone alterations, so that may be causing a problem. (FYI, the
changes from Scott and Sam work fine in my case, both locally, as well
as with a server in a different timezone).

[isa]

Hi all

LOL ... sory, sorry, I was so busy 'rattling on' that I slipped:

It's a TIMESTAMP, not a time [ now() ]

That should have been utc_timestamp() NOT utc_time

Did you try that rm ?

Isa

- Small is Beautiful -

[rm]

Okay, so I made a backup of my local install, and did a global
multifile replace of 'now()' with 'utc_timestamp()', and it seems to
work fine. So, to ensure that the changes that Sam and Scott have
suggested were not simply covering the change, I replaced all my
tweaked files with stock Pixie files from a clean install, and made
the change again. And it still worked! So it would appear that isa has
hit on the solution. I have yet to test on a remote server in a
different timezone than my own, but I suspect that test will also be
successful. Kudos to Isa!

[rm]

I did a fresh install of Pixie (with universal replacement of 'now()'
with 'utc_timestamp()' ) onto the server in a different timezone. I
then added a blog entry, and it appeared immediately. So it looks like
Isa has cracked the timezone nut that has faced Pixie.

[Scott]

Great stuff. I will so pleased to get this bug nailed.

rm - Was this a fresh install of Pixie (1.02) or a version of Pixie
with the existing Timezone fixes in place (commited by sam)? Do the
times in the dashboard display as expected as well?

Scott

[rm]

It was a fresh install without any other fixes, but I did not pay
attention to the times in the dashboard. If Isa could advise you,
that'd be great. Otherwise, I can do another install and let you know.

[rm]

Hi Scot. If you're still there, I did a completely fresh install (with
only "now()" changed to "utc_timestamp()" throughout; no other
changes), and the dashboard shows:
Statistics - 29 November 2009, 09:58 (this is my correct local time,
the server is in a different timezone)
Last login on: 29 November 2009, 15:57 (this ought to be 09:57, so it
is 6 hours off)

[Scott]

Thanks Ralph
Thats good to know. I will do some more testing. Very keen to get this
out of the way :)

Scott

[isa]

Mmm,

The issue you're referring to is coming from a different source.
By the way, I notice there is a global variable called $timezone
referred to in lib_date.php.
Where is this variable being set (from the db), I can't find it ...
If it's NOT being set, then it certainly should be, no? (used in
tz_offset)

When you say that you replaced the now()'s globally, you did mean IN
EVERY Php script:
mod_myaccount.php .. lib_auth.php .. lib_logs.php .. lib_rss.php

One thing though; using now() when updating fields will still result
in a UTC timestamp being recorded :-)

[Hort Club]

I am not familiar with where the now() is located. I would like to
help. I am in PST and my server is in PST, but by my third post it
takes hours before it is displayed. How can I check the server
timezone setting so I can compare. And which files or data tables
need to be changed for this to be tested. I am in GMT-8. By the way,
the way you guys talk is almost way over my head. Baby step it
please, I can locate the files and settings and change them if I know
what you guys are talking about.

[isa]

Got your comment Gerschel ... right ok:

The file responsible for delayed publishing in a tzone other than GMT
appears to be
admin/modules/dynamic.php
There are a few lines mentioning now() - - -change them to
utc_timestamp()

ie.
and public = 'yes' and posted < now()"));
--->
and public = 'yes' and posted < utc_timestamp()"));

I should imagine with a bit of patience, Scott & co. will release a
bug update.
However, there's no point in rushing these things, can make it
worse :)

Isa

- Small is beautiful -

[rm]

Isa, you can look at the post "Entry not showing up" <http://
groups.google.com/group/pixie-cms/browse_thread/thread/
eec0034cc71a0b35#> to see where the dashboard time needs adjustment.

With regard to your question, I am using BBedit and I did a global,
multi-file search-and-replace of "now()" with "utc_timestamp" ...
there were 24 replacements throughout all the files.

[Sam Collett]

Anyone able to test if the following works (in non GMT timezones)?
Instead of just putenv, replace with:

if(function_exists("date_default_timezone_set"))
{
date_default_timezone_set($timezone);
}
else
{
putenv("TZ=$timezone");
}

This would just mean it won't effect any other application on the web
server that uses the TZ variable (Apache logging?) - although I am not
100% sure if it does impact anything else.

--Sam

On Nov 26, 10:34 am, Scott <scotts...@gmail.com> wrote:

[isa]

I agree with you Sam, that it would be preferable to set the timezone
in the php scripts.
However, as pixie_v1.02 uses mainly sql timestamps, it will probably
take a while to settle down, and introduce more bugs for a while.
Putting 'php time vars' into sql queries might perhaps be confusing ..
either one or the other?
I would have thought that using/setting php local TZ, it would then be
better to store time values as BIGINT as 'php time()' returns 'no. of
secs since jan 1970'
ie. Unix time integer

While you decide which way to go, I've come up with a bugfix which
shouldn't interfere with the original design of the program, as it
carries on using mysql timestamps and tz_offset and has minimal
changes to the code.
For those people who are having trouble with delayed publishing or
wrong time/date displays who are either in a TZ other than GMT, or
their server is in another zone etc, they may like to follow the link
below:
http://isa.x10hosting.com/wiki/pmwiki.php?n=Programming.TimeZone

Anybody who wishes to test the zip file, or add other major bugfixes
(if any) and/or upload to the pixie project are very welcome to do so.

Isa :)