Newspublisher not submitting / creating / updating Revo 2.2.13 - My Forums

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

wallacio — Apr 08, 2014, 04:18 AM

Bob/Kevin,

To chip in on the initial problem you were trying to solve. I had exactly the same issue, whereby submitting the edited form resulted in the form being redisplayed without saving, or error. I added a bit of debugging to chunks and snippets and discovered that the conditional output modifiers for the error messages weren't behaving in npOuterTpl. For example:

[[!+np.errors:ifnotempty=`[[!+np.errors]]`]]

Even though np.errors was not empty, it wasn't being rendered. I've removed the conditions from the placeholders and the reasons for the form not being saved are now being displayed:

[[!+np.errors]]

I've noticed inconsistencies between installations or versions for conditional output before, but nothing that I could explain or be bothered looking into. Anyhow - looks like I have NewsPublisher working as I want, I just need to remove the validation for 'content' not being present (intentional) in my edit form!

Thanks both for your contributions
Andrew

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

BobRay — Mar 15, 2014, 03:15 PM

I would expect that the time between fetching the TVs and saving them again would be well under a second. You could measure it on your server if you want to.

Put this code just above the code I posted earlier:

$mtime = microtime();
$mtime = explode(" ", $mtime);
$mtime = $mtime[1] + $mtime[0];
$tstart = $mtime;

And this code just below the runProcessor('resource/create') call:

$mtime = microtime();
$mtime = explode(" ", $mtime);
$mtime = $mtime[1] + $mtime[0];
$tend = $mtime;
$totalTime = ($tend - $tstart);
$totalTime = sprintf("%2.4f s", $totalTime);
echo .=  "
Total Time: " . $totalTime;

I'm not sure if you'll see the output, you may have to write it to the error log or to a chunk.

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

entica — Mar 15, 2014, 12:39 PM

Ok perfect! I can live with "very small". 0 chance would be ideal, but realistically the chances of having several people hit save all at the same time is pretty low. They will all most likely be at least a couple seconds apart if not more. Of course this gets skewed with the more people I have trying to save, database lag, connection lag, etc. At most I think it would only ever be 3 to 5 people.

However, now that I think about it more, having previous TV's wiped out would be very very bad in this situation. Even if there's a 0.001% chance it could happen that is enough for me to consider an alternate method. Maybe I'll look in to modUsers some more. On top of this, it's all going to be done over a poor wifi connection which could mean taking 5 to 10 seconds to perform the save. I'm not sure if this is an issue or not as I presume NP fetches / writes TV's pretty much instantaneously server-side regardless of how long a client connection is taking?

Thanks,

K.

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

BobRay — Mar 15, 2014, 11:15 AM

I just checked the code in the NP class file and it does still save all the TVs, but it does so just before the resource is saved, so the probability of overwriting a TV with an old value is very small but not 0.

