Sphinx, czyli szybkie i skuteczne wyszukiwanie

Sphinx to open source’owy silnik wyszukiwarki SQL. Sphinx jest dostępny na licencji GPL 2 i jest całkowicie darmowy do zastosowań webowych.

Sphinx został stworzony przez rosyjskich programistów, aplikacja jest cały czas rozbudowywana i rozwijana, posiada płatny support.

Zasada działania Sphinxa

Sphinx jest aplikacją stand-alone, musi zostać skompilowany i zainstalowany na serwerze. Działa na zadadzie deamon-client.

Sphinx składa się z kilku narzędzi:

  • searchd – deamon wyszukiwarki. Musi być cały czas uruchomiony, na podstawie parametrów wywołania oraz konfiguracji przeszukuje indeksy i zwraca rezultaty.
  • indexer – generator indeksu. Służy do budowania indeksu, po którym następuje wyszukiwanie.
  • search – narzędzie pozwalają testować wyszukiwarkę z poziomu linii komend.
  • spelldump – narzędzie pomocne przy budowania słownika
  • indextool – narzędzie wprowadzone dopiero w wersji 0.9.9-rc2. Służy do debugowania i wyświetlania informacji o zbudowanym indeksie.

Cechy Sphinxa

  • Ekstremalnie szybkie indeksowanie (aż do 10MB/sec).
  • Ekstremalnie szybkie wyszukiwanie (około 0.1 sekundy dla 2-4 GB zbiorów danych).
  • Bardzo duża skalowalność (aż do 100 GB zbiorów danych na pojedyńczym CPU).
  • Współpracuje z wieloma typami baz danych: PostgreSQL, MySQL i MSSQL.
  • Posiada API dla języków takich jak PHP, Python, Java, Perl, Ruby i C/C++.
  • Obsługuję morfologię (przeszukiwanie pełnotekstowe (brak języka polskiego)).
  • Umożliwia sortowanie/filtrowanie wyników po zadanych atrybutach.
  • Umożliwia grupowanie rezultatów po zadanym atrybucie.
  • Wspiera stronnicowanie rezultatów.
  • Prosty, a zarazem dostarczający wiele możliwści plik konfiguracyjny.

Sphinx nie operuje bezpośrednio na bazie danych a jedynie na wcześniej przygotowanych indeksach. Dzięki temu zdejmujemy obciążenie z „wąskiego gardła”, którym w praktycznie każdej aplikacji jest baza danych i przeżucamy na serwer.

Wady Sphinxa

Jedyną znaną mi wadą Sphinxa jest to, że wcześniej stworzony indeks (po którym odbywa się wyszukiwanie) nie jest automatycznie aktualizowany o zmiany wykonane na bazie danych. Dotyczy to zarówno nowych wierszy w zaindeksowanej tabeli jak i modyfikacji zaindeksowanych już danych.

Nowe/zmienione dane pojawią się w indeksie dopiero po jego zaktualizowaniu poprzez polecenie:

indexer nazwa_indeksu --rotate

Pomimo dużej szybkości indexera, operację tą nie nie można wykonywać po każdej zmianie w bazie danych a jednie cyklicznie co kilka godzin/dni (w zależności od wielkości indeksu).

O ile brak aktualizacji indeksu o zmodyfikowane rekordy nie stanowi większego problemu, to brak nowych rekordów może stanowić dla wielu serwisów poważny problem. Często bywa tak, że użytkownicy wprowadzają jakieś dane do bazy a następnie chcą ich użyć wyszukując je. Rozwiązaniem jest mechanizm Live index updates.

