Thread

Just upgraded to 1.6.2 and something appears to have “broken”... our SAEF for paid member posts used to default to status “Open”, as set in our settings:

Admin -> Content Management -> Paid Member Posts -> Administrative Preferences -> Default Status: OPEN

Now they default to closed. Help!

Make sure that the weblogs they post to have a status group assigned to them, ewitch, or only Super Admins will be able to post anything but “closed”.

Derek,

I’m having this issue as well.
I created a site for a client with a fresh install of EE 1.6.2 (last build of it).
I’ve since upgraded to ExpressionEngine 1.6.3

Today I just tested it with a “semi-admin” member group and all new posts default to “Closed”

I definately have a Status Group assigned to the weblog as well
I’ve only tested this on EE 1.6.3 so no idea if this was happening on 1.6.2 as well.
For Admin it works fine… sets to Open

Thank you sir 😉

UPDATE: setting the status to “open” instead of “Open” seems to correct the issue.
This is strange because the actual status in the CP Status Config is “Open”

I’ve also always used “Open” instead of “open” on tons of sites before in the same configurations with no trouble at all…

Pie Man are you talking about the status you use in the weblog entries tag status= parameter?  Or in naming of custom statuses?  I believe your post is missing a bit of context.

Derek,

Sorry… I should have mentioned… though I sort of thought the first post was building a bit of the context :lol:

What I have is an SAEF form for submitting weblog entries.
I have a Status form field that’s hidden, and contains the value “Open”

As an Admin, when I use the SAEF, everything comes through as “Open”.
As another member group with all the correct permissions, using the SAEF, everything comes through as “Closed”

I’m just using the default status groups that come pre-configured with EE, which are “Open” and “Closed”

For the heck of it, I switched the naming of the SAEF Status form field to “open” (lowercase “O”). It now works fine.

To further this, I have used this general method (using “Open” on SAEF forms) numerous times without any trouble. This is currently the only site I have on EE 1.6.3.

I hope that clarifies things 😊

I have long ago learned to never make assumptions, particularly when a user replies to an existing issue. :-D

But yes, in that context, you are right.  The improved status validation would require case matching, which would only come up in this instance with a manually created status input field.

@ewitch - is this resolved for you as well?

But yes, in that context, you are right.  The improved status validation would require case matching, which would only come up in this instance with a manually created status input field.

Ok, but if the status in the CP is set as “Open” shouldn’t it be case sensitive to only liking “Open” on the front end, instead of “open”?

Thanks 😊

“Open” is the display name, but the form value in the cp is also ‘open’, lowercase.

<option value='open' selected='selected'>Open</option>

Fine… fair enough… hahaha :lol:

I could pick at this more, but it’s not a big deal 😉

Thank you for your time 😊

I could pick at this more, but it’s not a big deal 😉

Can I then instead?

Seriously though Derek I was just wondering why there is open in the database but Open comes up in the drop down as opposed to when you make your own status’ they get saved in the same format that you type them in?

I only ask as I remember someone having the exact problem of not getting any results returned from their weblog tag when they were using status=“Open” and I told them that they needed it to be “open” instead. This got them working right away but I was just curious with my limited knowledge of coding as to why this is?

Thanks.

Best wishes,

Mark

Lowercase is typically a better convention when programming, but capitalizing for display adds weight and significance.  MySQL is case-insensitive by default, i.e. these two WHERE clauses would have the same results:

WHERE status = 'foo'
WHERE status = 'Foo'

The issue with case sensitivity here and in the example you mention, which is involving relationship data, is that PHP is being used to compare the status, not MySQL, and looking in an array of valid statuses:

var_dump(in_array('Foo', array('foo', 'bar')));
// bool(false)

And to save you from asking, yes, this is being modified in future versions of ExpressionEngine.

Hi Derek,

Thanks for the info on this, much appreciated. Just wondered what the reasoning was so thanks for that 😊

Best wishes,

Mark

@ewitch - if you are still having problems, you can PM me to reopen the thread, but with both the current solution and the future modification explained, I am going to mark this as resolved.