我們在用火車頭采集的時候，一般很少有人采集文檔的發(fā)布時間，基本都是采集了直接發(fā)布，所以今天我遇到一個問題，就是采集好的內(nèi)容發(fā)布到dede后，看到系統(tǒng)入庫時間為3-19，正常，但是在文章頁顯示的時間為：暫無，列表頁顯示時間為1970-01-01，確實(shí)看著很不舒服，也不知道這個會不會對程序產(chǎn)生其他影響，初步猜測是在火車頭的發(fā)布模塊出了問題。
還是原來的思維，能解決的話，盡量解決下，網(wǎng)上找教程。也真不太好找，找到的都是dede采集之內(nèi)的，火車頭采集雖然也是采集，但跟dede采集卻又不一樣，后來找到這樣一個，先寫在這，大家看到了一定不要嘗試，否則你會后悔的。如果你只想知道如何解決1970的問題的話，這幾段都可以略過。但希望你懂得他是如何實(shí)現(xiàn)的。
一、錯誤解決方案剖析
首先在phpMyAdmin查看dede_archives這個表的sortrank和pubdate的一個值,你的時間是1970-01-01 00:00:00他的值就是28800好像這個..你自己查看看,改現(xiàn)在現(xiàn)在的時間比如2009-08-13 00:00:00
的值就是1250150400
那么你在后臺dede_archives這個表的sortrank和pubdate 把28800替換1250150400 搞定…
批量替換發(fā)布時間，入庫時間，更新時間的方法。
首先要知道一個文章有三個時間。
對應(yīng)的是數(shù)據(jù)庫的dede_archives表，請根據(jù)你的實(shí)際情況更換前綴。
這個表里有三個表示時間的字段：
pubdate：發(fā)布時間(前臺可更改)
senddate：入庫時間
sortrank：前臺調(diào)用最新文章。實(shí)際上是用這個時間。
我采集的文章不知道什么原因，入庫后都是2021年的。后面手工增加的2009年的文章。
在首頁等地方用pubdate排序方式都只能調(diào)出采集的2021年文章，
通過PHPMYADMIN查看發(fā)現(xiàn)有以上三個字段。
注意：里面的數(shù)值不是直觀的。
如不是2009-01-13 14:13:32而是1231846313
所以我們在批量替換的時候要這么做。
第一步。在后臺新增一個文章。
得到一個時間，比如2009-01-13 14:13:32，這可以通過管理文章那里看到。
第二步，后臺執(zhí)行SQL語句SELECT * FROM dede_archives order by id DESC limit 1
這樣你可以看到你剛才新加加的文章一所有字段值。
觀察以下的數(shù)據(jù)：
pubdate：1231846313
senddate：1231846313
sortrank：1231846313
|
其中1231846313就是時間數(shù)據(jù)了。
然后就是替換了。
UPDATE dede_archives SET sortrank = 1231846313;
UPDATE dede_archives SET senddate = 1231846313;
UPDATE dede_archives SET pubdate = 1231846313;
|
首先，看到第一句話應(yīng)該就可以pass他了，下面具體說說，他這個方法的問題在哪里(注：這種執(zhí)行sql語句，或者需要修改數(shù)據(jù)庫的一定先備份數(shù)據(jù)庫)。
對應(yīng)的是數(shù)據(jù)庫的dede_archives表，請根據(jù)你的實(shí)際情況更換前綴。
這個表里有三個表示時間的字段：
pubdate：發(fā)布時間(前臺可更改)
senddate：入庫時間
sortrank：前臺調(diào)用最新文章。實(shí)際上是用這個時間。
這段說的是沒有問題的，我再詳細(xì)的說下：
1.pubdate：發(fā)布時間(前臺可更改)
在發(fā)布新文章或編輯文章時，可在高級參數(shù)里看到，可以更改。也是系統(tǒng)在內(nèi)容頁及列表頁調(diào)用的時間。當(dāng)發(fā)布時間為1970時，列表頁會顯示1970-01-01，而文章頁獲取的發(fā)布時間則為“暫無”，當(dāng)然這個以dede默認(rèn)模板為準(zhǔn)，如果你修改了可能會有其他結(jié)果。如：我的待審核文章審核發(fā)布時會自動更新為當(dāng)前系統(tǒng)時間(如果不會設(shè)置，看Dedecms未審核文檔自動更新發(fā)布時間)
2.senddate：入庫時間
根據(jù)字面意思即可理解，但是所謂的入庫時間體現(xiàn)在哪里?就是dede后臺檔案列表中的“錄入時間”，理論上dede后臺無法修改，但實(shí)際也可以執(zhí)行sql語句修改，并無實(shí)際意義。如果你的文章命名規(guī)則為“{typedir}/{Y}/{M}{D}/{aid}.html”的話，也直觀的提現(xiàn)在你文章頁的url中。
3.sortrank：前臺調(diào)用最新文章。實(shí)際上是用這個時間。
這個時間我們一般看不到，但是前臺模板設(shè)置為“orderby=’public’的話，系統(tǒng)就是按照這個時間來調(diào)用的。說了一大堆只是在強(qiáng)調(diào)這些細(xì)節(jié)，也算是講講原理吧。
其次，我們應(yīng)該了解，即使是火車頭采集，或者dede采集，pubdate、senddate、sortrank這三個時間也不可能完全一致，所以這里也有點(diǎn)問題，但是無傷大雅，最終要的在于，這個方案是修改了整個系統(tǒng)的數(shù)據(jù)庫pubdate、senddate、sortrank的三個時間段，也就是說，從你發(fā)的第一篇文章，到最后一篇，都會變成你現(xiàn)在修改的這個時間，我第一次修改之后，整站的文章都成了3月19日發(fā)布的，可以說幾乎所有的東西都亂了，這個大家應(yīng)該能想明白，所以，我說備份很重要，轉(zhuǎn)載這篇文章的人，確實(shí)很害人。這種方法我覺得沒有什么可取的，完全用不上的。
二、正確的解決1970的方案
火車頭采集發(fā)布時唯一不會錯的就是系統(tǒng)錄入時間，所以，我們以這個為標(biāo)準(zhǔn)，將public及sortrank時間改為senddate(聲明下，先備份，后操作)。同時，網(wǎng)站采集比較多的考慮下，是不是有些文章的發(fā)布時間與入庫時間相差很大?如3-19采集了很多篇，發(fā)布為待審核，通過插件控制每天自動更新，4-19才更新完，如果你執(zhí)行兩條命令的話，那原來審核最晚的那些文章也會變成3-19日發(fā)布，不過你可以選擇只執(zhí)行一條命令。)
如果你不介意上面我說的，確實(shí)需要解決1970的問題的話，在dede后臺-系統(tǒng)-sql命令行工具，執(zhí)行以下命令：
1 |
UPDATE dede_archives SET sortrank = senddate ; |
|
這條命令是將前臺調(diào)用時間也改成入庫時間，如果你是我上面提到的那種，就不要執(zhí)行了，至于1970還會不會有其他影響，自己斟酌
1 |
UPDATE dede_archives SET pubdate = senddate ; |
|
這條命令是將發(fā)布時間改為入庫時間，就不解釋了，上面都說了