W skrócie działa to następująco:

  • Na indeksowanej tabeli tworzymy 2 indexy: główny (main) i dodatkowy (delta).
  • Tworzymy tabelę sph_counter, w której będziemy zapisywać max(id) z indeksu głównego.
  • Indeks główny będzie wyszukiwał w 99,9% danych indeksowanej tabeli, indeks dodatkowy będzie wyszukiwał w 0.1% danych tabeli.
  • Dzięki rozbiciu indeksowania na 2 indeksy (duży główny, mały dodatkowy) możliwe jest dużo częstsze indeksowanie indeksu dodatkowego gdyż będzie zawierał on niewiele danych, zatem reindeksacja nie będzie obciążać serwera i bazy danych.
  • Modyfikujemy sphinx.conf wg. wytycznych z linka.
  • Ustawiamy w cronie reindeksowanie głównego indeksu „raz na dzień” oraz dodatkowego indeksu np. „co 3 minuty”.
  • Zatem, co 3 minuty będziemy uzupełniać indeks dodatkowy, natomiast raz dziennie będzie uzupełniany indeks główny.
  • Każdorazowo przy aktualizacji indeksu głównego do tabeli sph_counter zostanie zapisany wartość klucza głównego (sql_query_pre), przez co indeks pomocniczy będzie startował od zera.

Zasada działania aplikacji opartej na Sphinx’ie

  • Skonfigurowanie konfiga „sphinx.conf” i zbudowanie indeksów.
  • W aplikacji, poprzez api następuje wywołanie Sphinxa z parametrami (szukana fraza, limit, offset, order etc…).
  • Sphinx zwraca wyszukane rekordy w postaci tablicy kluczy głównych (+ zdefiniowane atrybuty).
  • Na podstawie ID’ków kluczy głównych wyciągamy dane z bazy (lub z cache’a) i prezentujemy w serwisie.

Szybki tutorial

  • Tworzymy i konfigurujemy plik konfiguracyjny sphinx.conf.
  • Bujemy indeks(y)
    indexer --all
    
  • Odpalamy demona:
    /usr/local/bin/searchd -c /usr/local/etc/sphinx.conf
    
  • Testujemy wyszukiwanie po indeksie:
    search [INDEX_NAME] SZUKANA_FRAZA
    
  • Podpinamy API
  • Testujemy wyszukiwanie poprzez API

