This image has the "None" button clicked under the "Link URL".

WordPress has the habit of creating 3 separate files for each image upload. AND it saves the orriginal image file. This is set in stone, and WordPress does not plan to change the default behavior.

When one clicks on the image in the post, it will opens up the orriginal file. Or does it?

This post will test the functionality.

this image was inserted with the default behavior, no "link URL" options were selected.

This was an infiltration on the server, where the wp-header.php had a bunch of gobbeldy-gook javascript added. How could this happen? And what’s more what other php files were modified? Dealing with this issue and getting the site back up and running was one thing, but almost worse was the almost immediate “Black List” by Google. A dreaded event indeed!

Deleting and restoring a few php file got the site back without too much delay. And after an exhaustive search in all folders for any other rogue files, the server appeared to be clean. To prevent future attacks, all passwords were changed. But that action by it’s self did not solve the dreaded appearance of a big red warning screen presented curtesy of Google whenever anyone tried to access the site. Convincing Gloogle everything was well now took a bit of doing.

First a Google Webmaster account has to be created. Then a validation page/link has to be installed on the server, followed by a quick visit by Google to establish its there. And only then can a new request for a spidering visit be activated. It can take Google a couple of days to do this, so in the meantime viewers still get the dreaded red screen. Even though the site is clean.

This system is actually pretty good, nobody wants to visit a site that might be infected. However, getting thrown “into the dungeon” by Google when there is no danger, is disconcerting to say the least!

Editing the CSS with a child theme of StudioPress Genesis is an ongoing project, it’s still not entirely clear to me how developers do it. So many styles… and so much potential for conflicts. Sometimes it “should” work, but doesn’t and the likely culprit has everything to do with the “Cascading” part of “CSS”. I read recently that learning CSS is way up there on the scale of difficulty in programming languages. The syntax is easy, but the logic is endlessly complex.

The Firefox Firebug browser plug-in is a Godsend. What would we do without it? A quick and easy way to see the effects of CSS and that changes that can be done. Then back into Dreamweaver to edit the ‘real’ CSS file. It also allowes us to the the CSS properties of other websites, and yes, they too must struggle, if the commented-out code is anything to go by!

Which reminds me, can’t stress enough the need to add comments to any code files. They act not only as a reminder for our own changes, but also for any hapless designer who might have to work with the file at a later time!

There are always little customizations needed, no matter how suitable a Theme appears initially. The client always seems to want something that is either not built-in, or something taken out. Using a framework such as Genesis does not make tweaking any easier! Multiple processes and PHP codes are hidden in the Genesis folders (which one should never edit) so it takes a bit of PHP knowledge to modify or “hook” HTML, PHP and shortcodes to any of the existing Genesis hooks.

After much searching, and trying to do it the “hard way”, I realized StudioPress has a plugin for this. First step is to install it, but then what? Here’s where some PHP knowledge is required. I managed to make some modifications using the “Hooks” plugin, for instance controlling whether the date shows above every post or not.

Say ‘hello’ to web-based research, research and more research! I’m still trying to figure out if the learning curve required for modifying StudioPress templates is worth the trouble. Could it be easier to start simple, with the default 2010 WordPress theme?

Time to hit the support files for further info on “Hooks”. Right now it’s all gobbledygook to me!

This was the perfect time to experiment with a restore from backup. I had previously used the wp-db plugin, and had a .sql.gz copy of the backup. Here’s the process:

Log into the server account (Bluehost) and open PHPmyAdmin. Select the appropirate database. Click the “Import” and upload the .sql file. It did a little processing and WOW… the site is back! Complete with my settings, posts, categories, design. Very cool, and good to know how.

Just make sure to regularly back up any WordPress installation! And update as needed, but be aware an update CAN screw up everything.

For instance… when browsing to a folder is the directory visible? This can be avoided in several ways, but it also depends on the host/server settings. We obviously don’t want anyone to see right into the folder contents.