Html page done - client want a news section - what todo?

Let them use twitter or facebook to update their news and just pull in that news to the sight. I don't think there is much code to be done here and it's fairly secure.

 

You could always setup a SQL database, and have a couple php pages to login/edit records. Pending how dynamically he wants the pages this would simplify things. Then pull the information from newest to oldest on the php page, limiting results.

 

Why do you think that wordpress is 100% hacker friendly? I have years with wordpress and nothing happend..

 

Experience, common sense, the most abysmal messy code I have ever seen in my life, idiots who know nothing about security making themes, plugins, widgets..etc, I could go on but I'm getting a migraine.
Read post#19, that pretty much sums it up.

 

First rule of security: DON'T TELL ANYONE HOW YOU ARE DOING THINGS ON THE SERVER
If you use WP or any other off the shelf "solution" then you are using common code that is available to anyone who wants to download it. That makes it a big juicy target for every idiot, crook, and ahole. As soon as one of them finds a hole they post the exploit on hacker sites, and every other site using the same trash becomes a target as all the script kiddies engage in a feeding fenzy trying to find sites with the same piece of junk.

Hacking is dumb; creating trash code and making it available for others to use is dumber; using third party junk because it is "easy" is the dumbest.

 

Can't be that many years, either that or you're sites are so minor nobody bothers with them.

http://pwnies.com/archive/2008/winners/#mass0wnage
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress

ZERO internal security as it's "one ring" protection, you break through that outer ring, the whole system is garbage; and with SO many entry vectors, connection data in the global scope or worse, undeletable global scope (define), the mere notion of the word "security" in the same sentence as "wordpress" should only be used with a negative connotation. You add in the garbage markup it shoves down your throat that the template system doesn't let you change , idiotic amounts of JS for nothing -- and now the endless halfwit off the shelf templates that crap all over sites with bloat like jQueery and Bootcrap... It's shocking anyone with more than two brain cells to rub together would use it by choice! The underlying system is trash, you start adding plugins/mods/extensions/whateverTheyWantToCallThemThisWeek and of COURSE you're going to get pwned.

Anyone using it for anything more than a crappy little personal blog is basically tucking the sawed off shotgun under their chin with their finger on the trigger in the back of a pickup truck with blown shocks going down a bumpy road, and doesn't know enough about web technologies to be running a 'real' website in the first damned place.

You sleaze together a bunch of crappy off the shelf solutions, you get what's coming to you!

Though I disagree with @COBOLdinosaur about the not sharing the code, the trick is to use good practices to isolate what can be done and from where. Named queries, prepared queries, restricting scope of the database connection handle, restricting the scope of the connection info and destroying it once used, restricting where and what can even call that info in the first place, distrusting ALL user input, one index to rule them all so there's only ever a single valid entry vector, separation of data handling from other functionality, using native PHP instead of some goofy templating system (since PHP is a templating system), etc, etc...

Though around two thirds of what I just rattled off is probably unfamiliar to the majority of people crapping out PHP; in the same way two-thirds the tags in HTML are unfamiliar to the people who crap out HTML these days...

But then, I'm probably one of the few dev's crazy enough to do this:

<?php

define('SQLTYPE', 'mysql');

function dbSettings() {
	dbSecurityCheck();
	return [ 
		// begin user edits
		
		'dsn' => SQLTYPE . ':dbname=test;host=localhost',
		'username' => 'jake',
		'password' => '******',
		'tablePrefix' => 'paladin_',
		
		// set to false to prevent installer from running
		'installerPassword' => 'asdfasdfasdf', 
		
		'pwSalt' => 'pxd1138',
		'pwAlgo' => 'SHA256'
		
		// do not edit past this point
		
	];
}

function dbSecurityCheck() {
	if (!defined('dbSettingsSent')) {
		define('dbSettingsSent', 1);
		if (
			(count($d = debug_backtrace()) == 3) &&
			isset($d[2]) &&
			($d[2]['function'] == 'main') && 
			(str_replace(
				'/dbSettings.php',
				'/index.php',
				str_replace('\\', '/', $d[0]['file'])
			) == str_replace('\\', '/', $d[2]['file']))
		) return true;
	}
	die('Hacking attempt detected for dbSettings.php!');
}

?>

Code (markup):

Which prevents being able to pull the login name/pw/dsn or other security info from anywhere except the main() function inside the index.php in the same directory as that file. Restricted scope, and I only pass it to classes/functions that NEED it.

But then, I do **** like this too:

function safeInclude($file) { include($file); }

Code (markup):

Just so I can BREAK scope when including files.

But then, I have a laundry list of "improvements" that should be made to PHP that would piss off normal PHP devs... like not allowing include/require to actually include/require files that don't have a .php extension. Like not allowing readfile or the normal file access functions to load any file with a .php extension. Like not having include/require actually pass the scope from which they are called; or for that matter allow them to contain anything other than functions... swing an axe at the heredoc/nowdoc bull as well as removing <?php ?> from the specification entirely so the ONLY options for output are echo or print.... Hell, I'd probably axe double quote strings while at it.

PHP is "insecure by design" -- axing the mysql_ functions was a START, but really there's a lot of "easy" in it that also pisses on security. Sadly systems like turdpress don't even seem to bother practicing even the simplest of two or three decade old methods for securing interpreted languages.

Like NEVER allow a library file to output ANYTHING if called directly, like NEVER put any secure data in global scope, like destroy security info as soon as you are done using it...

The first of which PHP makes it WAY too easy to do.

 

try www.objengine.com

admin: http://bookingcentar.com/cms/objengine/admin.php?userid=cms.sa
pass: tim
Admin user can define custom object, regular user can add/update/delete data,
JSON output for "ExampleObject": http://bookingcentar.com/cms/objengine/ajax.php?objectname=ExampleObject&limit=2
HTML output: http://bookingcentar.com/cms/test1.php
Source of test1.php page: http://bookingcentar.com/cms/test1.txt