Błąd „connection to 127.0.0.1:9312 failed (errno=111 ….”

W przypadku gdy najpierw został uruchomiony deamon Sphinxa a dopiero później stworzony indeks to aby API działało poprawnie należy zrestartować demona. To samo tyczy się przypadku gdy w indeksie sphinx.conf zostały zmienione zwracane atrybuty.

/usr/local/bin/searchd --stop
/usr/local/bin/searchd -c /usr/local/etc/sphinx.conf

Błąd „błąd „searchd error: offset out of bounds””

W przypadku gdy chcemy zwiększyć domyślną liczbę zwracanych (przetwarzanych) rekordów z 1000 na więcej należy:

  • zmienić max_matches w sekcji searchd w konfigu sphinx.conf,
  • zrestartować demona searchd,
  • ustawić 3 parametr w metodzie SetLimits().

Z Sphinx’a korzystają między innym: craigslist.org, filestube.com, netlog.com, thepiratebay.org, wikimapia.org i wiele więcej.

Niedługo, jak czas pozwoli, postaram się jeszcze napisać coś o samym pliku konfiguracyjnym Sphinxa „sphinx.conf”.

Zaosoby Amazon S3 we własnej domenie

O samym Amazon S3 nie będę się rozwodził gdyż już nie raz pisałem o tej usłudze. Generalnie jest to bardzo wydajna usługa hostingu plików w chmurze amazona.

Problem

Standardowe URLe prowadzące do zasobów zgromadzonych na serwerach europejskich wyglądają następująco:

http://UNIQUE-BUCKET-NAME.s3-external-3.amazonaws.com/katalog/plik.jpg

Gdzie UNIQUE-BUCKET-NAME to unikalna w skali globalnej nazwa nadawana przez dewelopera.

Powyższy adres jest bardzo długi i nie wygląda zbyt przyjaźnie. Jeżeli komuś zależy na pewnych walorach estetycznych to pewnie wolałby zmienić ten adres na:

http://subdomena.domena.pl/katalog/plik.jpg

Rozwiązanie

Posłużę się przykładem, gdyż taki przekaz będzie najprostszy i najlepiej rozumiany. Załóżmy, że posiadamy domenę lorem.pl, wszystkie statyczne pliki hostujemy na Amazon i chcemy je widzieć pod subdomeną static.lorem.pl.

W Amazon S3 tworzymy bucket (jeżeli już mamy utworzony to zmieniamy nazwę) o nazwie identycznej do subdomeny czyli static.lorem.pl.

Następnie tworzymy rekord CNAME dla subdomeny static.lorem.pl i ustawiamy go na „s3-external-3.amazonaws.com.” (tak, musi być kropka na końcu). Rekord CNAME można ustawić w panelu administracyjnym dostarczonym przez firmę hostingową, jeżeli nie posiadacie takiej opcji to musicie przesłać dyspozycję na support.

Koniec, zmiany nie będą widoczne od razu, należy poczekać godzinę, maksymalnie kilka godzin, pliki wgrane na Amazon powinny być widoczne z poziomu subdomeny. Należy też pamiętać, aby po wgraniu plików na Amazon ustawić plikom odpowiednie ACL (prawa dostępu). W CloudBerry: PPM na bucket->ACL->ACL Settings->Public->OK

UPDATE z ORDER BY w jednym zapytaniu na przykładzie orderingu danych

Wstęp

Mamy przykładową tabelę z userami:

DROP TABLE users;
CREATE TABLE users(
	id SERIAL PRIMARY KEY,
	name VARCHAR(50),
	created TIMESTAMP DEFAULT NOW()
);

INSERT INTO users(name) VALUES('Marcin');
INSERT INTO users(name) VALUES('Bartek');
INSERT INTO users(name) VALUES('Agnieszka');
INSERT INTO users(name) VALUES('Dominika');

Na tabeli wykonywane były wielokrotnie operacje INSERT/UPDATE/DELETE przykładowo:

UPDATE users SET name = 'Ania' WHERE name = 'Bartek';
UPDATE users SET name = 'Dalia' WHERE name = 'Marcin';
DELETE FROM users WHERE name = 'Ania';

Zatem SELECT bez orderu wyświetli nam dane posortowane względem kolejności modyfikacji:

SELECT * FROM users;

psql=> select * from users;
 id |   name    |          created
----+-----------+----------------------------
  3 | Agnieszka | 2009-12-19 10:41:49.324851
  4 | Dominika  | 2009-12-19 10:41:49.958792
  1 | Dalia     | 2009-12-19 10:41:49.297223
(3 rows)

W interface aplikacji chcemy oprogramować własną obsługę kolejności rekordów. Dodajemy zatem kolumnę, która będzie obsługiwać tą funkcjonalność.

ALTER TABLE users ADD COLUMN order_id INTEGER;

Problem

Musimy teraz uzupełnić kolumne order_id o poprawne wartości. Kolejność orderu danych, które znajdują się w bazie powinna być kolejności wprowadzania tych danych do tabeli (czyli zgodna z kolejnością pola id).

Aby zrealizować poprawne uzupełnienie orderu tworzymy pomocniczą sekwencję, która wykorzystamy do wygenerowania kolejnych liczb do orderu:

DROP SEQUENCE order_id_seq;
CREATE SEQUENCE order_id_seq;

Wykonujemy oczywiste zapytanie przypisujące rekordom z tabeli users kolejne wartości sekwencji:

UPDATE users SET order_id = NEXTVAL('order_id_seq');  

Niestety przez to, że dane nie były ustawione w dobrej kolejności ORDER ustawiony jest niepoprawnie.

psql=> SELECT * FROM users;
 id |   name    |          created           | order_id
----+-----------+----------------------------+----------
  3 | Agnieszka | 2009-12-19 10:41:49.324851 |        1
  4 | Dominika  | 2009-12-19 10:41:49.958792 |        2
  1 | Dalia     | 2009-12-19 10:41:49.297223 |        4
(3 rows)

Rozwiązanie

Aby UPDATE poprawnie ustawił kolejność orderu należy nieco zmodyfikować zapytanie i nadać danym z tabeli users odpowiednią kolejność.

W tym celu tworzymy podzapytanie sorted_ids, w którym poprzez ORDER BY ustalamy kolejność rekordów, które następnie w zapytaniu nadrzędnym zostaną zmodyfikowane właśnie w tej kolejności.

UPDATE users
	SET order_id = correct_order_id
FROM
	(
	SELECT 
		id, nextval('order_id_seq') as correct_order_id
	FROM
		users
  	ORDER BY 
		id ASC
	) as sorted_ids
WHERE
	users.id = sorted_ids.id; 

select * from users order by order_id;

Jak widać dane zostały pięknie zorderowane:

psql=> select * from users order by order_id;
 id |   name    |          created           | order_id
----+-----------+----------------------------+----------
  1 | Dalia     | 2009-12-19 10:41:49.297223 |        1
  3 | Agnieszka | 2009-12-19 10:41:49.324851 |        2
  4 | Dominika  | 2009-12-19 10:41:49.958792 |        3
(3 rows)

Przy okazji wspomnę, że w aplikacji łatwiej obsłużyć ordering odwrotny, tzn. wiersze, które posiadają największą wartość order_id są na czele a nie na końcu listy. Przy takim podejściu przy wstawianiu nowego rekordu pole order_id powinno mieć wartość MAX(order_id) + 1. Dla orderingu odwrotnego należy zmienić w podzapytaniu kolejność sortowania z id ASC na id DESC.

Należy także dbać o to, aby przy usunięciu rekordu prenumerować order_id wszystkich rekordów, które znajdują się ‚nad nim’ o -1.

Relecyjna baza ‘ala MySQL’ w chmurze Amazon AWS

Amazon w ramach AWS (Amazon Web Services) uruchomił publiczną wersję beta usługi relacyjnaj bazy danych ‚ala MySQL’ (Amazon RDS) w swojej chmurze.

Amazon RDS ma cechować się:

  • prostotą konfiguracji i wdrożenia do aplikacji,
  • pełną kompatybilnością z bazą danych MySQL,
  • prostotą w zarządzaniu bazami, backupami i dostępnymi narzędziami,
  • pełną automatyką w backup’owaniu i czynnościach serwisowych,
  • skalowalnością w zależności od potrzeb uzytkownika
  • niezawodnością
  • bardzo dostępną ceną, tak jak w przypadku innych usług developerzy kasowani będą jedynie za zaosby, które rzeczywiście zużywają ich aplikacje.

Czy rzeczywiście tak będzie? Mam nadzieje. Przeczytaj więcej o Amazon RDS.

Usunięcie nieużywanych tagów z bazy WordPress’a

Czasami zachodzi potrzeba „ręcznego” kasowania postów z WordPress’a, jako że system ten działa na MySQL MyISAM to nie wspiera kaskadowego kasowania zależnych danych.

Skasowanie postów jest stosunkowo proste:

DELETE FROM wp_posts WHERE conditions;

Trudniejsza sprawa jest ze skasowaniem tagów. Na necie znalazłem poniższe zapytanie, działa wyśmielicie:

DELETE a,b,c
FROM
	wp_terms AS a
	LEFT JOIN wp_term_taxonomy AS c ON a.term_id = c.term_id
	LEFT JOIN wp_term_relationships AS b ON b.term_taxonomy_id = c.term_taxonomy_id
WHERE (
	c.taxonomy = 'post_tag' AND
	c.count = 0
	);

Czasami jednak pole „count” w relacji „wp_term_taxonomy” zawiera niepoprawne dane (liczbę większą od 0), wtedy nieużywane tagi musimy zidentyfikować poprzez LEFT JOINa z warunkiem ID IS NULL. Poniżej zapytanie wyświetlające nieużywane tagi.

SELECT DISTINCT wp_terms.slug FROM wp_terms wt
	INNER JOIN wp_term_taxonomy wtt ON wt.term_id=wtt.term_id
	INNER JOIN wp_term_relationships wtr ON wtr.term_taxonomy_id=wtt.term_taxonomy_id
	LEFT JOIN wp_posts wp ON wp.ID=wtr.object_id
WHERE
	taxonomy='post_tag'
AND 
	ID IS NULL
AND 
	NOT EXISTS(SELECT * FROM wp_terms wt2
                INNER JOIN wp_term_taxonomy wtt2 ON wt2.term_id=wtt2.term_id WHERE wtt2.parent=wt.term_id)
ORDER BY name

Zrzut danych z bazy do pliku w MySQL

Metoda I

Zapytanie z poziomu bazy danych.

mysql> SELECT *
    -> INTO OUTFILE 'c:/data.csv'
    -> FIELDS TERMINATED BY ','
    -> ENCLOSED BY '"'
    -> ESCAPED BY '\\'
    -> LINES TERMINATED BY '\r\n'
    -> FROM table_to_export;
Query OK, 20 rows affected (0.02 sec)

Metoda II

Zapytanie z poziomu konsoli bez logowania się do bazy danych.

mysql -u user -h host -p --quick -e 'SELECT * FROM table_to_export' baza > data.txt

Warto pamiętać, że w metodzie I plik zapisywany jest po stronie serwera mySQL a w metodzie II po stronie klienta mySQL. Zatem gdy łączymy się z bazą danych z innego serwera niż wykonujemy zapytanie to należy użyć metody II.

Edycja danych ‘inline’ dzięki Jeditable i jQuery

Jeditable to bardzo fajny plugin do jQuery dzięki któremu można stworzyć mega szybką i prostą edycję danych bez przeładowania. Działa to tak, że np. blok tekstowy objęty odpowiednim <div> po kliknięciu zamienia się w <textarea>, następnie tekst w nim zawarty można edytować i zapisać.

Instalacja i korzystanie z Jeditable jest banalne. Trzeba zaincludować bibliotekę jQuery, plugina Jeditable oraz nałożyć odpowiednią klasę na edytowalny tekst i to wszystko. Aby zmienione dane zapisywały się oczywiście trzeba odpowiednio zaprogramować back-end.

Przejdź na stronę Jeditable oraz zobacz podstawowe przykłady i zaawansowane przykłady.

Wyrażenia regularne unicode

Problem

Mamy formularz z polami, które musimy zwalidować pod kątem poprawności danych. Pole może zawierać jedynie litery (duże, małe – wszystko jedno).

Jakim wyrażeniem regualarnym realizujemy sprawdzanie? Pierwsza myśl to [a-zA-Z]… niestety walidacja nie zadziała poprawnie, gdyż w zakres [a-z] uwzględnia jedynie 26 liter alfabetu łacińskiego natomiast nie uwzględnia znaków diakrytycznych czyli litery [ą, ć, ę, ł, ń, ó, ś, ź, ż] nie spełnią kryterium walidacji.

Zatem aby walidacja działała poprawnie trzeba by dodać do zbioru [a-zA-Z] litery ze znakami diakrytycznymi. Otrzymujemy zatem wyrażenie: [a-zA-ZąćęłńóśźżĄĆĘŁŃÓŚŹŻ]. Wyrażenie to zadziała poprawnie, jednak jest narażone na potencjalne błędy, łatwo zapomieć o którejś literze lub zrobić literówkę. W przypadku gdy tworzymy aplikacje multijęzykową czynność tą będziemy musieli powtórzyć dla każdego z obsługiwanych języków.

Poprawne rozwiązanie

W programowaniu jak już coś sie robi to należy zrobić to porządnie, tak aby swojego kodu nie trzeba było poprawiać, modyfikować etc…

Z pomocą przychodzi nam kodowanie UNICODE, w które umożliwia napisać reguły na litery posiadające znaki diakrytyczne. Wyrażenie \p{L} oznacza jakąkolwiek literę w jakimkolwiek języku, może by być: Ł, ź, ü, ß czy cookolwiek co jest literą (także nie łacińską). Zatem nasze wyrażenie walidujące pole zawierające włącznie litery będzie wyglądać następująco:

preg_match('#^\pL+$#', 'MałyŁoß');

Gwoli wyjaśnienia \pL to skrót od \p{L} a \p{L} oznacza znak (code point) unicode \p należący do kategorii liter {L}.

Klasy/kategorie znaków w unicode:

\p{L} – wszystkie litery
\p{M} – wszystkie znaki, które samotnie nie występują, musi być połączony z innym znakiem i składa się na np. akcent, umlaut, etc…
\p{Z} – wszystkie znaki niewidoczne
\p{S} – wszystkie symbole, znaki walut, znaki matematyczne
\p{N} – wszystkie znaki numeryczne
\p{P} – wszystkie znaki interpunkcyjne: przecinki, średniki etc…
\p{C} – wszystkie niewidoczne znaki kontrolne i niewykorzystywane znaki code point

Przeczytaj więcej o właściwościach wyrażeń regualrnych w unicode.

Aktualny czas a transakcja w PostgreSQL

Ostatnio miałem ciekawy case’ik – musiałem w obrębie jednej transakcji zmienić dane rekordów. Wszystko odbywało się w kilku funkcjach plpgsql, funkcje mogły się wywoływać rekurencyjnie w triggerach a zmiany dotyczyły między innymi pól typu TIMESTAMP. Wartości pól TIMESTAMP rekordów były zmieniane i ich zmiany automatycznie wpływały na w działanie skryptu.

Jakież było moje zdziwienie gdy skrypt nie chciał działać, a wszystkie rekordy miały taką zamą wartość pola typu TIMESTAMP. Otóż okazało się, że po rozpoczęciu transakcji funkcje zwracające aktualny czas:

SELECT CURRENT_TIME;
SELECT CURRENT_TIMESTAMP;
SELECT NOW();

przestały zwracać aktualny czas a zamiast tego czas rozpoczęcia transakcji.

I o dziwo jest to rzeczywiście poprawne działanie. Na stronie http://www.postgresql.org/docs/8.3/static/functions-datetime.html można przeczytać:

Since these functions return the start time of the current transaction, their values do not change during the transaction. This is considered a feature: the intent is to allow a single transaction to have a consistent notion of the „current” time, so that multiple modifications within the same transaction bear the same time stamp.

Zatem wyjściem z tego problemu jest użycie postgres’owej funkcji timeofday() i zrzutowanie jej wyniku na TIMESTAMP, realizyje to zapytanie:

SELECT cast( timeofday() AS timestamp);

Edit: zamiast timeofday() można uzyć funkcji clock_timestamp(), która zwraca date w postaci TIMESTAMP’a

SELECT clock_timestamp();

Dla ciekawości sprawdziłem jak zachowują się inne dialekty SQL i okazało się, że zarówno MySQL jak i MSSQL realizują tą sytuację odmniennie niż PostgreSQL, zatem:

  • MySQL – w transakcji zwracany jest bieżący czas (nie czas rozpoczęcia transakcji)
  • MSSQL – w transakcji zwracany jest bieżący czas (nie czas rozpoczęcia transakcji)
  • PgSQL – w transakcji zwracany jest czas rozpoczęcia transakcji

Sztuczki w wordpress’ie: przeciążanie standardowych funkcji dostępnych w szablonie

Gdy programujemy w szablonie skórki WordPress’a możemy korzystać z całej masy funkcji dostępnych w engine WordPress’a. Niektóre z nich zwracają wartości, inne od razu drukują na ekran, zwykle są parametryzowane i możliwość konfiguracji jest wystarczająco duża.

Problem

Niestety z czasem zawsze przychodzi pewne ‚ale’… chcielibyśmy aby standardowa funkcja wordpressa działała minimalnie inaczej. Zatem musimy zmodyfikować jej kod… ale stop nie możemy tak bezczelnie nadpisywać funkcji wordpress.Takie hamskie haki są niedopuszczalne z kilku powodów:

  • Utrudniamy przyszłe aktualizacje, po każdej aktualizacji będziemy musieli pamiętać aby w pliku XXX w linii YYY wstawić swojego hacka.
  • Ta sama funkcja może być wywoływana w innym pliku szablonu, może to powodować błędne/niechciane działanie. Pozatym gdy zmienimy skórkę na inną to hack pozostanie dalej mimo, że już go nie będziemy potrzebować
  • Hack’owanie kodu jakichkolwiek bibliotek/frameworków czy takich gotowych kombajnów jak wordpress jest sprzeczne z zasadami programowania.

Zatem jak sobie z tym problemem poradzić?

Wszelkie gotowe rozwiązania powinno się rozszerzać nie modyfikując przy tym źródeł samej głównej aplikacji. Jeżeli takie rozszerzenie jest nie możliwe to oznacza, że aplikacja została źle napisana i należy poszukać innej rozszerzalnej.

Czy rozszeżać funkcje w WordPress?

Oczywiście. Posłużymy się w tym celu trochę zapomnianym plikiem szablonów: functions.php. Jeżeli plik functions.php nie istnieje w katalogu głównym naszej skórki to go tworzymy. Plik ten jest automatycznie ładowany wraz z uruchomieniem WordPress’a, można w nim umieszczać swoje dedykowane dla skórki funkcje oraz jak w naszym przypadku funkcje speudo przeciążające.

Zwykle w szablonach nie ma tego pliku, także świadomość programistów wordpress’owych na temat jego jest niewielka. Zatem radze sobie zapamiętać o takiej możliwości!

Dobra, a więc załóżmy, że chcemy zmodyfikować działanie funkcji the_content_rss. Tworzymy zatem w pliku functions.php funkcję my_the_content_rss.

function my_the_content_rss($more_link_text='(more...)', $stripteaser=0, $more_file='', $cut = 0, $encode_html = 0) {
	global $id;

	ob_start();
	the_content_rss('', $stripteaser, $more_file, $cut, $encode_html);
	$bufferContent = ob_get_contents();
	ob_end_clean();

	$bufferContent = preg_replace( '/\.\.\.\s*$/', '', $bufferContent );
	$bufferContent .=  '&lt;span class="read-on"&gt;&lt;a href="'. get_permalink() . "#more-$id\" class=\"more-link\"&gt;$more_link_text&lt;/a&gt;&lt;/span&gt;";
	
	print $bufferContent;
}

Funkcja my_the_content_rss musi przyjmować co najmniej takie parametry parametry jak oryginalna funkcja the_content_rss. Wywołuje oryginalną funkcję, jako że the_content_rss nie zwraca wartości tylko drukuję ją na ekran musimy zatem poprzez ob_start() włączyć buforowanie, od tej pory wszystkie dane, które miały być drukowane są zapisywane w buforze, następnie poprzez ob_get_contents() odczytujemy ten bufor i kończymy buforowanie ob_end_clean().

Teraz mając w zmiennej $bufferContent wynik działania oryginalnej funkcji możemygo dostosować do naszych indywidualnych wymagań w przykładzie jest to wycięcie „…” oraz wstawienie linka do szczegółów posta.

Tyle. Następnie w szablonie w miejscach, w których potrzebujemy niestandardowy wygląd/dane szablonu wywołujemy zamiast the_content_rss nowo stworzoną funkcję my_the_content_rss.