Slashdot Mirror

Theres a plugin for that. :) https://wordpress.org/plugins/... I think this one actually records a video of the user interactions.

Do you have a source for WordPress claiming copyright ownership of all themes? I've used WordPress quite extensively and have never heard of this.

https://wordpress.org/news/200... "One sentence summary: PHP in WordPress themes must be GPL, artwork and CSS may be but are not required." The only way someone can set conditions on the work you're working with is if they have some sort of copyright claim on it. If you fork a WordPress theme, then they have such a claim and can say "Derivatives must be GPL as a condition of redistribution". They still claim this even if you wrote a theme from scratch.

They're protecting their users. Suppose WordPress kept using ReactJS and I used WordPress. Now, I decide to sue Facebook for violating some patent of mine. Due to Facebook's licensing, I'd lose my license to use ReactJS and, thus, wouldn't be able to use WordPress. All WordPress-based sites of mine would immediately need to come down lest Facebook sue me back. It's a method of suppressing patent infringement lawsuits. By WordPress switching from ReactJS to an alternative, they protect their users from this.

If you believe software patents are bullshit (as I do) and you release everything as prior art, then what Facebook is doing can literally never impact you.

The kinds of people this will impact are companies who love patents and regularly file lawsuits about infringement - it would hinder them from doing so.

So I don't really see the problem.

It's not fair to WordPress to conflate a WordPress plugin with WordPress itself

The difference between Wordpress and other CMSes (like Drupal) is that their official repo has repeatedly served malware.

The WordPress Codex tells coders how to sanitize user input, but the NextGEN coders seemed to forget the parameterized URL is user input.

In my experience, the answer is "custom code and plugins". If you're running a bog standard Wordpress install with Akismet, FormNinja, Gallery, and a handful of the other top-20 plugins, auto-update is just fine and won't bother you at all. If you have a lot of custom layout code, or specialized plugins that are mission critical but not regularly updated, updating Wordpress can break them, thus breaking the website. Yes, it's stupid. Yes, this situation should not be the case. However, you asked thy people don't enable auto-update. That would, in fact, be why.

As an aside, shameless plug for the super awesome Shield Plugin. It's free, and when properly configured, can prevent nearly all of the major forms of automated attack. I've also used iQ Block Country to nix traffic from most of the usual purveyors of such attacks. Not a dev or an investor, just a super happy user of both.

Now, to go one further, Slashdot seems to be back-and-forth regarding mandatory auto-updating. Wordpress has a flaw, and the response is, "why isn't auto-update just how the thing works?". Microsoft implements this with Windows 10, and the response is, "How dare they tell me when I have to update!". Which is it?

In my experience, the answer is "custom code and plugins". If you're running a bog standard Wordpress install with Akismet, FormNinja, Gallery, and a handful of the other top-20 plugins, auto-update is just fine and won't bother you at all. If you have a lot of custom layout code, or specialized plugins that are mission critical but not regularly updated, updating Wordpress can break them, thus breaking the website. Yes, it's stupid. Yes, this situation should not be the case. However, you asked thy people don't enable auto-update. That would, in fact, be why.

As an aside, shameless plug for the super awesome Shield Plugin. It's free, and when properly configured, can prevent nearly all of the major forms of automated attack. I've also used iQ Block Country to nix traffic from most of the usual purveyors of such attacks. Not a dev or an investor, just a super happy user of both.

Now, to go one further, Slashdot seems to be back-and-forth regarding mandatory auto-updating. Wordpress has a flaw, and the response is, "why isn't auto-update just how the thing works?". Microsoft implements this with Windows 10, and the response is, "How dare they tell me when I have to update!". Which is it?

I'd be very interested to find out why these 1.5m sites did not automatically update.

They're probably professional sites that businesses depend on for a revenue stream. Believe it or not, some businesses do depend on WordPress as their CMS. Those businesses have probably learned to disable the auto-updates.

I'm not against using WordPress, certainly not like some other posters here. But I am against allowing WordPress auto-updates. Before any updates are deployed, you need test whether the new version renders your site the same way as before.

WordPress has a history of changing core functionality in a way that breaks major features, and they've been known to introduce entirely new attack surfaces without the ability to turn them off. That last one, by the way, led to a situation which may seem familiar.

Do NOT allow your site to be updated at the whims of the WordPress development team. Their track record does not inspire confidence.

I'd be very interested to find out why these 1.5m sites did not automatically update.

They're probably professional sites that businesses depend on for a revenue stream. Believe it or not, some businesses do depend on WordPress as their CMS. Those businesses have probably learned to disable the auto-updates.

I'm not against using WordPress, certainly not like some other posters here. But I am against allowing WordPress auto-updates. Before any updates are deployed, you need test whether the new version renders your site the same way as before.

WordPress has a history of changing core functionality in a way that breaks major features, and they've been known to introduce entirely new attack surfaces without the ability to turn them off. That last one, by the way, led to a situation which may seem familiar.

Do NOT allow your site to be updated at the whims of the WordPress development team. Their track record does not inspire confidence.

WP itself is not affected, they say. Plugins and themes of course are the wild card, if they email without using the WP wrappers. https://core.trac.wordpress.or...

Unless I'm mis-reading your post, you've brought up three different issues:

