EEConf 2024 is around the corner! EEConf 2024
In case anyone gets a similar problem, I was getting this error when trying to save the settings:
Notice: Undefined index: field_defaults in / …path to… /extensions/ext.md_character_count.php on line 443
And a few other errors - the settings were still saved though. As this was the first time I’d used the extension, I hadn’t realised that there were parts missing from the settings page. Line 443 refers to $_POST[‘field_defaults’], which didn’t exist, hence the error crashing the Control Panel.
Adding:
if (isset($_POST['field_defaults'])) {
before the foreach line (443) removed the error.
The reason it was occuring was that I’d tried to access the extension too early! Although I had some weblogs, I hadn’t set up any fields yet, and the extension doesn’t check for this.
What would be handy is adding the above if statement to the extension code to prevent the error appearing and when loading the settings page, display a message if no appropriate text fields were found in the weblogs informing the user.
In case anyone gets a similar problem, I was getting this error when trying to save the settings:Notice: Undefined index: field_defaults in / …path to… /extensions/ext.md_character_count.php on line 443And a few other errors - the settings were still saved though. As this was the first time I’d used the extension, I hadn’t realised that there were parts missing from the settings page. Line 443 refers to $_POST[‘field_defaults’], which didn’t exist, hence the error crashing the Control Panel. Adding:before the foreach line (443) removed the error. The reason it was occuring was that I’d tried to access the extension too early! Although I had some weblogs, I hadn’t set up any fields yet, and the extension doesn’t check for this. What would be handy is adding the above if statement to the extension code to prevent the error appearing and when loading the settings page, display a message if no appropriate text fields were found in the weblogs informing the user.if (isset($_POST['field_defaults'])) {
I had this problem tonight as well - I was setting up my base EE install and hasn’t added any fields yet but tried to enable and save the extension.
The above fix works as long as you remember to close the if statement on line 450(ish).
The absolute first thought that comes to mind when I read this is: T-W-I-T-T-E-R! hahaha.
I’ve gotten a little hooked on it. Enjoying it much.
Second thought (if this hadn’t been just for the CP, which I think it is) … hhmm, I wonder how hard it would be to integrate with SAEF or FreeForm to submit Tweets via the Twitter API. That way you can literally LOG your own Tweets.
Heck, even if it isn’t possible, it would help ‘blog’ writers get-to-the-point with short entries 😊 hhmm
I have been unable to successfully use this extension in a MSM setup. I haven’t been experiencing any of the errors outlined earlier in this thread, but when I try to apply some settings to a second MSM site the extension settings are blank, and in turn erase the settings which existed in the original site. This functionality of this extension is very cool, and it’s very frustrating that it’s advertised as MSM compatible but maybe it’s a conflict with other extensions i’m using? I’ve only been applying the extension to text input and standard textarea custom fields.
Have others been able to use this extension on more than one MSM site?
Sure, Ryan.
EE 1.6.8, Build 20090723
Extensions:
LG Add Sitename (v.1.2.0) Edit Tab AJAX (v.1.2.2) File, by Mark Huot (v.3.1.1) Edit Alert (v.1.0) jQuery for the Control Panel (v.1.1.1) MD Markitup (v.1.6.1) URL Field Extension (v.1.0.5) Edit Menu (v.1.0.2) DC Required Category (v.1.0.5) LG Live Look (v.1.1.2) NSM Publish Plus (v.1.1.1) Fresh Variables (v.1.0.1) FieldFrame (v.1.2.1)
Thanks for looking into this. Very much appreciated!
I’ll take a look.
On a different note: I’m curious why you choose to use Mark Huot’s old File extension when you have FieldFrame installed. With FF, you can use nGen’s File Fieldtype, which is much nicer and has more features.
Simple answer: rewrite filenames, plus more granularity regarding resizing. More complex answer: A recent update of Fieldframe broke some MSM compatibility (i.e. custom field names now need to be different per site). Ironically, this was the main reason why I had originally switched from Huot’s to Ngen’s extension. So, I switched back again. That’s how it goes sometimes….
However, I may be switching back again to File Field (!) as the main bugbear with Huot’s File extension is that you have to save the entry to upload the image. IIRC that isn’t the case with File Field. Will be checking this out this afternoon.
Well, you’re right. This is not working in a Multi-Site setup. I’m trying things, but if anyone else wants to take a look, you can fork this on GitHub: MD Character Count.
Well, you’re right. This is not working in a Multi-Site setup. I’m trying things, but if anyone else wants to take a look, you can fork this on GitHub: MD Character Count.
Ryan,
I had a quick look at this just now and ran into the same problem as somebody else mentioned with regards to line 443.
I’ll make a patch that deals with that problem first, before looking at the larger problem which is the MSM functionality.
It looks pretty complicated for just a cursory glance, so I’ll have a deeper dig into it over the weekend.
I think I found the problem…it’s inside of
ext.md_character_count.php
swap out function save_settings() with
function save_settings()
{
global $DB, $PREFS;
// load the settings from cache or DB
// force a refresh and return the full site settings
$this->settings = $this->_get_settings(TRUE, TRUE);
// unset the name
unset($_POST['name']);
$good = array("", "", "","", ""); // This is where all this really comes in handy...
$bad = array("\'", '\"', '\\', ";", ":"); // These 2 items help keep bad information from being entered into the format string.
foreach ($_POST['field_defaults'] as $key => $value)
{
unset($_POST['field_defaults_' . $key]);
$_POST['field_defaults'][$key]['count_max'] = ereg_replace("[^0-9]", "", $_POST['field_defaults'][$key]['count_max']);
$_POST['field_defaults'][$key]['count_format'] = str_replace($bad, $good, $_POST['field_defaults'][$key]['count_format']);
}
// add the posted values to the settings
// This was the original line. We need adjust the value of $this->settings instead of creating a new variable $settings
//$settings[$PREFS->ini('site_id')] = $_POST;
$this->settings[$PREFS->ini('site_id')] = $_POST;
// update the settings
// $settings has been changed to $this->settings
$query = $DB->query($sql =
"UPDATE exp_extensions
SET settings = '" . addslashes(serialize($this->settings)) . "' WHERE class = '" . MD_CC_extension_class . "'"
);
}
So, the only change I made was to change $settings to $this->settings because we are adjusting the value of $this->settings (which should contain all of the existing settings for all sites) instead of creating a new variable $settings.
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.