Archive for the 'WordPress' category
Monday, February 15th, 2010
- WYSIWYG style configuration now resides in plugin options.
Easier configuration - no need to edit your CSS file to make your editor true WYSIWYG. Don't worry, your old configuration will still work.
- Image management tool now appears with the right year/month/ directory opened.
Your blog contributors won't upload images into your root image directory anymore.
- All uploaded images above certain height and width (check out plugin options) are sized down to fit into it.
Well, this won't handle those insane 5000 x 3000 px images some people try to put into their posts (as it's just too big for the PHP memory), but at least it takes care of the oversized 2000 px wide images which won't fit on your screen when opened. The default setting is 960 px of either width or height.
- Works on sites with secured wp-config.
- Insert FV Wordpress Flowplayer button added.
Let's you use our popular video plugin with ease.
- Pasting dialog receives focus when it appears.
- Dreamhost JSON glitch fixed.
Head on to our Foliopress WYSIWYG plugin page or Wordpress.org.
WordPress |
Saturday, February 6th, 2010
A lot of our plugins use embedded shortcodes inside square brackets.
Our embedded shortcodes look something like this:
[command parameter=something value=number]
The reason we use square brackets is that square brackets parse just fine in WYSIWYG editors including our own Foliopress WYSIWYG.
We've had a lot of simple questions about how to use our FV Wordpress Flowplayer. I couldn't understand why. The instructions are pretty straightforward.
It turns out that the shortcodes were being parsed and showing the result instead of the code people should be using. How anybody managed to get the plugin working without the short codes is a bit of mystery to me. But they did. Wow can people be ingenious sometimes.
So once I'd found the error, we weren't much better off. I couldn't get the square brackets to stop parsing. With angled brackets it's not so difficult. One just escapes them like this:
< >
But there is no such escape for square brackets (or rather the escape still gets parsed by our plugins).
It turns out that the shortcode won't trigger even if there is a non-breaking space: .
But that is no real solution as it means that we are telling our users to insert a space or weird character where there is none. No, we needed a real invisible character to disable execution of the shortcode but leave no visible trace in the html.
After much poking around, I finally found one: ­ That's the soft hyphen character.
So I can boldly post commands like this:
[flowplayer src=example.flv, width=400, height=300]
Which would otherwise result in this:
Clearly showing an empty movie box isn't going to teach a visitor much about how to place an flv in his or her own post.
The long term solution is to code our plugins not to parse what is inside code tags. But in the meantime, soft hyphens can save you in a pinch from having embedded shortcodes execute when they shouldn't.
Alternate techniques (all in use on this site)
- use javascript to write the opening square bracket): not bad but I'd rather put in an invisible character than face fragile javascript in half a dozen tutorials
- use sniplets to hold the documentation (as sniplets don't get parsed a second time but just inserted).
Downsides: unwieldy as you have to go over to sniplets to edit or change tutorials each time. Not easily moved between CMS's or even sites. Plugin dependent.
More readable source code without a javascript code parser
While I was at it, I decided to turn all code into a nice dark green to be more readable and made it a few pixels larger too. Previously code on Foliovision was an elegant but slightly difficult to read medium gray.
WordPress |
Tuesday, January 12th, 2010
We just released a new version of FV Wordpress Flowplayer plugin. For those of you who don't know it - it's the standard opensource Flowplayer, but without any branding in it.
Version number is 0.9.15 and it has two new features:
- widget support - now you can put videos to your sidebar with ease
- template support - allows you to insert videos with some simple PHP - nice feature for site developers
Read our FV Wordpress Flowplayer page to see how to use it or download it from FV Wordpress Flowplayer on Wordpress plugins.
WordPress |
Saturday, November 21st, 2009
We received a lot of requests to add some buttons to the toolbar of our own Wordpress WYSIWYG editor called Foliopress WYSIWYG. That's why we added a brand new drop down menu which can be easily customized - you can add any kind of styling you can imagine to it.
Foliopress WYSIWYG Formating Dropdown
The usage is simple and straightforward for more advanced and experienced Wordpress users, but in case you need help you will find everything about it in:
And of course - you are welcome to ask questions in the comments bellow our articles.
The version number is 0.9.7. Download it from our main Foliopress WYSIWYG page or Wordpress plugins.
WordPress |
Saturday, October 31st, 2009
As we announced a couple of days ago, the new version or our WYSIWYG editor for Wordpress is done. The main improvements are:
- Multiple image posting
The Image Management window stays opened after to send an image to the post. This allows you to insert multiple images with ease. If you like the window to be closed every time you insert the image into the post, you can disable multiple image posting in the options.
- No need to edit any configuration files
Everything important is in the options screen now!
New Foliopress WYSIWYG options screen
- Available thumbnail sizes are limited by the size of the picture
Each time you are going to insert a thumbnail for an image into the post, only the sizes which are lower than the horizontal size of the image are shown. This won't let you insert a 500px thumbnail for a 320x240px image.
- Better security
Since the Image Management window may stay opened after you insert an image, we implemented a technique which disables the usage of that window after you log out from your Wordpress admin panel.
- Automatic wpautop can be turned off
If the post you are about to edit with Foliopress WYSIWYG was created with the default Wordpress editor (TinyMCE), Foliopress WYSIWYG runs wpautop on it prior to editing. TinyMCE is storing posts without any HTML markup for the paragraphs, so it's necessary to run this core Wordpress function in order to work with the posts correctly in our editor. You may want to disable this function if some of your special posts are destroyed after opening with Foliopress WYSIWYG.
Download the plugin from our Foliopress WYSIWYG page or from the Wordpress plugin page.
If you are going to do the auto-upgrade, you should use this simple guide to preserve your current settings.
WordPress |
Tuesday, October 27th, 2009
If you use our WYSIWYG editor for Wordpress called Foliopress WYSIWYG, then you will be probably happy to hear the exciting news:
You will be able to upgrade to the next version (which will be released in next couple of days) using the Wordpress built-in automatic plugin updater.
However if you ever made any changes to the custom configuration file, these changes will be lost, as we have no control over the Wordpress update process and all the files will be overwritten. This is a list of your configuration changes which we can't keep after the update is done:
- configuration of BodyId and BodyClass for the editor
- custom Toolbar configurations
- custom plugins for the built-in FCK editor
What you need to do is to write down these settings before the upgrade and then put them into the new options screen which the new version of our plugin will feature (in case you used any extra plugins inside the editor, you need to save all the plugin files and update the same custom config file manually).
Here's an article about how to change the custom config file in all the old Foliopress WYSIWYG versions which will help you to pull these settings out of it: Foliopress WYSIWYG setup and edit.
If you are not using our editor yet, we hope this feature will help it compete with the others.
WordPress |
Tuesday, October 20th, 2009
We are very happy to announce that one of the most burning issues with our own WYSIWYG editor called Foliopress WYSIWYG has been fixed. I'm talking about the bad size of editor window in Safari and some other Webkit based browsers, like Google Chrome.
This is the problem most of Safari users experienced with our editor
You can see that the actual editor window is not stretched to the whole desired size of the editing window. The workaround was to switch to the Source mode and then back to WYSIWYG. The editor window had the right size then.
The fix for this issue appeared just a couple of weeks ago in FCKeditor's trac bugtracking system here (FCKeditor is one of the biggest parts of Foliopress WYSIWYG).
You can download the new version (0.9.5) from the main Foliopress WYSIWYG page.
WordPress |
Wednesday, October 14th, 2009
We are working on some major upgrades to our Foliopress WYSIWYG this month. Our wonderful client Richard Nikoley kicks the pants out of his Macbook Pro and he does the same thing to Foliopress WYSIWYG. He's given us a laundry list of small issues to fix, most of which have to do with minor misbehaviour in the Safari browser.
Given that Safari is webkit and Google Chrome is based on Safari, getting webkit browsers right is a priority for us.
We've fixed the text issues (no need to click the source button and back for proper display) but still have to do our SEO Images upgrade to take us from KFM 1.2.1 to 1.4.3 which will give us full Safari support for image upload and insertion.
While we were at it, Martin and I had a discussion about whether to be using code or pre tags for code extracts.
I advocated both, wrapping slapping an unescaped code tag inside the pre tags. It turns out that wreaks havoc in Foliopress WYSIWYG, stripping the line breaks. So our recommendation for Foliopress WYSIWYG users is just use escaped code inside pre tags.
While I was tracking this down though, I decided to chase down the W3 recommendations for the use of code and pre in the HTML 4.01 specification.
Imagine my surprise to find out that poetry their code example:
The following example shows a preformatted verse from Shelly's poem To a Skylark:
<PRE>
Higher still and higher
From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
</PRE>
Here is how this is typically rendered:
Higher still and higher
From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest
I hadn't read Shelley for years, since I wrote a couple of long papers on wife Mary's Frankenstein. It was a joy to find something so exquisite and uplifting in an otherwise long and dry technical document.
Unknown anonymous specification writer, thank you for bringing this fragment of poetry into this coder's day.
Code is poetry and as the deconstructionists would say poetry is code.
But what does the W3 specification reveal about the code and pre mystery?
It turns out that code is a phrase element and pre is a visual presentation element.
In the end, code is a bit of redundant information unless you are searching a document for code fragments (which honestly could be just as easily done and more certainly with some nice rules looking for certain patterns). Your search could just as easily use pre to bring up most of the fragments for which you are looking.
Visually both code and pre by default render in a fixed-width font, with code tending to get a typewriter style typeface like courrier and pre tending to get a sansserif fixed width font like Monaco. I think I prefer seeing my code in courrier but there is nothing preventing me from adding a typeface for pre to my stylesheet.
For the sake of simplicity, our recommendation is to just use pre for your larger code blocks. We won't be doing further debugging of the double nested pre and code tags as just getting pre not to add unnecessary angled brackets was a formidable task. One of the downsides of WYSIWYG editors is limited capability in handling code samples in text.
Unlike basic written text, in code formatting even a single changed space can render the code useless or even destructive.
When writing a major article about programming, we'd recommend turning WYSIWYG off completely which is also a per post option with Foliopress WYSIWYG. There's nothing more depressing than seeing a carefully built article filled with elaborate code examples crumple and scatter into visual dust. Code samples are tough to rebuild.
For basic use on html or CSS code samples though, pre alone with escaped brackets will take you or us as far as we need to go.
Is there a use for the code tag then?
We do recommend using the code tag for single code elements as in this article.
IT, WordPress |
Wednesday, October 14th, 2009
We recently checked our site in W3C Markup Validation Service and find out that some of our inline javascript in the posts is not properly enclosed in CDATA tags. Read about the details of the issue, reason for it and a bit of hope in future Wordpress releases.
Everything inside a CDATA section is ignored by the XML parser and all the inline javascript should be in it. This is how you do it:
<script>
<![CDATA[ function anything(a,b)
{ }
]]>
</script>
So we fixed all of our plugins which are putting any javascript into the posts and there was another error coming out of the Validation Service saying that the CDATA section is not properly closed.
The generated source code of the page was looking like this:
<script>
<![CDATA[
function anything(a,b)
{ }
]]>
</script>
The greater than symbol in CDATA closing tag was replaced by the HTML entity.
We disable both wpautop (this is a function which is automatically inserting paragraphs and newlines into the post - that's why we hate the default Wordpress editor which can't live without it and use Foliopress WYSIWYG instead) and wptexturize (another nice Wordpress function, which used to mess up all of our HTML comments) all the time, so we were very unhappy that there is some other plugin destroying our posts.
After a while I discovered that it's the Wordpress core who is doing this. Let's take a peek at the structure of the responsible Wordpress template tag code:
function the_content() {
1. Get the post content;
2. Apply all the filters on it;
3. Replace ]]> with ]]>
4. Display it;
}
So there's an extra line of code just to mess the CDATA tags. No php comments around it to explain why it's there. Nothing in the Wordpress Codex about it, no sensible answers in support forums.
I had to search the Wordpress bug tracking system for an hour to find more about the problem: That single line of code is there for RSS. CDATA closing tag would just break the feeds. That's is.
Seems like the Wordpress guys are aware of this as the issue is planed to be solved for Wordpress 2.9 - https://core.trac.wordpress.org/ticket/3670. That means the tag will be converted only in the feeds. Until then our pages are not 100% valid.
However the ticket is 5 years old now with last change 5 weeks ago. I can't believe Wordpress community is fighting this nearly from the beginnings of Wordpress.
- Read more about CDATA on w3schools or Wikipedia.
- Read about problems people have with this Wordpress issue.
- Take a look at the fix.
WordPress |
Wednesday, October 14th, 2009
It's no secret we are seriously into Wordpress SEO. After the otherwise brilliant John Godley's Headspace killed a few too many websites on us, we decided not to use any extra Wordpress SEO plugin but just use appropriate core Wordpress functions for our SEO.
What we did was use the excerpt field for descriptions and tags for keywords.
KISS Wordpress SEO: now retired since version 2.7
Our KISS Wordpress SEO was great until Wordpress 2.7 when suddenly the excerpt field no longer existed in the page editing interface. Thanks Automattic! Our perfect workaround was now a pain in the butt.
We gave the UrbanGiraffe Headspace 2 another look, but alas it was still taking our sites down. I know Headspace 2 can work but it just didn't seem to like our core plugin install.
So we moved to the old school SemperFi's All-in-One-SEO plugin. All-in-One-SEO plugin has been around forever. It's always seemed a bit ugly and a bit clunky. But give SemperFi credit: they've been banging away on it forever and All-in-One-SEO is pretty much bugfree at this point.
What we really dislike about All-in-One-SEO is the keywords field. First, as any longtime SEO will tell you, keywords are just not that important. And as any longtime Wordpress master knows, the built-in tags pretty much have keywords covered. You just needed to add a couple of lines of code to your template and their they were.
So we don't need another interface to access keywords. We do need long titles (we used to use Joost's SEO titles plugin) and we do need descriptions. But we don't need a keyword interface.
And adding a keyword interface just confuses our clients when what we want is for them to add tags.
There is no way to turn off keywords in All-in-One-SEO and there isn't even a class on the row so there was no easy way to remove it.
We're also not crazy about automatically generated metadescription tags. We think metadescriptions should be written only by hand, as they are used to sell your post. Automatically generated metadescriptions are not really any better than letting Google and Yahoo generate them for you. For mass metadescription editing (you can see what posts and pages are missing metadescriptions and add the missing ones quickly) we use our own FV Descriptions plugin.
We thought about forking All-in-One-SEO, but due to automatic update and accidentally having our version overwritten, we didn't want to that either.
Anyway our next step was to try to contact SemperFi via their contact form and ask them to put a checkbox in their admin interface to turn off the keywords feature. I told Martin I'd give them $50 to add this feature.
Hello,
can you please put an option into new version of your great plugin which would remove the keywords field from the AI1S editing box? We believe using tags is better and the tags are used in keywords meta field anyway. The keywords field is just confusing people.
Another nice thing would be the option to disable automatic meta description generation from the Wordpress excerpt. The post either has a AI1S description entered and there is a meta description for the post or the meta description field should remain empty.
We are sending you $50 if you do these changes now. We are constantly modifying your plugin in order to make these changes (when installing, after updates), so we know it's not hard to do, we just want to make sure our changes aren't removed when updating.
Thanks, M.
We got this email back:
Please refer to http://semperfiwebdesign.com/forum/ for plugin support. We will now only address plugin issues on our new forums so that everyone can benefit. You may sign up for an account and post any issues you have about WordPress, plugins, themes, etc.
If you need personal service, we can provide professional consultancy on a per hour fee basis at our standard hourly rate.
We tried calling them too. SemperFi doesn't pick up the phone either. Unfortunately, you can't contact these jokers anymore, except via the forums. Which we did.
In their forums, SemperFi were kind enough to offer at some point to add ID's to the fields of All-in-One-SEO. But what we want is a simple checkbox to remove the keywords section altogether from the post/page interface.
What we've done here is exactly that, plus we've killed the automatic updates from SemperFi. If you use our FV All-in-One-SEO plugin, you won't accidentally overwrite your copy.
If like us you have clients using Wordpress, enjoy simple SEO with FV All-in-One-SEO. No auto-generated metadescription, no inteference with tags. If SemperFi ever get their act together to add the checkbox to the admin interface to disable keywords and an option to turn off automatic metadescription creation, we will merge back our FV version into the original All-in-One-SEO.
PS. If you are into Wordpress SEO and like your metadescriptions you should might like our FV Descriptions plugin which is a mass description field editor compatible with excerpts, Thesis, both older and newer versions of All-in-One-SEO.
Download the plugins here:
FV All in One SEO Pack - an advanced plugin for your daily SEO optimization of your Wordpress site
FV Descriptions - a handy description editor good for use with FV All in One SEO Pack
SEO, WordPress |
Friday, October 9th, 2009
Relenta is a great CRM-lite which beats any mailing software I know for ease of use and speed. Highly recommended.
As you may be aware, we run almost entirely Wordpress sites, although many are almost custom apps with additional functionality for real estate, insurance or political discussion. We needed a way to wed our Wordpress sites to Relenta. Relenta does not have contact forms of its own but instead an email API for adding new contacts.
Fortunately John Godley's Filled In for Wordpress handles forms admirably and has a mailing function built-in. Filled In to handle the forms and Relenta to handle the lists is the best of both worlds.
But like anything technical, there are a few issues to look out for. Without further ado, here is our detailed guide to using Relenta with Wordpress.
In order, these are the steps to create a form in Wordpress with help of Filled In and send the information to Relenta CRM for parsing.
-
Build an HTML form compatible with Filled In and stick it into a page or post. This means that the form has to have an unique id and action should be empty string. Example:
<form id="relenta-contact" action="" method="post">
<input type="text" name="email" value="" />
<input type="submit" value="Submit" />
</form>
-
Go to the Wordpress management, into Filled In page. Create new form and as name use the id "relenta-contact".
-
Before editing options for this form, go to "Email Templates" tab. Here create a new template (name it however you want). Click on the template name to edit it. Write some subject and click on the "plain text" hyperlink located right after "HTML content:". Now there is an "Text content" area where you need to stick the e-mail template Relenta uses to create new contact. Example:
### BEGIN CREATE CONTACT ###
API_KEY: ********************************
EMAIL: $email$
FULL_NAME: $fname$
JOB_TITLE:
COMPANY:
CONTACT_COMMENTS:
PHONE(LABEL):
WEBSITE(LABEL):
MESSENGER(LABEL):
FAX(LABEL):
ADDRESS(LABEL):#START#
#END#
TEXT(LABEL):#START#
#END#
BLOCK NAME|PHONE(LABEL):
GROUPS: ********
OPTIONS: overwrite
MATCH_BY:
REMOVE_THIS_BLOCK: not
### END CREATE CONTACT ###
Here's how you find the API and Group IDs:
The API_KEY can be found under My account > API tab.
The Group IDs can be found in Contacts > Categories and groups > Edit category > Show group IDs.
- Now go to form options (click on the form name you created in step 2). Here set 2 "Filters" (is Required for fname and email for email), 1 "Post Processors" (Send as email for Relenta) and 1"Result Processor" (Display a 'thank-you' message).
- Setup "is Required" (by clicking on it) "Field" to 'fname' and write something nice to "Error message". Setup "email" "Field" to 'email' and again write something to "Error Message".
- Now setup "Send as email" "To" to your relenta e-mail (yourname@relenta.net) and "Template" to the name of the e-mail template you created in step 3.
- Setting up "Display a 'thank-you' message" shouldn't be a problem anymore.
- You can of-course setup any other things you want (if you know what you are doing), but this basic form will work for you. There are a few more details on the Relenta email API itself in the Relenta manual. There are more details about setting up Filled In on the UrbanGiraffe plugin page.
Very Important Relenta/Filled In Compatibility Note
The last thing is that Filled In uses Swift PHP libraries for sending which do not work properly with Relenta's email API (Swift PHP inserts some bad characters in the line breaks). Here is Filled In which uses PHPMailer which works with Relenta just well. SMTP and attachments are not fully tested on this version so be sure to test thoroughly before use.
In general, any form the page of which you touch or edit in any way should always be retested after saving. Forms are one of the most fragile and yet essential parts of the a website and should be managed with great care.
Enjoy Wordpress and Relenta together now, a capuccino for your website.
WordPress |
Friday, October 9th, 2009
Basecamp URL change to basecamphq
Today 37signals dropped our domain http://webwork.clientsection.com. Instead they have replaced it with http://webwork.basecamphq.com.
There is a thread on their forums covering the issue. As one customer writes:
BasecampHQ is a stupid domain for one. What is its relevance to my clients? I am paying for a professional service – not for branding that sounds like a paint ball website.
I totally agree. Apparently this change is coming with additional footer branding and additional branding in the emails.
This is a case of breaking the contract with the original customer: us. We are the ones who bought into their white label extranet solution with attractive anonymous core domains like:
- grouphub.com
- clientsection.com
- projectpath.com
- seework.com
- updatelog.com
We pay a handsome yearly fee for the use of the software and the domain. Until recently, it's been $600/year. Now, it's $1200/year. For that fee, we expected 37signals to honour their part of the deal which was to allow us to continue to use the software and environment which we helped them get off the ground.
We actually upgraded our Basecamp account recently and consolidated our operations on the system. I was happy to do it, but now have deep regrets.
37signals at this point has gone Microsoft. They are not working for us anymore. I'm not sure they are working for them. They are working for the corporation and have become that corporation.
What is particularly disheartening is the supercilious tone and dissembling of Jason Fried has not abated. His excuse for sandbagging us on our domain name:
In fact, it reminds us a lot of our transition away from IE 6 a few years ago. That transition was also met with similar dissatisfaction by some of our customers.
Fried was immediately called on his absurd analogy by Andrew Myers:
There is no reason for this move from any perspective other than that of marketing for your products. What will this bring to us the customer (Who are paying your bills) that we simply can not live without?
I also do not like the fact that branding for Basecamp is now on all pages and in emails generated by the software. Why? 37signals, you’re dropping the ball on this one. How about spending more development time improving Basecamp, your core product, instead of wasting so much time on stuff that doesn’t really matter to your customers.
and Dougal:
it’s filled with pretzel logic. By the third sentence you’re talking about IE6 as a comparison – with the only correlation being that people didn’t like that either? And third, you never address the crux of the matter – that you sold it for years as white label and now you are branding it and linking from our extranet pages to your selling pages.
I also suggest you take a look at your About page and see if you still Believe in those things… especially the one about your customers being your investors.
Dougal hit the nail on the head.
We aren't that important anymore, the core customers. 37signals want to be the Microsoft of project management and online collaboration. They don't need or want us any more.
ep agrees and highlights another issue well known to alert 37signals customers. You can't get your data out:
You can not leave with your data period. 37s is abusing this situation which has lasted for years now. When you have been using Basecamp for years, you depend on it, your customers depend on it and you’re tied because you can not leave with your data, just a stupid xml file or a ridiculous set of html files.
37signals used to be a small company like lots of us are (or not?). When you are a small company your customers are human beings; when you have passed a certain point of growth (and greed), the same customers become numbers.
I’m afraid we have become numbers.
The only way out is via the API which is a bit shaky. Somebody should write a migration tool. In fact someone already has done so. The problem is that it doesn't work (I tried it).
We are currently working on a serious enhancement to Basecamp, which we are beta-testing internally. Now that we have over 50 live projects, Basecamp is creaking at the seams and so we've decided to enhance it.
Once this enhancement is out the door, we will be working on a self-hosted open source version of Basecamp. Our code base will be Wordpress (check out our Foliopress WYSIWYG and Thoughtful Comments to see what we are up to on the Wordpress). We've built insurance apps, real estate apps, SEO apps, all on the Wordpress codebase, so we know this can be done.
The first extra tool will be an import tool from Basecamp. The API work for our Basecamp based tool will come in very handy.
Anyone who is interested in updates on our enhancement to Basecamp and in being able to host a Basecamp-like solution on their own domain and on their own server should sign up below. People form this list will be first in line to beta-test.
If I have any strong thoughts about Basecamp alternatives in the meantime, I will share them with this list as well.
Once we get the very first iteration done, we will be seeking collaborators. If you'd like to participate in development and have great Wordpress, PHP or server-admin skills, we want to hear from you. Please sign up here:
What this won't be is a slow product like ActiveCollab (server crippling loads) with a lot of features. We build fast and lean. The first iterations will actually have less features than Basecamp but the ones which we really need. We believe in the GPL and we believe in free software and won't pull a license change either. Don't believe us?
Our codebase is Wordpress: we couldn't leave the GPL even if we wanted to.
WordPress |
Wednesday, September 16th, 2009
We often get questions from our clients about what to do when they lost a Wordpress password and since there are no images in the offical Wordpress guide (Codex) you can read our Lost Your Password in Wordpress guide.
WordPress |
Monday, September 14th, 2009
If you ever delete any users in your Wordpress installation, read carefully. Look what it looks like when you are trying to delete some user who is an author of some pages (read more about Wordpress pages):
Wordpress not showing pages in user management
As you can see Wordpress shows the number zero under Posts. But this user clearly has some pages as you can see on next picture:
User's pages
If you try to delete the user, you get no warnings about any of the pages this user created:
Deleting user in Wordpress
Why isn't Wordpress showing the number of pages in user management? Why there's no warning about the pages? The screenshots are from Wordpress 2.8.4 with no plugins.
I run into some problems because of this few days ago, several pages disappeared from a site - good luck the host provides db backups on daily basis.
Conclusion?
Always attribute all posts and links when deleting a user. It will save the pages too.
I'm submitting this as a feature request to the Wordpress developers. Let's hope they will put it in into the next Wordpress release together with number of comments and maybe some other usefull information.
Update
Seems like we are not the only one who is missing this (basic) feature. I found some tickets about this or related issues when browsing Wordpress bug tracking system.
In the first ticket it seems like this will be added in 2.9 version - wp-admin/users.php does not show pages under "posts" column.
The other ticket tickets is about showing number of comments in User management and is containing references to several other complaints about this which appeared in the support forum and it even contains a fix - Also show comment count in wp-admin/users.php. It should appear in 2.9 version.
Hopefully there will be all the information about pages, comments and even more in User management in the next major Wordpress version. The developers are not very keen to implement these ideas in 2.8.5 version (see the tickets milestones).
WordPress |
Friday, September 11th, 2009
Not having much luck with the PR profession lately.
Let's take the case of Stuart Bruce of Wolfstar Consultancy.
In July of this year, Stuart came to us with his weblog StuartBruce.biz which he wanted to move from Typepad to Wordpress rather urgently. He dropped the future work promise very early:
Just need to move the A PR Guy's Musings blog. It is quite highly ranked so it is important that the permalinks move properly. As I run a global PR company specialising in social media I might potentially have other WordPress development work in the near future.
Fortunately I don't fall for that kind of talk anymore. "Future work" is kind of like the guy on the first date promising that it's not just a one-night stand.
No worries. We aim to help people get out of Typepad. Typepad to Wordpress is not really a money maker for us in comparison to the other work we do, as it is such painstaking work (thanks Anil). We just want to help others get out of the nightmare situation of having years of their lives locked into a limited and rotting system (the so called improvements actually made Typepad worse and less search engine friendly, i.e. numbered images).
We do get lots of additional work from the people we help from Typepad to Wordpress, as they are invariably impressed at the smoothness of the move and how quickly they are reindexed in Google and how pleasant and helpful our team is. We work hard at this. No reason on this earth that web designers and programmers should be unhelpful and incommunicative.
There is no obligation for follow-up work. We're happy to help. But we are not happy not to be paid. Nor are we happy to have to send out a manhunt to get paid. Not only did Stuart Bruce not pay his invoice, he just disappeared without saying thank you or even letting us know the job was finished.
Repeated contact brought absolutely no response.
Apparently Stuart Bruce doesn't think much of web designers. Here's what he wrote about why decided to go with Typepad instead of Wordpress back in 2005 (emphasis mine):
I’ve experimented with both Movable Type and WordPress but decided to go with Typepad because that’s what I’m already using for several clients. As it has the ability to import/export posts I can always change the platform later.
Despite the recent problems with Typepad I still have faith in it. It remains a good solution for small businesses and organisations (although the Yahoo Movable Type offering might present a viable alternative). Movable Type and WordPress might both be better, but a business that doesn’t have an IT person needs something that it much easier to install and maintain.
Even in 2006, he's still cursing technology and throwing around the geek epithet (emphasis mine):
Typepad – despite the outages it is still the best platform to introduce people and if used with your own mapped domain is ‘business grade’ for SMEs/SMBs. Unless you are a geek or have an IT department to support you then WordPress.org and Movable Type are just too hard. Most SMEs/SMBs aren’t geeks, don’t have an IT department and don’t have time to mess around. Time is more precious than 0.0005% annual server downtime!
Stuart, you'd like your clients to hire professional PR people (who for inexplicable reasons generally cost far more than competent help setting up a weblog or even a good designer) but not competent tech support?
- Properly set up Wordpress will do wonders for your search engine results.
- A strong design will do wonder for your branding.
- Wordpress can serve as a full-blown website with advanced programming integrated into the core. Check out our Canadian life insurance site for what can be done in Wordpress, so there is room to grow. Unlike in Typepad where you run into a brick wall as soon as you want to leave the blog format.
- Wordpress is built on open source so your data remains your own and doesn't get surreptitiously encoded into the SixApart data hoard from which it is nearly impossible to rescue it.
In any case, Stuart Bruce is not using Typepad anymore. Being cheap up front cost him a fair amount of money (although very little trouble as he engaged us for Typepad to Wordpress) to get out of Typepad. Stuart did have a nice site as we set it up until he decided to go the DIY route and put in one of the worst contact form plugins I've ever seen (the original source is here for perusal and posterity: hopefully Stuart will correct this after he reads this article - free tips, saving money on his IT bill again).
Free IT Tips for Stuart Bruce/Wolfstar Consultancy
- Stuart: You'd have more luck with Wordpress if you'd had us build your contact form. Your pages are 70% unnecessary gunk for your shoddy DIY contact form Stuart.
- Stuart: your site is throwing a lot of 500 errors. If you hadn't cheaped out and gone with 1and1hosting.com you wouldn't have those. No need to blame Wordpress for the shoddy hosting you chose.
I hope for the sake of his clients that Stuart makes better tech recommendations when they are paying the freight than he does for himself.
Leaving Wordpress, Typepad and the web behind, I have a few general business tips for Stuart Bruce and Wolfstar Consultancy.
Free General Business Tips for Stuart Bruce/Wolfstar Consultancy
- Tip #1: when you ask for special consideration, it's considered good form to say thank you for a job well done.
- Tip #2: when you ask for special consideration, pay your bills promptly.
- Tip #3: when employing an SEO company (poor you Stuart, you thought we were just a bunch of web coolies to stomp on), don't try and pull a runner.
- Tip #4: Don't have old-school English biddies from your accounting department give lectures on "how things are done in England", i.e. "We only pay paper invoices, not online ones." You had no problems paying the deposit, I don't see why it was so difficult to pay the balance.
- Tip #5: Don't have your assistant lecture said director of web design and SEO company about how busy you are: "Stuart Bruce is a very busy man and director of this company. He doesn't have time to correspond with suppliers."
Thanks for nothing, Stuart. Chasing you around for payment for two months was actually worth more than the price of your order. Martin also really appreciated working over the weekend on your rush job and then receiving neither private thanks nor public acknowledgement.
I hope your clients treat you better than you treat your suppliers.
WordPress |