a) What is the best way to update a PHP script?
b) How do Wordpress and Drupal update by default?
c) How do you update the PHP interpreter without breaking scripts?

> a) What is the best way to update a PHP script?

Probably the best way is to use a revision control system such as "git", "cvs", "svn", or "hg". You can look at the Wordpress SVN here:

https://core.trac.wordpress.or...

The system tracks all changes:
https://core.trac.wordpress.or...

On an up-to-date server, you can run "svn update" to retrieve all of the updates that you're missing. An an older system, you can pull only the specific changes you want, such as security patches:
https://core.trac.wordpress.or...

b) How do Wordpress and Drupal update by default?

In a stupid way. The script itself downloads the new version from the Wordpress web site. For this to work, the script (and therefore all scripts on the server) needs to have permission to overwrite files on the server. That's bad because in most cases that means *any* script can change *any* file on the site. Any little security hole in any script allows the bad guy to write whatever he wants, including his own software, and run it on your server. That's a bad idea. It's *possible* to set this up to be reasonably secure, but nobody does. PHP makes the more secure configuration much more difficult than it needs to be.

> c) How do you update the PHP interpreter without breaking scripts?

Most of the time, a function will be deprecated several years before it's removed or disabled by default. Use http://php.net/manual/ to understand the PHP you're writing rather than copying and pasting shit from Stackoverflow that might have been halfway correct six years ago. The manual will let you know if a function is deprecated, and point to the newer approach you should use instead. Aside from using good documentation (not forums) as your primary learning tool and avoiding deprecated functions, you can make your software easier to update and fix later. That's mostly about modularity - keep unrelated things separate. Ideally each function you write would be no longer than about 4-12 lines. A simple, short function is easier to update later. Related functions can be group into classes ( http://php.net/manual/en/langu... ). It's much easier to fix your file uploader if it's all together in a file called "fileuploader.php" rather than being sprayed through "mega_forum_script.php" (8MB).

> *super novice programmer here* ... PHP

You have a much harder road ahead of you than us oldtimers who learned in the 1980s and 1990s. Your newbie code will be exposed in the internet, where it'll be attacked several times per hour. That's very high risk. Minimize your exposure by trying to avoid working with confidential data for now. Recognize your limitations and don't try to write a security system or shopping cart with credit card payments right now. When you *do* have to work on something that could cause damage when attacked, consider asking a programmer who is trained in security to do code review. (I've been programming professionally for 20 years, mostly doing security-related code, and I still ask my peers to review my work - there's no shame in that.)

Unless I'm mis-reading your post, you've brought up three different issues:

a) What is the best way to update a PHP script?
b) How do Wordpress and Drupal update by default?
c) How do you update the PHP interpreter without breaking scripts?

> a) What is the best way to update a PHP script?

Probably the best way is to use a revision control system such as "git", "cvs", "svn", or "hg". You can look at the Wordpress SVN here:

https://core.trac.wordpress.or...

The system tracks all changes:
https://core.trac.wordpress.or...

On an up-to-date server, you can run "svn update" to retrieve all of the updates that you're missing. An an older system, you can pull only the specific changes you want, such as security patches:
https://core.trac.wordpress.or...

b) How do Wordpress and Drupal update by default?

In a stupid way. The script itself downloads the new version from the Wordpress web site. For this to work, the script (and therefore all scripts on the server) needs to have permission to overwrite files on the server. That's bad because in most cases that means *any* script can change *any* file on the site. Any little security hole in any script allows the bad guy to write whatever he wants, including his own software, and run it on your server. That's a bad idea. It's *possible* to set this up to be reasonably secure, but nobody does. PHP makes the more secure configuration much more difficult than it needs to be.

> c) How do you update the PHP interpreter without breaking scripts?

Most of the time, a function will be deprecated several years before it's removed or disabled by default. Use http://php.net/manual/ to understand the PHP you're writing rather than copying and pasting shit from Stackoverflow that might have been halfway correct six years ago. The manual will let you know if a function is deprecated, and point to the newer approach you should use instead. Aside from using good documentation (not forums) as your primary learning tool and avoiding deprecated functions, you can make your software easier to update and fix later. That's mostly about modularity - keep unrelated things separate. Ideally each function you write would be no longer than about 4-12 lines. A simple, short function is easier to update later. Related functions can be group into classes ( http://php.net/manual/en/langu... ). It's much easier to fix your file uploader if it's all together in a file called "fileuploader.php" rather than being sprayed through "mega_forum_script.php" (8MB).

> *super novice programmer here* ... PHP

You have a much harder road ahead of you than us oldtimers who learned in the 1980s and 1990s. Your newbie code will be exposed in the internet, where it'll be attacked several times per hour. That's very high risk. Minimize your exposure by trying to avoid working with confidential data for now. Recognize your limitations and don't try to write a security system or shopping cart with credit card payments right now. When you *do* have to work on something that could cause damage when attacked, consider asking a programmer who is trained in security to do code review. (I've been programming professionally for 20 years, mostly doing security-related code, and I still ask my peers to review my work - there's no shame in that.)

Unless I'm mis-reading your post, you've brought up three different issues:

a) What is the best way to update a PHP script?
b) How do Wordpress and Drupal update by default?
c) How do you update the PHP interpreter without breaking scripts?

> a) What is the best way to update a PHP script?