Here is the code (around line 1421 of the core/components/newspublisher/model/newspublisher/newspublisher.class.php file:

            /* *********************************************
             * Deal with bug in resource update processor. *
             * Set $fields to current TV value for all TVs *
             * This section can be removed when it's fixed *
             ********************************************* */
            if ($this->existing) {
                /* @var $t_tv modTemplateVar */
                $t_resourceTVs = $this->resource->getMany('TemplateVars');
                $t_resourceId = $this->resource->get('id');
                foreach ($t_resourceTVs as $t_tv) {
                    $t_tvId = $t_tv->get('id');
                    $t_value = $t_tv->getValue($t_resourceId);
                    $fields['tv' . $t_tvId] = $t_value;
                }
                unset($t_resourceTVs,$t_resourceId,$t_tvId,$t_value);
            }

You could try removing it and clearing the site cache. If the bug is still there, some other TVs that are edited in the NP session will be set to empty values.

[Update] I finally found the bug report and it appears that this has not been fixed: http://bugs.modx.com/issues/5965

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

entica — Mar 15, 2014, 08:49 AM

After some testing it appears as though the TV bug has been fixed and it doesn't appear as though NP tries to send all TV values. No matter how hard I tried to have things not work, it worked every time regardless of who loaded the resource first, who saved first and even perceptual saves at the same time. Works like a charm and I'm much happier keeping the data in TV's within the appropriate resource. This also makes life much easier for me in regard to retrieving the data and sorting it via pdoResources. However, before I declare this a success and the direction I will take, I need to expand my testing where I have 5 to 10 saves trying to commit near simultaneously.

Thanks again for all your help! I'll be sure to drop by your site and support you in some way (sitecheck/book/donation). I have leaned on so many of your previous posts, information on your site, contributions, etc. I owe you a great deal.

K.

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

BobRay — Mar 14, 2014, 10:38 PM

By far the cleanest and most efficient approach would be to extend the modUser object and put the extra fields there, especially if the fields will be used for searching or sorting. Basically, this gives you the equivalent of an extra user profile with custom fields. Much cleaner than having to deal with the extended fields which are stored as a JSON string, arrive from get() as an associative array, and are almost impossible to use in a search or for sorting.

As for the TVs, unfortunately (last time I checked), the resource/update processor had a bug that required you to send all TVs if you intend to save any, otherwise it blanks out the values of the ones you don't send.

For you, that would mean that the TVs will all be saved when they save the resource, undoing any of the other people's TVs that have been changed in the meantime. TBH, I can't remember if I load the other TV values when the form is launched or just before the resource is saved. If it's the latter, the odds of an overwrite would be much lower.

If this bug has been fixed, the code to add the other TVs could be removed from NP. In that case, you'd be golden since the TV values are in a different table and updating some of them would have no effect on the rest.

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

entica — Mar 14, 2014, 10:21 PM

Hmm, sounds like I need to do some real-time experimentation with a few friends. I don't think I'm worried about changes being undone by future saves as every individual has their own unique set of TV's for the same resource. I would make a custom NP for each user so they are presented with only the TV's that are unique to them. However, there would be about a 100 of these TV's assigned to the 1 document and potentially 10 people all trying to save at the same time to their respective TV's. I guess my question would be that if someone save's their TV's, will it undo someone else's TV's? I'm presuming it will since their version of someone else's TV's would be blank upon submitting and not merge.

Anyway, the solution I'm working on right now to get around all this is using user extended fields and moving all the data there that I would otherwise use TV's for. This has the benefit of allowing numerous people to "save" at the same time since they're all writing to their own individual profiles. It also seems a lot quicker as it doesn't have to go through the usual stuff that a resource goes through on save (updating cache, etc.). However, my large problem here is that I'm having a heck of a time working with the extended data. In the past I've always used getResources & output filters in clever ways to manipulate data. With extended profiles I'm having a rough time as A) my JSON knowledge is weak and B) my PHP is weak. I'm sure it would be trivial for a true PHP programmer to write something that would extrapolate and manipulate the extended field data. I'm simply trying to accomplish it by tons of nested pdoUser and pdoResources / getResources calls. My page that tabulates the data is handling several hundred calls / calculations and is woefully ineffective. Time to brush up more on PHP and ModX's Dev guide. I'm also concerned that extended fields may have some kind of hidden limit. I may need to store up to a 1000 extended fields per user.

Thanks as always for your insight and listening to me ramble on

K.

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

BobRay — Mar 14, 2014, 08:42 PM

Thanks for the kind words.

I'm not really the person to ask about simultaneous saves. My guess would be that the lock occurs at the MySQL level only for the few milliseconds that it takes to save to the DB, and that any other simultaneous saves would cause a delay but would still work. I don't think you'd ever get an error message in MODX.

The real problem would be that later saves would undo the changes made by the earlier ones, since they'd be saving a modified document that could have been loaded quite a while earlier.

Loading a document in the Manager might lock it, but NewsPublisher doesn't. You might be better off having your users operate in the Manager if there will be near-simultaneous edits.

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

entica — Mar 14, 2014, 10:54 AM

Hi Bob,

I did a 100% complete re-install of everything from scratch and now it's working! Go figure. I did have about 8 other packages installed before, so maybe something got borked with the previous setup. Anyway, sorry to waste your time with this and I really should have tried a fresh install first before posting here.

While we're here, I have another question about NP. Theoretically, if I have 10ish people all trying to edit/save the same document at roughly the same time (maybe 5 seconds apart from each other), what would happen? I presume the document gets locked when edited? Will an error message return? Does the lock happen when the document is first opened or when it's saved? What happens if the permissions allow for lock stealing/override? Basically I'm looking for a way to have multiple people edit the same document at approximately the same time, but I'm presuming this isn't feasible without some kind of complicated middle-step snippet that does some kind of queuing. Any insight in to this situation would be greatly appreciated.

PS. I also want to take this opportunity to thank you profusely for your continued level of commitment to ModX and it's users. Your contribution to this platform is nothing short of staggering. Myself and many unspoken others greatly respect and thank you for your dedication.

Thanks,

K.

Re: Newspublisher not submitting / creating / updating Revo 2.2.13

BobRay — Mar 13, 2014, 10:17 PM

Just a note, the allow_modx_tags permission is not a standard MODX permission. It's part of a custom policy installed with NewsPublisher, so even a user with full rights wouldn't necessarily have it. Nor would they get past the need to have the allow_tags_in_post System Setting on. That said, those would only come into play if the Resource contained MODX tags.

A couple of other thoughts: A mismatch between the various date/timezone settings will sometimes keep things from saving, as will a character set problem, but both are pretty unlikely as causes of your problem. SiteCheck would check both of those for you and would also check the integrity of the modx_site_content table (and a bunch of other things). I wouldn't guarantee that it will solve your problem, but it's handy to have around in any event. http://bobsguides.com/sitecheck-promo.html