Michael4fm

Oops … sorry. Have entered a “bug report” through the correct route, and will mark this as ‘resolved’. In the very unlikely event I find any other bug in future ( ?? ) I’ll take the right action first time!

Thanks for the feedback both ??

@jgarcia: Oh … ?? thought it would be relatively easy …ish, once I knew the right direction. Probably not worth me employing someone just because I’m so anal!

@dotnordic: That sounds like a direction worth exploring. Maybe won’t be ‘precise’, but at least it could elimininate acres and acres of white space. Thanks for the idea ??

I’m glad that I’m not going mad … but I’m a bit confused on your conclusion

I think the way I outlined the functionality before is how it should work, otherwise things get confusing when you deliberately attempt to have a blank value

It’s perhaps unclear from this statement whether you think a blank value SHOULD be allowed to ‘override’ the default or not. Personally, now that I know how it will behave, it’s not a huge deal. I mention it purely in case someone else comes looking at this thread (though if it were a vote, I’d cast mine FOR allowing the occasional blank value while getting the benefit of a default ‘suggestion’ in most cases).

[I’ve got round the problem of introducing new fields on new posts that don’t exist on old ones by adding an ‘if’ statement – if it’s blank, use this value. If you need to change a value on old posts, you can do a ‘search and replace’ … though it takes a little thinking about if you need to change 4 to 3, 3 to 2, 2 to 1, etc!]

Sorry, just reread your comments, and maybe I’m still not ‘getting’ what you’re saying.

Re a blank field: no, that makes no sense. A default value defines a value to use when the field is created, so you can’t have both a default value and have a blank value — it has to be one or the other.

Maybe I should be saying “suggested” instead of “default” … so the “suggested” value is pre-filled. If you do nothing and just save the post, this value is used, or you can choose to use a different value, including a NULL value, when you save it.

So what I’ve done is have MICHAEL4FM as the ‘default’ (in my world ‘suggested’ value) in CCTM but on creating this post I’ve erased this value so that the stored value should be NULL or blank … which is what it is showing on the ‘edit post’ screen.

Thanks for such a quick response!

Your explanation of how it SHOULD work matches my initial assumption. On reading your comments I thought maybe it was just ‘me’, especially as I was basing my comment on items I’d previously created and given a value to a field then later attempted to set it to ‘blank’ by deleting the value and resaving the post.

However, I’ve just created a new post … the ‘default’ value in CCTM is for “CAPTION” is “Michael4fm”. I created a new post and deleted the default value for this field so that the value is ‘blank’ … still is when I edit the post, then published it. However, it shows as “Michael4fm” on the public side of the post here. Yet the value in the post itself is blank (screenshot below the actual post), and has been since creation … so it must be getting the value from the CCTM default … mustn’t it?

To double check I’m not going totally mad, I’ve just gone into CCTM and blanked out the default. When I then view the post the “Caption” field is also blank. When I restore a default value in CCTM, that value then appears in the post … even though I’ve not changed the post at all.

So while I understand what it SHOULD do (and can understand what you mean about the complexity!) what it ACTUALLY seems to be doing is using the default value if another one isn’t specified … or is that just me and I really should be looking elsewhere for the cause?

Just something to consider – before you commit too much time to your plan – it’s really easy to set up a ‘virtual’ server on your local machine using free software from ServerPress.

This would mean you could set up an exact duplicate of the site on your local machine for testing, play around as much as you like, then upload any new or changed files by FTP and export / import the actual database if you also need to.

Yeah, where there are predefined options – dropdown fields and radio buttons, but perhaps also anywhere else a ‘default’ value has been specified … text fields etc.

I’ve resolved this .. kind of. Found a way to use an FTP’d image that doesn’t use the WP image function. So my own question is resolved.

Might be worth putting an answer here though for anyone else researching the same question. ??

Thanks for the update drec.

My ‘login’ problems seem to have solved themselves (magically, I guess, cos I’m not aware of doing anything to fix it!)

Weird quirks like not accepting a leading “/” in image and file paths, and for some reason doesn’t like anything but “default” permalinks. Not a big problem right now, but might be when I’m working on some other sites.

So I’ll stick with Wampserver for now, as I’ve invested quite a bit of time in setting it up, but if the permalink thing becomes an issue, I’ll give ServerPress a try. ??