Probably the best way is to use a revision control system such as "git", "cvs", "svn", or "hg". You can look at the Wordpress SVN here:

https://core.trac.wordpress.or...

The system tracks all changes:
https://core.trac.wordpress.or...

On an up-to-date server, you can run "svn update" to retrieve all of the updates that you're missing. An an older system, you can pull only the specific changes you want, such as security patches:
https://core.trac.wordpress.or...

b) How do Wordpress and Drupal update by default?

In a stupid way. The script itself downloads the new version from the Wordpress web site. For this to work, the script (and therefore all scripts on the server) needs to have permission to overwrite files on the server. That's bad because in most cases that means *any* script can change *any* file on the site. Any little security hole in any script allows the bad guy to write whatever he wants, including his own software, and run it on your server. That's a bad idea. It's *possible* to set this up to be reasonably secure, but nobody does. PHP makes the more secure configuration much more difficult than it needs to be.

> c) How do you update the PHP interpreter without breaking scripts?

Most of the time, a function will be deprecated several years before it's removed or disabled by default. Use http://php.net/manual/ to understand the PHP you're writing rather than copying and pasting shit from Stackoverflow that might have been halfway correct six years ago. The manual will let you know if a function is deprecated, and point to the newer approach you should use instead. Aside from using good documentation (not forums) as your primary learning tool and avoiding deprecated functions, you can make your software easier to update and fix later. That's mostly about modularity - keep unrelated things separate. Ideally each function you write would be no longer than about 4-12 lines. A simple, short function is easier to update later. Related functions can be group into classes ( http://php.net/manual/en/langu... ). It's much easier to fix your file uploader if it's all together in a file called "fileuploader.php" rather than being sprayed through "mega_forum_script.php" (8MB).

> *super novice programmer here* ... PHP

You have a much harder road ahead of you than us oldtimers who learned in the 1980s and 1990s. Your newbie code will be exposed in the internet, where it'll be attacked several times per hour. That's very high risk. Minimize your exposure by trying to avoid working with confidential data for now. Recognize your limitations and don't try to write a security system or shopping cart with credit card payments right now. When you *do* have to work on something that could cause damage when attacked, consider asking a programmer who is trained in security to do code review. (I've been programming professionally for 20 years, mostly doing security-related code, and I still ask my peers to review my work - there's no shame in that.)

I've got a web designer friend who prefers Joomla, in large part because it works similarly to the design tools he's used to...though he fully admits that it has a much bigger learning curve than others.

My personal blog is run on WordPress. This is, in large part, because it's a blog and intended to be one. I like the fact that there's a mobile app for quick uploads and microblogging. I've never had to write a line of code to make anything work. I use a few plugins to make it work, namely The Shield and IQ Block Country to make my blog much more secure.

I'm not a web designer, and I don't claim to be. I just want to blog. Wordpress helps me do that much better than the other CMS's I tried - Ametys, Concrete5, Silverstripe, and at least one other one whose name escapes me. There were always drawbacks to the others - theme availability, responsive/mobile layout compatibility, media management, or something else - Ametys requires Tomcat, which required a special hosting account (I tried both Arvixe and HostISO, both became a world of regret), and even in a sandboxed environment, lots of things were much more complicated than they should be.

I'm certain the Slashdot groupthink goes against Wordpress, and there are legitimate reasons why - PHP and security spring to mind. Even so, I've been hack free, and it's allowed me to focus on content, rather than implementation.

The number of CVEs assigned to Wordpress + plugins vs Plone + addons is a very misleading metric for making this type of claim.

https://wordpress.org/plugins/ shows 45,129 Wordpress plugins.

https://pypi.python.org/pypi?:... shows 3242 Plone addons.

If you assume rough parity in terms of line of code between a Plone addon and a Wordpress plugin (a dangerous assumption), 10x more Wordpress related CVEs would indicate that Wordpress has a lower density of CVEs per LOC than Plone does.

But, of course, even that comparison is a misleading one to make. There are too many other factors that skew these numbers to draw any meaningful conclusions from them. CVEs simply weren't intended to be used for this kind of comparison.

Hello,

I am Wayne the designer of the Wordpress Slidingdor theme and you are recieving this email because you have at some time signed up for support at the Slidingdoor support page.

The latest WordPress 4.4 update broke the SlidingDoor theme.

It may be that you are no longer using the Slidingdoor wordpress theme, in which case you can disregard the rest of this email.

But if you are using the Slidingdoor theme, it's better that you find this out before your website crashes.

This is an urgent issue, and this is a one-off email.

If you upgrade to WordPress 4.4 before you upgrade to the latest Slidingdoor theme then the Wordpress update will break the SlidingDoor theme and your website will go blank.

There is a simple fix: I have released an update to the slidingdoor theme which is available for download at wordpress.org.

https://wordpress.org/themes/s...

Just click on 'download' or from within your wordpress installation just go to Appearance, Themes, and Update.

You need to upgrade the sliding door theme BEFORE you upgrade to WordPress 4.4.

Some people may have already upgraded to Wordpress 4.4 and if you have an old version of Slidigndoor you may now have a blank screen.

If this has happened, the way to fix it is to FTP into your site and upload the new updated theme by hand OR log in directly to the wordpress admin page.

