上門一對一計算機家教
當前位置: 首頁 > dedecms家教 >

火車頭采集文章織夢dedecms發布時間變為1970年解決辦法

點擊: 時間:2014-09-23 來源:北京家教網
我們在用火車頭采集的時候,一般很少有人采集文檔的發布時間,基本都是采集了直接發布,所以今天我遇到一個問題,就是采集好的內容發布到dede后,看到系統入庫時間為3-19,正常,但是在文章頁顯示的時間為:暫無,列表頁顯示時間為1970-

我們在用火車頭采集的時候,一般很少有人采集文檔的發布時間,基本都是采集了直接發布,所以今天我遇到一個問題,就是采集好的內容發布到dede后,看到系統入庫時間為3-19,正常,但是在文章頁顯示的時間為:暫無,列表頁顯示時間為1970-01-01,確實看著很不舒服,也不知道這個會不會對程序產生其他影響,初步猜測是在火車頭的發布模塊出了問題。

還是原來的思維,能解決的話,盡量解決下,網上找教程。也真不太好找,找到的都是dede采集之內的,火車頭采集雖然也是采集,但跟dede采集卻又不一樣,后來找到這樣一個,先寫在這,大家看到了一定不要嘗試,否則你會后悔的。如果你只想知道如何解決1970的問題的話,這幾段都可以略過。但希望你懂得他是如何實現的。

一、錯誤解決方案剖析

首先在phpMyAdmin查看dede_archives這個表的sortrank和pubdate的一個值,你的時間是1970-01-01 00:00:00他的值就是28800好像這個..你自己查看看,改現在現在的時間比如2009-08-13 00:00:00

的值就是1250150400

那么你在后臺dede_archives這個表的sortrank和pubdate 把28800替換1250150400 搞定...

批量替換發布時間,入庫時間,更新時間的方法。

首先要知道一個文章有三個時間。

對應的是數據庫的dede_archives表,請根據你的實際情況更換前綴。

這個表里有三個表示時間的字段:

pubdate:發布時間(前臺可更改)

senddate:入庫時間

sortrank:前臺調用最新文章。實際上是用這個時間。

我采集的文章不知道什么原因,入庫后都是2021年的。后面手工增加的2009年的文章。

在首頁等地方用pubdate排序方式都只能調出采集的2021年文章,

通過PHPMYADMIN查看發現有以上三個字段。

注意:里面的數值不是直觀的。

如不是2009-01-13 14:13:32而是1231846313

所以我們在批量替換的時候要這么做。

第一步。在后臺新增一個文章。

得到一個時間,比如2009-01-13 14:13:32,這可以通過管理文章那里看到。

第二步,后臺執行SQL語句SELECT * FROM dede_archives order by id DESC limit 1

這樣你可以看到你剛才新加加的文章一所有字段值。

觀察以下的數據:

pubdate:1231846313

senddate:1231846313

sortrank:1231846313

其中1231846313就是時間數據了。

然后就是替換了。

UPDATE dede_archives SET sortrank = 1231846313;

UPDATE dede_archives SET senddate = 1231846313;

UPDATE dede_archives SET pubdate = 1231846313;

首先,看到第一句話應該就可以pass他了,下面具體說說,他這個方法的問題在哪里(注:這種執行sql語句,或者需要修改數據庫的一定先備份數據庫)。

對應的是數據庫的dede_archives表,請根據你的實際情況更換前綴。

這個表里有三個表示時間的字段:

pubdate:發布時間(前臺可更改)

senddate:入庫時間

sortrank:前臺調用最新文章。實際上是用這個時間。

這段說的是沒有問題的,我再詳細的說下:

1.pubdate:發布時間(前臺可更改)

在發布新文章或編輯文章時,可在高級參數里看到,可以更改。也是系統在內容頁及列表頁調用的時間。當發布時間為1970時,列表頁會顯示1970-01-01,而文章頁獲取的發布時間則為“暫無”,當然這個以dede默認模板為準,如果你修改了可能會有其他結果。如:我的待審核文章審核發布時會自動更新為當前系統時間(如果不會設置,看Dedecms未審核文檔自動更新發布時間)

2.senddate:入庫時間

根據字面意思即可理解,但是所謂的入庫時間體現在哪里?就是dede后臺檔案列表中的“錄入時間”,理論上dede后臺無法修改,但實際也可以執行sql語句修改,并無實際意義。如果你的文章命名規則為“{typedir}/{Y}/{M}{D}/{aid}.html”的話,也直觀的提現在你文章頁的url中。

3.sortrank:前臺調用最新文章。實際上是用這個時間。

這個時間我們一般看不到,但是前臺模板設置為“orderby=’public’的話,系統就是按照這個時間來調用的。說了一大堆只是在強調這些細節,也算是講講原理吧。

其次,我們應該了解,即使是火車頭采集,或者dede采集,pubdate、senddate、sortrank這三個時間也不可能完全一致,所以這里也有點問題,但是無傷大雅,最終要的在于,這個方案是修改了整個系統的數據庫pubdate、senddate、sortrank的三個時間段,也就是說,從你發的第一篇文章,到最后一篇,都會變成你現在修改的這個時間,我第一次修改之后,整站的文章都成了3月19日發布的,可以說幾乎所有的東西都亂了,這個大家應該能想明白,所以,我說備份很重要,轉載這篇文章的人,確實很害人。這種方法我覺得沒有什么可取的,完全用不上的。

二、正確的解決1970的方案

火車頭采集發布時唯一不會錯的就是系統錄入時間,所以,我們以這個為標準,將public及sortrank時間改為senddate(聲明下,先備份,后操作)。同時,網站采集比較多的考慮下,是不是有些文章的發布時間與入庫時間相差很大?如3-19采集了很多篇,發布為待審核,通過插件控制每天自動更新,4-19才更新完,如果你執行兩條命令的話,那原來審核最晚的那些文章也會變成3-19日發布,不過你可以選擇只執行一條命令。)

如果你不介意上面我說的,確實需要解決1970的問題的話,在dede后臺-系統-sql命令行工具,執行以下命令:

UPDATE dede_archives SET sortrank = senddate ;

這條命令是將前臺調用時間也改成入庫時間,如果你是我上面提到的那種,就不要執行了,至于1970還會不會有其他影響,自己斟酌

UPDATE dede_archives SET pubdate = senddate ;

這條命令是將發布時間改為入庫時間,就不解釋了,上面都說了

------分隔線----------------------------
30选5开奖查询