如果你在有使用 Zend Guard Loader 的網站中架設 Gallery 3 的話, 在跑完 install 的畫面之後, 你就會發現你的 Gallery 3 永遠都出現一個空白畫面. 這問題... 有人在 Gallery 那邊問, 想當然的.... 得到一個不是我們的問題的答案 (如果我是作者, 我也會這樣回答的), 也有人在 Zend 那邊問, 結果與我以前問 Zend 問題的經驗一樣.... 完全沒有任何作用. (閱讀全文)
在 Gallery 3 的 Search 模組中, 是透過 MySQL 的 full-text search 方式來處理, 不過... 這個方式對於 CJK 之類的文字, 由於無法分辨詞的斷點, 是無法正常運作的. 這個修改, 是把有非英文的 search, 改成 like 來處理 (東西一多, 也許效能會很差, 所以... 如果你的系統這樣子改之後, 找東西變很慢的話, 就不要用了). (閱讀全文)
這個模組修改自 Gallery 3 的 imageblockex 模組. (閱讀全文)
由於 Gallery 3 使用 flowplayer 這一個 flash player 的原因, 所以只接受 flv 與 mp4 (只能播 h.264, 不過有時會有影無聲) 這兩種檔案. 而在 Gallery 2 的時候, 是透過 QuickTime 的 plugin 來播放, 所以支援的格式似乎多了一些. (閱讀全文)
這問題應該很久之前就有了 (七個多月了), 修正的方法很簡單也很直覺, 不過, 不清楚為什麼一直沒被接受.
如果你想刪除這個資料, 可以選擇的進階的設定去直接修改 server_add 的那一個變數 (那是 php serialize 之後的變數值), 或者用這個 patch:
diff -Nur gallery3.orig/modules/server_add//views/admin_server_add.html.php gallery3/modules/server_add//views/admin_server_add.html.php
--- gallery3.orig/modules/server_add//views/admin_server_add.html.php 2011-05-25 12:04:04.000000000 +0800
+++ gallery3/modules/server_add//views/admin_server_add.html.php 2011-12-12 13:48:12.465883402 +0800
@@ -26,7 +26,7 @@
<? foreach ($paths as $id => $path): ?>
<li>
<?= html::clean($path) ?>
- <a href="<?= url::site("admin/server_add/remove_path?path=" . urlencode($path) . "&csrf=<?= access::csrf_token() ?>") ?>"
+ <a href="<?= url::site("admin/server_add/remove_path?path=" . urlencode($path) . "&csrf=".access::csrf_token()) ?>"
id="icon_<?= $id ?>"
class="g-remove-dir g-button">
<span class="ui-icon ui-icon-trash">
修正後就可以正常的刪除不要的路徑了.
當我們利用 minislideshow 之類的小東西在顯示某個相簿的照片時, 是直接利用 RSS 的方式來取得要顯示的照片. 不過, 在 Gallery 3 裡頭, 對於 RSS 中指定要某個相簿的時候, 是使用相簿的 ID 來選取, 利如, 我有個相簿放在 /var/albums/tommy/tommy_photo 這個目錄下, 我必需要知道這個相簿在 Gallery 資料庫中的 ID (例如是 6), 才能用 /rss/feed/gallery/album/6 的方式來取得資料. 這個對於一般的使用者來說, 要知道那個 ID 是多少, 是比較有難度的, 並不如 tommy/tommy_photo 來的直覺. 所以... 改一下程式允許用路徑來選擇, 會比較方便些. (閱讀全文)
Gallery 這軟體很奇怪, 每次改版就是一個全新的程式, 基本上與上一個版本可以當做是完全不同的程式來看待. 據作者的說法, 當初 Galley 2 的出現, 是為了解決在 Gallery 1 上頭的問題.... 而 Gallery 2 看起來是一個很成功的軟體.... 除了整個系統過於肥大之外, 應該也沒什麼缺點. 不過.... 作者還是開發了 Gallery 3, 而且這次的開發應該不太順利吧, 因為由一開始的 beta 到最後正式版的發行, 經過了好幾年. 而且.... 雖然正式版推出了不算短的時間, 整個 Gallery 3 用起來, 我覺得應該還算在 beta 階段吧.... 與 Gallery 2 比起來, 除了用了一些 AJAX 的技巧外, 在功能面上完全比不上舊的 Gallery 2.
如果 Gallery 2 用的還滿意的人, 建議先不要考慮 Gallery 3 吧, 等 3.1 (或 3.2 再來看看). 如果你決定使用 Gallery 3, 那, 這篇與後續的幾篇有關 Gallery 的文章, 應該會對你有些用處. (閱讀全文)
這幾天在測試 Gallery3, 測試 Gallery Remote 時, 發現原本裝的 Gallery2 在使用 Gallery Remote 時也無法正常登入. 登入時會出現這個錯誤訊息:
這錯誤在 Gallery Remote 的 FAQ 裡頭就有, 應該是一開始執行是會去使用 gallery_remote2.php, 如果不存在, 才會轉用別的 URL, 而在 Gallery2 的時候, 是沒有 gallery_remote2.php 的, 正常來說, 這個存取會回傳 404 not found 的錯誤, 不過... 由於我的 nginx 有對 404 做轉向的處理, 結果... 會造成實際收到的是 302 的轉向回應, 所以... 接下去就動作就不正常了.
原本希望保留我在 nginx 下的轉向設定, 只針對 gallery_remote2.php 回應 404 就可以. 不過... 試了一下, 發現似乎不能這樣子處理, 因為只要有轉向的設定, 不過是透過 php 去回應 404, 或在 nginx 對該 URL 回應 404, 都還是會去做轉向的動作.
最後... 只好在使用 Gallery2 的這個 virtual host 中不去對 404 做轉向處理, 改成回應 404 的錯誤. 如:
error_page 404 /internal_error_404_page.html;
location /internal_error_404_page.html {
internal;
}
這樣子改之後, 就可以正常登入了.
在 Gallery 2.1 的時候, 我記得沒有這個問題, 只是... 產生的檔案, 會是 UTF-8 的編碼, 在 Windows 下頭, 那一些中文反而是亂碼. 但是... 今天發現, 在 Gallery 2.2 的時候, 這個檔案就完全空白了. 大小變成 0. (閱讀全文)
今天早上睡不著, 約五點就起床了, 所以上網逛逛, 發現我這邊設定在 LifeType 中的 Gallery 外掛, 有些路徑會運作不正常, 所以花了一些時間研究了一下, 目前看起來, 整個運作都正常了, 除了不能在 Gallery 做登入的動作外, 其他的操作, 就如同在 Gallery2 的系統一樣, 都可以正常運作. (如果你有發現有那個地方不能用的, 麻煩通知一下) (閱讀全文)