You should have renamed Admin when you created the site. You should never have a test ID. And you should have https://wordpress.org/plugins/... to spam you in times like these...

Actually, yes, they are issues. Responsive images in WordPress have always required kludges that hook into the core. Responsive oEmbeds are worse: you had to hook into embed_oembed_html and use regular expressions to modify the iframe markup (or use javascript to modify them after page load, also less than ideal). These kludges are inherently fragile and almost always cause problems with third party plugins. Now it is part of the core and just works.

Besides, if you look beyond the marketing speak, there are a lot of improvements that make it easier to run big sites. Things like taxonomy metadata (finally!) and the WP_Network object, which makes it much easier to run multisite installations (or multilingual installations using the most popular method for achieving this).

I make my living by running a couple of large WordPress sites, and this release makes me as happy as a pig in shit.

Actually, yes, they are issues. Responsive images in WordPress have always required kludges that hook into the core. Responsive oEmbeds are worse: you had to hook into embed_oembed_html and use regular expressions to modify the iframe markup (or use javascript to modify them after page load, also less than ideal). These kludges are inherently fragile and almost always cause problems with third party plugins. Now it is part of the core and just works.

Besides, if you look beyond the marketing speak, there are a lot of improvements that make it easier to run big sites. Things like taxonomy metadata (finally!) and the WP_Network object, which makes it much easier to run multisite installations (or multilingual installations using the most popular method for achieving this).

I make my living by running a couple of large WordPress sites, and this release makes me as happy as a pig in shit.

WordPress is good.

Ok, stop laughing and hear me out.

We all know that with all the shitty web-cmses out there, the ones built on LAMP (PHP) are the oldest that actually have a finished and working feature set.
Show me one non-PHP CMS with the featureset of WP, Joomla, Drupal, EZ Publish or Typo 3, closed source or FOSS. You won't find any.
PHP and the CMSes built with it are at least ten years ahead of the game in the market they were built for - that's a simple fact that no one can deny.
And of those, the mess called WP is actually the best that fits every mold.

- It's primarly a blogging engine - which is what most people want and need anyway.
- It takes about 3 clicks and ten seconds to move it away from the blogging perspective to a regular web CMS.
- It's dead simple to install.
- It uses the hook model (also found in Drupal) to implement features that can be applied flexibly. And while that principle is questionable at best - especially from a performance standpoint - there is no doubt that it is *very* easy to use to implement custom features and setups.
- The documentation actually exisits and is pretty good.
- The community is massive. It's basically an army of tinkerers fiddling away at extensions and plugins.
- It has an official full blown mobile management app downloadable for free.
- It has a large, semi-post-capitalistic hip company baking it and it's development. (They all work remote, from around the planet and put their money where their mouths are.)
- There are popular WP plugins built by people who can't programm - but they work (sort of) and are installed/activated/deactivated/uninstalled within seconds.
- The architecture is a bizar convoluted shoddy mess. But you can start tinkering with it within minutes and won't feel bad about it - because, hey, guess what, it's a mess already.
- Modifying templates and themes in a non-destuctive update-safe manner is dead simple. ... and so forth ...

In an nutshell:
WordPress is PHPs philosophy carried 1on1 into the application/CMS layer.
That is why it's so successful.
And rightfully so.

