-
- 55 Posts
Hi Bob and others... I have used Newspublisher on numerous sites, all of which I have updated to revo 2.2.13 and have had no problems. However, I just created a new 2.2.13 site (not updated from an older revo), installed Newspublisher via package management and it doesn't work. I have been struggling for the past few hours trying to get NP to work and I just can't. There are no errors in the log. Here's what happens:
1. On a test page, click on NP edit button.
2. Edit page fields.
3. Click submit, page refreshes and nothing has happened.
4. Resource hasn't been updated.
I also tested this with creating pages with NP and same result. I've ensured ACL/permissions are correct. Any ideas?
Thanks,
K.
-
- 24,544 Posts
Assuming that you can save resources on the site outside of NewPublisher, I can't think of anything that could cause that without generating an error message at the top of the form.
For Permissions, NewsPublisher requires both 'save_document' (in the Context Access ACL entry) and 'save' (in the Resource Group Access ACL entry). If the resource contains MODX tags, you'd also need the allow_modx_tags custom permission and the allow_tags_in_post System Setting to be on. One of the last two would be my best guess on what's wrong.
-
- 55 Posts
Thanks for the prompt response Bob. Unfortunately I've tried everything I can think of. I even gave my test user full admin permissions to both web and mgr contexts and it still didn't work. I also tried with the main admin account itself and still no dice. Something is seriously wrong here as NP works flawlessly on my other sites and I have it set up identical to those. The sites are even on the same server / environment. I guess I'll nuke the site and try re-installing everything from scratch - just grabbing at straws now.
Thanks,
K.
-
- 24,544 Posts
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
-
- 55 Posts
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.
-
- 24,544 Posts
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.
-
- 24,544 Posts
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.
-
- 55 Posts
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.
-
- 24,544 Posts
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
[ed. note: BobRay last edited this post 10 years ago.]