Tip for others who come looking at this thread:

Might be worth STARTING with ServerPress! ??

Most certainly will, drec. Likewise if / when you do, post it up here in case it works for me too!

At the moment I’m recreating the wp-config file whenever I need to work on a website, then just leaving the browser open so I remain logged in as long as possible. Not ideal, but at least it works!

Me too … upgraded to WP3.5, playing with BFA Montezuma theme, seems to disable ‘drag and drop’ on the admin | widget screen.

(Tip for others … doesn’t SEEM to have any other negative effects that I’ve found so far, so if you’re already using it and there’s no suitable replacement, you could maybe deactivate it, do whatever you need to on the ‘widgets’ screen, then re-activate it.)

Not sure if you’ve solved this, as it’s a few days old, but just in case and as a temporary workaround …

I’m having problems getting back into the WP dashboard on a local WAMP server too.

I’ve found that if I delete the wp-config.php file (or rename it actually, just in case) it forces the system to recreate a wp-config.php file, then says ‘OK go ahead and install WordPress’ … then says ‘oh, you already have’ … then presents me with a sign-on screen that let’s me in to the dashboard to do whatever I like.

Downside is it only works for that session, so you have to repeat if you come out of the admin side of WP then want to go back in later, but it MIGHT work for you as temporary / emergency access? (I’ll keep hunting for a ‘permanent’ solution!)

May be kind of related, but if not seems as good a place as any to add the comment, rather than start a new thread.

Plugin (which is fantastic and produces beautiful emails, even before tweaking it a bit!) only seems to work on ‘plain text’ emails, so where users can choose between receiving html and plain text if they choose html it overides / circumvents using this plugin. I’ve cheated right now by hacking other plugins where I can so that when users think they’re choosing “html”, they’re really choosing plain text! ??

Perhaps your examination of Jetpack integration might result in a more general ‘intercept’ of html produced emails and application of the ‘better emails’ styling?

Hi Mished

I don’t think there is a shortcode. The plugin seems to rely on users being able to access their ‘backend’ profile page. When the plugin is activated a list of categories they can subscribe to is there.

I say this because I’ve been looking for a way to present these choices ‘front end’ too. If the ‘front end’ bit is important, there’s another plugin – Subscribe2 – which does a similar job. It isn’t as flexible – either everyone gets ‘instant’ emails or everyone gets ‘digests’. The choice is sitewide by you, not down to individuals. You also need to purchase the ‘front end’ bit from someone else, but it’s only $2.

Hope this helps. If you DO work out how to get this plugin to display front end, let me know OK? I’d really like to do the same!

Longer answer, as I wrote it out for moneybar

The theme file has several CSS files. I’m using BP-Default 1.5 but I’m sure the three column version is very similar. One is called “default.css”. Near the top, there’s a section that deals with CSS code for the ‘header’ section. It’s a very lengthy entry for

#header {

.. which is the first thing in my ‘header’ section. It contains loads of entries about how it should be presented in different browsers – rounded corners for Firefox, different gradients in Opera, etc.

At the end of all of this, I just inserted a new line:-

background-image: url( ../images/default_header.jpg

There was already a file called this in /wp-content/plugins/buddypress/bp-themes/bp-default/_inc/images/

I renamed this original one (just in case!) then uploaded the picture I had uploaded as the header image (I’m just using one, not randomly rotating them … I’m sure there’s a clever way to do that too, but I haven’t thought about it!) named as default_header.jpg

That was all there was to it. Now when I view the posts with featured images attached, I see the same header as the rest of the site, and as I see for posts that don’t have featured images.

I THINK it has to do with BP now (apparently) using ‘featured images’ to generate the header. Not sure – but it was that snippet of info that pointed me in the right direction … kind of.

Anyway … seems to have worked for me. Only completed it a few minutes ago, but it has passed the quick tests I’ve done. Luckily I don’t plan on changing the header image a lot once the site is completed, so it shouldn’t be a problem for later. If you change yours often, it MIGHT work if you use a different path / address for your background image … tell it to look at the one you’re using already, rather than copy it into the directory I’ve said. Haven’t tried it, but it seems logical that it would work!