Agreed. I use a plugin called Apocalypse Meow to do this, but there are a dozen others that can do the same. It's not a perfect solution (attackers can come at you from thousands of compromised computers under their control), but the more speed bumps you place in a potential hacker's way, the more likely he is to decide to skip your site and focus on an easier target. (It's the security equivalent of not needing to run faster than a bear, just faster than other people who are running away from the bear.)

If you are using a well know framework for your site there might already be support for comment spam management. It's not always free as some of them are basically interfaces for a paid service but it may still be worth a look. They would block comment spam in general instead of focusing on comments from a specific set of nodes.

https://www.drupal.org/node/20...
http://wordpress.org/plugins/s...

Here you go

There's an extension to the <link rel> tag that overloads it by, instead of linking to actual related data (as the tag was intended to do), treats the target of the link as defining a schema / data format, when rel="profile". The URL is then essentially a globally unique key for the data format; parsers that recognize the format will see the key and know how to parse some other information on the page. gmpg.org is the host of one of the early ones, XFN, which is linked in default Wordpress installs.

I've found quite a few plugins to help secure WordPress. One of the ones I really like is Apocalypse Meow. This locks people out from even trying to log into your site after X attempts. (You define what X is but it defaults to 5.) If they go over the attempts, they get banned from trying to log in for a day (or however long you define). It also removes the WordPress version information from your site's HTML code which has no purpose except to tell hackers "try these methods to get into my website". It can stop direct execution of PHP scripts from inside wp-content and more.

Having it on my site for awhile, I've found that hackers predominantly try one of three usernames. The first, of course, is "admin", the default WordPress administrator username. If you have your admin account named "admin", rename it at once. Even if you do nothing else, you've increased your security a ton. The next account they try is the name of the site. If you run "example.com", they'll try the username "example". If you run "SomeOtherSite.com", they'll use "SomeOtherSite". The last one they'll use is "administrator" (an obvious choice people might change "admin" to).

I assumed developers would be thinking about security first with e-commerce.

These are developers who, when faced with the problem of how to build an e-commerce site, think "I know, I'll use my favourite blogging software". Assuming they can tie their shoelaces is a stretch, let alone thinking about security.

Right about now, somebody is champing at the bit to reply saying that Wordpress has outgrown its blogging roots and is now a proper CMS. I invite anybody tempted to believe that nonsense to look at Wordpress' database schema and make their own mind up.

Great, Dice posts story from a corporate-software-industrial-complex advertorial mag, with a link to their so-called blog. Which ironically is running WordPress, along with a bunch of common plugins like "Yoast WordPress SEO plugin v1.4.7" and "All in One SEO Pack 1.6.14.6". Right there tells me how clueless they are about WordPress, because unless you have a damn good special reason, you do not want to be running two separate SEO plugins. LeadGen contact form plugin, a bunch of ad and analytics beyond the usual, and no apparent caching plugin. Oh, and no Google Authorship id done the correct way, despite both of those SEO plugins having "fill in the blank" prompting for it (they do have an XFN tag on their contact info but don't do the full Google social.)

For more laughs, their verison of All-In-One SEO is downlevel. Exactly what Checkmarx themselfes warn agansit. They are on 1.6.14.6, current version is 2.0.2.

Yeah, I'm gonna listen to them about WordPress security.

When you click through their blog to the actual PDF report, guess what? They redacted the names of all those "at-risk" plugins, noting only 6 by name. Four of which they claim took their advice and fixed the problem, and two (WP Super Cache and W3 Total Cache) which I recall getting fixes for months ago. Hot news. I guess that even though their supposed expertise is in scanning for vulnerabilities, they are not going to tell you which are at risk in the current environment, because you didn't pay them. Classic dipstick move. Total and utter unawareness of the karmic and $$ benefits of internet "gift culture", such as, the whole damn open source movement and the specific WordPress ecosystem in which they are supposedly expert.

But we should listen to them, because: Checkmarx was recognized by Gartner as sole visionary in their latest SAST magic quadrant and as
Cool vendor in application security.

I saw this same question asked further up the comment line, and I think it's the key. They aren't targeting wordpress blogs.

What I think you are referring to is the unique authentication keys and salts. I have had to (reluctantly) fix a client's hacked site because they had set it up without them.

If there's any newbies here, make sure you replace (WP provides a random generator) the definitions below in wp-config.php:

/**#@+ * Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define('AUTH_KEY', 'put your unique phrase here');
define('SECURE_AUTH_KEY', 'put your unique phrase here');
define('LOGGED_IN_KEY', 'put your unique phrase here');
define('NONCE_KEY', 'put your unique phrase here');
define('AUTH_SALT', 'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT', 'put your unique phrase here');
define('NONCE_SALT', 'put your unique phrase here');

You should not use plugins to regulate login attempts, at this time. Check the post, below and link to his blog with the reasons why. http://it.slashdot.org/comments.pl?sid=3643255&cid=43436363

I'd also recommend that people reset their Secret Keys to resalt users' cookies. https://codex.wordpress.org/Editing_wp-config.php#Security_Keys

Pardon?

All those SQL Injection CVEs for both projects all seemed to me like they were in 3rd party addon modules/plugins.

Without any kind of looking into just how many 3rd party addons are available for each project and whether or not the vulnerable ones are ever likely to actually be installed on the average site, it's jumping to conclusions to use that to compare the two projects to each other.

eg for Drupal I looked at how many sites report using those Drupal modules, and got:
3423, 30*, 163, unknown*, 1957 for the 5 modules that had CVEs. The two marked (*) were marked with large warnings as insecure and abandoned with . And this is out of 19000+ modules hosted at drupal.org.

For comparison the most popular contributed Drupal addon module reported 547306 sites currently using it. It would be safe to say that less than 1% of Drupal sites have ever used any of those modules that had SQL Injection vulnerabilities this year.

Someone else wanting the same data for Wordpress (I ran out of enthusiasm), could look it up here:
http://wordpress.org/extend/plugins/

Wordpress has even more addons available than Drupal. I don't think 5 or 6 SQL Injection vulnerabilities in a year out of roughly 20000 3rd party addons is enough evidence to claim either project is not doing a "pretty good job". You'd need to look at other factors.

SMF is a sloppy mess to customize in my experience. If your need is to integrate something to WordPress, you might as well use BBPress:

http://wordpress.org/extend/plugins/bbpress/

SMF2WP - A Wordpress plugin that ties the 2 together.
----------
SMF2WP is a simple one way bridge from Simple Machine Forum (v2.0.1 tested) to WordPress (v3.2.1 tested). This means, this one uses databases of SMF Forum and sync to WP database every time a user performs log-in action in both WP and SMF. To get this working, it is highly recommended that you have a fresh install of WordPress with an install of SMF. Also, WP and SMF must be installed in same domain, and should not be being accessed through a subdomain, though it still work. For example, if your website contains of WordPress for news and SMF for forum, if your news is mydomain.com, then your forums should be somewhere like mydomain.com/forum.

This plugin will do these following tasks:

        If a user log in WP, then that user will be logged in SMF using SMF2API.
        If a user logout WP, then that user will be logged out SMF using SMF2API.
        If a user log in SMF, will be logged in WP as well.
        If a user log out SMF, will be loged out WP as well.
-------

Plugin - http://wordpress.org/extend/plugins/smf2wp/

Actually, I never said their format is bad; just that mine is better; in many ways, mostly for my own purposes. It has virtually nothing to do with K&R indenting, which was actually invented in the early days of C, when file size was a much bigger issue than it is now.

You see, I write plugins for all three of the "big" CMSes (Drupal, WordPress, and Joomla).

I use a common base class, and about 90% of the code is completely cross-coded. It's a sort of "M-V/C" pattern, with the C and V being mixed up a lot. It's an outstanding way to generate extremely robust and high-quality UX across systems. I've been doing it for a long time, and in many different languages.

I won't rewrite all the code used in the other plugins, just to please one set of folks. They have every right to enforce a common style, and I have every right to release mine on GitHub. The Drupal folks are geekier than most, so fetching the plugin from elsewhere isn't a big deal. It would be more of a big deal for the WordPress crowd or the Joomla crowd.

As I said, it really is all about personal style. However, in all my years of coding, one thing that I have learned, is that geeks LOVE to say "you were wrong", so I'm glad I was able to provide that service for you.

Cheers!

Actually, I never said their format is bad; just that mine is better; in many ways, mostly for my own purposes. It has virtually nothing to do with K&R indenting, which was actually invented in the early days of C, when file size was a much bigger issue than it is now.

You see, I write plugins for all three of the "big" CMSes (Drupal, WordPress, and Joomla).

I use a common base class, and about 90% of the code is completely cross-coded. It's a sort of "M-V/C" pattern, with the C and V being mixed up a lot. It's an outstanding way to generate extremely robust and high-quality UX across systems. I've been doing it for a long time, and in many different languages.

I won't rewrite all the code used in the other plugins, just to please one set of folks. They have every right to enforce a common style, and I have every right to release mine on GitHub. The Drupal folks are geekier than most, so fetching the plugin from elsewhere isn't a big deal. It would be more of a big deal for the WordPress crowd or the Joomla crowd.

As I said, it really is all about personal style. However, in all my years of coding, one thing that I have learned, is that geeks LOVE to say "you were wrong", so I'm glad I was able to provide that service for you.

Cheers!

I don't have the technical skills to judge the merits of MySQL vs PostgreSQL, but I can't tell you one thing: MySQL is like PHP, it might have lots of critics, but is the more widely used, supported, and developed database/programming language for web applications. All popular CMSs are written in PHP (Drupal, Joomla, MediaWiki, WordPress...), and many of them have MySQL first in the list. WordPress is almost MySQL specific. They have a PostgreSQL plugin, but works rewriting queries on the fly, and they recognize is expected to be slower, and not work for all plugins.

I've always wanted to have the excuse to try a different programming language/framework for web applications, and even a different database server, but I never had the excuse because you always feel second class if you go with them. I use my own hosting, but for cheap virtual hosts PHP and MySQL is almost a de facto standard. And if you pick some web application almost always MySQL is the best or only choice.

I know some day I'll be proved wrong, and this comment will be outdated, but I don't feel this is the time yet. And let me insist, I'm not claiming is due to technical merits (nor denying it), but I feel this is the way it is.

1. What sites are out there that implement OStatus? I know of

http://rstat.us/
http://identi.ca/
http://status.net/

To start with, every site running StatusNet implements it. Here are a few lists of independent StatusNet sites:

• List of Independent StatusNet Instances
• List of Federated Users
• Another list of StatusNet sites, organised topically, also with links to some other lists

There's also an OStatus plug-in for WordPress, a set of OStatus-bridge apps for Facebook, Twitter, and Google+.

And there are plenty of other sites/platforms that support enough parts of the OStatus stack to be useful (like PuSH, which is the part that allows you to `follow' people on other sites); e.g.: even if your blog-platform doesn't support PuSH, you can run it through FeedBurner and that will make it PuSH-enabled (which is how I get notices from mimiandeunice.com in my StatusNet timeline, for example).

There are probably others that I haven't listed or that I don't know about; when I find new OStatus-related things, I bookmark them on my OStatus-compatible microblog.

2. What good and complete tutorials are there for implementing OSTatus? The ones I tried broke my brain. I want less theory and words, at least initially, and more (pseudo) code. Let's start simple: What do I need to do to make my CMS "folllowable" from the three sites above, for example?

Start with `How to OStatus-enable Your Application'.

Just for example, take Wordpress and Joomla, the 2 that you mention.

There are already migration tools for those platforms, so most of your job is already done for you.

That was simply not true for me, in the case I mentioned.

Also, themes are difficult to update. Compared to plugins and the Wordpress core, theme updates have these problems:

1. First, themes do not notify you when they have updates available.

They do now. I'm staring at a theme update notification right now.

2. It takes an expert to merge a theme update with the existing customization of the theme. (Plugins and core updates are one click.)

No it doesn't. Use Child Themes.

3. Theme vendors limit their support. I dealt with a well-known theme vendor which charges some small amount for a subscription to all its themes. It refuses to provide archive versions or changelogs. So the expert is left guessing what customizations have been made, unless some previous person working on the site has keep a copy. (Plugins are more commonly from the WP site, with changelogs and archives.)

True. As with all vendor markets, YMMV and caveat emptor.

(Also, protip: man diff)

4. Users keep unused themes lying around online and see no reason to update them. (This can also be a problem with inactive plugins.)

Lazy people are lazy. This is a problem with people, not with Wordpress.

5. Wordpress core can do nothing to protect against bad code. A theme can run arbitrary PHP, as can any admin user from the admin interface, as mentioned by parent. (Plugins are similar, though runtime the active theme has priority over plugins.)

Again, this is a 'vulnerability' in programming languages, necessary because write and execute permissions are kind of important to people who want functionality. How this is a 'fault' in Wordpress is beyond me.

Any software that abstracts away some of the details leaves open the possibility that its users might not understand its inner workings well enough to run it securely. It's meaningless to observe this. I could say the same about cars (and be perfectly correct). If I wanted to add something actually useful to the debate, I would:

1) Detail which plugins are responsible for the vulnerability.

2) Describe how they made the system vulnerable.

3) Describe whether they can be made secure, and if so, how.

Most of my WP installs were infected because I am a slack ass. Here are the high level steps I took to solve the problem:

• 1) Backup sites.
• 2) Fix all world-writable directories in your WP install (what the hell WP?!). This seems to be the primary vector for getting in.
• 3) Clean up infected PHP files with this script from php-beginners.com. Thank you Paolo.
• 4) Inspect all .htaccess configs for errant redirects and fix.
• 5) Install and run the timthumb vulnerability scanner. Possible secondary vector. Thank you Peter Butler!
• 6) Update your WP install to latest and greatest.
• 7) Remove any unused plugins and themes.
• 8) Backup sites.

I may be missing something - again, I'm a slackass. Anyone else have other advice for our admin-challenged friends besides "get a real software package"?

By the way, I was trying to lock down one of my WP installs to only allow authed users access to posts. However, WP does not put the assets for post - usually in wp-content/uploads - behind the auth wall. It's just out there for the whole world to see. It was a simple fix to rewrite the .htaccess config for this directory to redirect to an auth script, but still it still shocks me how insecure this app is.

WordPress is extremely easy and quick to update. You can click a single button and update every single plugin and theme, or another button to update core. That's it. If you're upgrading by manually uploading files to a bunch of different servers for some reason, you should at least look into something like updating with Subversion or using multisite and just updating once for every site.

Some of that is Wordpress' fault for not having an easy way to run mass upgrades. My employer has 15 different sites running on Wordpress and the fact that I have to log in to each one manually after upgrading the files and click a link to handle the database update is annoying.

This drove me nuts at my current job for about 2 months - you need Wordpress Network.

There's the easy way and the hard(er) way to do this:

This is the official easy way, but it's never worked for me (last tried in Spring of 2011). The nice thing is that it's all stuff built into WordPress, so you should be able to do it without any problems. I'd say it's probably worth giving this a try with one site, and if it works, run with it.

This is more down and dirty way that will definitely work, and is more or less how I did it. A little SQL editing never hurt anyone.
Also, this is a great companion to the bavatuesdays link. He goes on about his DNS in the first few paragraphs, but the second half of that post has some good details about where files need to be, and how links and such need to be updated.

Once you have a network, you a fantastic "Update Network" button. Boom. Take the rest of the day off.

Some of that is Wordpress' fault for not having an easy way to run mass upgrades. My employer has 15 different sites running on Wordpress and the fact that I have to log in to each one manually after upgrading the files and click a link to handle the database update is annoying.

This drove me nuts at my current job for about 2 months - you need Wordpress Network.

There's the easy way and the hard(er) way to do this:

This is the official easy way, but it's never worked for me (last tried in Spring of 2011). The nice thing is that it's all stuff built into WordPress, so you should be able to do it without any problems. I'd say it's probably worth giving this a try with one site, and if it works, run with it.

This is more down and dirty way that will definitely work, and is more or less how I did it. A little SQL editing never hurt anyone.
Also, this is a great companion to the bavatuesdays link. He goes on about his DNS in the first few paragraphs, but the second half of that post has some good details about where files need to be, and how links and such need to be updated.

Once you have a network, you a fantastic "Update Network" button. Boom. Take the rest of the day off.

Some of that is Wordpress' fault for not having an easy way to run mass upgrades. My employer has 15 different sites running on Wordpress and the fact that I have to log in to each one manually after upgrading the files and click a link to handle the database update is annoying.

This drove me nuts at my current job for about 2 months - you need Wordpress Network.

There's the easy way and the hard(er) way to do this:

This is the official easy way, but it's never worked for me (last tried in Spring of 2011). The nice thing is that it's all stuff built into WordPress, so you should be able to do it without any problems. I'd say it's probably worth giving this a try with one site, and if it works, run with it.

This is more down and dirty way that will definitely work, and is more or less how I did it. A little SQL editing never hurt anyone.
Also, this is a great companion to the bavatuesdays link. He goes on about his DNS in the first few paragraphs, but the second half of that post has some good details about where files need to be, and how links and such need to be updated.

Once you have a network, you a fantastic "Update Network" button. Boom. Take the rest of the day off.

I wouldn't worry so much about spam, but rather about frivolous projects.

To see what other models are like, go check out...
http://www.indiegogo.com/
http://rockethub.com/
http://www.pozible.com/
http://www.crowdfunder.co.uk/
http://invested.in/
http://fundry.com/
http://pledgie.com/
http://www.sponsume.com/
http://peerbackers.com/

Then after you're doing reading through the hundreds of projects that amount to little more than "give me money because... well, just because.", you'll probably be glad that KickStarter does some, albeit a very superficial, checking of projects.

Yes, KickStarter has its own problem projects that make it through the review process.. projektor (probably a scam), juicies (unrealistic funding vs rewards leading to a kid way in over his head), Googly Eyes (essentially selling an existing product for a premium).
But they do try, and they explicitly disallow 'good cause' type projects, which are often the "just give me money" type projects.

Nothing against 'good cause' projects when they really are for a good cause - people who need a prosthesis but can't afford one.. more power to then. But then there's the "I want to go on a trip to Europe"-types.

I'd be more afraid of that sort of thing hitting crowdtilt, than spam hitting it.

Also, for those who want a truly open alternative, set up a Wordpress site and go check out:
http://ignitiondeck.com/id/wordpress-crowdfunding/
http://wordpress.org/extend/plugins/crowd-funding/

If you have a Wordpress blog you can add a plugin that takes your site dark for the 18th - redirecting to an education page. But it's a 503 redirect, so it won't kill your search engine rankings. Every little bit helps.

Apparently, the GPL being incompatible with Apple's App store is a murky issue at best. Currently, there are several apps that are licensed with the GPL, such as the iOS Wordpress App and Doom. So what is the final word on GPL apps in the App Store?

Heise have recently published the source code under the MIT license:
http://www.heise.de/extras/socialshareprivacy/
Unfortunately, documentation and strings seem to be German only, but it's probably not excessively complex to set up. Maybe someone can start an English language fork?

Btw, users have already created plugins for Wordpress and Joomla:
http://wordpress.org/extend/plugins/2-click-socialmedia-buttons/
http://wordpress.org/extend/plugins/wp-socialshareprivacy/
http://joomla-extensions.kubik-rubik.de/2csb-2-click-social-buttons

Heise have recently published the source code under the MIT license:
http://www.heise.de/extras/socialshareprivacy/
Unfortunately, documentation and strings seem to be German only, but it's probably not excessively complex to set up. Maybe someone can start an English language fork?

Btw, users have already created plugins for Wordpress and Joomla:
http://wordpress.org/extend/plugins/2-click-socialmedia-buttons/
http://wordpress.org/extend/plugins/wp-socialshareprivacy/
http://joomla-extensions.kubik-rubik.de/2csb-2-click-social-buttons

I've been using Dreamweaver for about 12 years, great piece of software - for static websites, and if you want to maintain it yourself.

However, from some of the previous pieces of software the author has used, it sounds like his best solution is a content management system. Sadly, for most of these, it does mean a rewrite of the site, but it sounds like he is doing that anyways every couple of years.

Go with something like Wordpress http://wordpress.org/ or Joomla http://www.joomla.org/ . You just do not know the relief it is when clients have their own ability to change content - both for stress on your end and to get stuff done in a timely fashion on their end. Both (especially Wordpress, not as familer with Joomla) have been around for years, and are pretty well established. And many hosting providers will install these on your site free of charge, so all you really have to do is set it up. I would look into some themes though - the default layouts for Wordpress kind of irritate me - maybe because I have seen so many sites using that default template that its gotten old. But there are TONS of themes and plugins out there for both systems.

1. Blog your progress. Whatever you did today, blog it. Let people know what you did that worked, or what was faster (Nginx vs. Apache), or what wasn't (ColdFusion?). Don't reinvent the wheel, use WordPress, regardless of whether you like PHP/MySQL or not.

2. Use a subscription/payment management company. You're just a small group of nerds, not accounts receivable clerks. Fastspring, Plimus are free; Chargify, Subsify, Cheddar Getter, BrainTree, Spreedly charge; and Zuora is expensive.

3. Use Google Docs and Slideshare to share documents.

4. Chat. Don't just rely on email. Emails can often read like "this way or the highway". Be collaborative. You can often accomplish more with 15-30min collaboratively as opposed to composing and responding to long emails. Skype, Jabber, SIP

5. Take notes on what you did. Made a server configuration or a setting change in your CMS, your compiler, or whatever? Copy and paste from xterm so you don't have to guess about those commandline switches next time. Take screenshots and make them available to others. Zim, Projly, DokuWiki.

6. Have a phone numbers. If not bog-standard landline phones, take advantage of Google Voice and SkypeOut and SkypeIn (people can call your Skype line on a normal phone number). I realize Google Voice might not be available in South Africa yet.

7. Someone mentioned version control. Use git if you're a cool kid. Or svn if you're old and busted. Read the RedBean book. I've had success in having non-tech colleagues using graphical clients like TortoiseSVN (integrates into Windows Explorer).

8. Write tests. Any member of your team, sitting anyplace, should be able to push a button and run all your tests. Tests document how you're supposed to use a given method, class, etc., especially valuable when you're so far flung. Use JUnit, PHPUnit, FooUnit for your language. Write the tests before you develop, and you're doing Test Driven Development.

9. If you're writing tests, that implies loose coupling, which might require dependency injection. Can be difficult to climb that mountain, but it's worth it when you can just run a test and be sure your project works.

10. Development processes: Scrum, Extreme Programming. UML lets you communicate graphically about objects.