So it looks like your server configuration is blocking the web user (or php) from accessing that other php file…  I would check with my host and see if they had some thoughts as to why the server is blocking access…  if this is a nginx setup, there are settings that can block that…

if a topic exists in forum with a same name, the slug is adjusted just as wp would for a duplicate post title (believe its done with core wp function)…  so if you post title (and slug) of Paris and it already exists, the slug will become paris-2…or the next number in sequence if many with same slug..

we can make note of the request for the blog linking plugin…  it is currently being overhauled, so ‘might’ be possible…

you can always change the title and slug once the topic has been posted using the forum tools (https://simple-press.com/documentation/codex/faq/how-to/how-to-delete-a-topic-or-post-and-other-tools/) and editing the topic title which also allows you to change the topic slug…  its available on both forum and topic view…

Thanks for the title clarification, Papa.

About the main first problem and if you don’t take it personal: I am the server administrator. It doesn’t makes much sense to me, unless I am not understanding what you are saying. The problem shows up only if I blog link a post with an author different than admin. So which other php file are you referring to? When sp-linking-blog.php is called from post.php with author same as admin everything works fine. It seems to me that there is something in the plugin related to permissions which doesn’t allow admin to blog link a post published by a different author. 

Isn’t that error thrown after validatePermission() in case $p aborts? Where is the validatePermission() function located? I really need something to locate the origin of the problem (and to fix it of course), please. Any idea?

Well – the first thing to clear up is the error message. This is a message that SP forces when the validation of permissions fail. However – in terms of your reported issue it is a red herring.

The routines that generate this error are only called on a new blog post/forum topic. Or – as I suspect in this case – an attempt to create a new forum topic from an existing blog post. These routines are NOT called from a normal blog post edit action. So we are looking for something different.

An edit action does not appear to care about the user making the change if a linked topic is already in place. The only thing I can see in the code that might thwart the ricess is the line iof code:

if ((isset($_POST[‘sfedit’]) && $_POST[‘sfedit’] == true) || ($links && $links->syncedit == true)) {

In other words – is the topic update in edit checkbox ticked and is the option to sync edits set as on in the forum admin panel.

Yes, they are.

However, I see no correlation with them being on or not and the error I get. 

This error hits only when the author of a blog post is different from admin and admin is the one updating the post with the blog linking option ticked. What you posted doesn’t seem to show any relation with whomever the user is.

1. It’s an existing, published post.
2. There is no equivalent topic on the forum, though (hence I want to use blog linking to create it).
3. The post author is ALPHA
4. ALPHA is Organizer group member
5. Organizer group have full access permissions.
6. Blog linking chosen forum, though, grants only LIMITED ACCESS (can reply to existing topic, but cannot create new topic).
7. ADMIN opens the post, adds excerpt, checks the blog linking boxes and clicks on UPDATE POST.
8. The post updates but topic in not created in the forum and the infamous error is thrown.

If you replace all ALPHA with ADMIN in the process above, everything works correctly and the new forum topic is created.

The error seems to be caused here, as I already stated:

$p->validatePermission();
if (!$p->abort) {

// blog linking process

} else {
trigger_error(‘Linking – Permission’.’: ‘.$p->message, E_USER_WARNING);
}

and therefore something goes wrong on validatePermission()

It seems to me that linking blog plugin DOES NOT recognize who makes the action and their privileges, but the author of the post and their privileges. Hence, when ADMIN (who should have all permissions) performs a linking blog plugin action on a post whose author is else than ADMIN and has no permissions, that error is thrown.

I really hope to have been clear this time. If the plugin doesn’t allow administrator to operate on every post, then the plugin is useful only for new posts. Running a website with hundreds of events posted each and every day is a bit more complicated than that and I really hope that there is a workaround to allow admin to be admin. And I hope you can help me to find this workaround soon, because frankly I’m already running out of time.  

I’ll be slightly happy to even use brutal force at this point (code wise, of course)…

Would something like 

if (!$p->abort) || USER IS ADMIN {

work? If yes, what can I use in place of USER IS ADMIN? Conventional WP 

And if not possible and I have to figure other ways around myself, could you at least tell me where validatePermission() function is and what checks it does?

Thanks.

There is no equivalent topic on the forum, though (hence I want to use blog linking to create it).

You did not say this or make it clear in your first post. You just said edit and existing blog post. As I said in my reply above – the error in the log can only occur when a new topic is being created – not edited.

With the information that this was, indeed, a brand new forum topic then yes – we can look elsewhere. And that is probably a lot easier. So – do BOTH the users in question have the Simple:Press permissions to ;start topics’ AND ‘create blog linked topics’ – in the particular forum in question?

You ave probably answered this question above bit I still think you should check. And remember that even though a different person may be editing the blog post – the author ID remains the same. 

I metioned CREATE NEW TOPIC on the forum. I thought it was clear that there was no topic on the forum.

U1 – One user is ADMINISTRATOR of both wp and sp.

U2 – Then there is the author of the blog post, which is a member with full access permissions.

The forum where the new topics should be created via blog linking plugin though grants only LIMITED ACCESS permissions to ALL the user groups existing, meaning that NO user group can create a new topic on that forum. So, U2 cannot create new topics on that forum.

That is why I need U1 (administrator, should be capable of having all permissions) to do the job, by enabling linking blog action bit on the published blog post and updating published blog post.

On user groups, U1 appears as a member (like author – U2) and therefore in theory he has no permissions to create new topic on that forum either. However, it is also administrator and hence when he blog-link his own blog posts, the new topic on that limited access forum gets created successfully.

But not when he blog-link someone else (U2) blog posts. 

I need the plugin to ovverride permissions if the user performing the blog-linking action is the administrator, no matter who the blog posts author and its privileges are.

To try with different words: there is a case scenario where the forum host of the blog-linking plugin grants only limited access to everybody (create new topic disabled) and even administrator cannot ovveride those limitations, but for himself. The reason why that forum grants only limited access permissions is that is exactly a forum which should host the events topics (from blog posts), so that users can reply, but cannot create their own.

not sure I follow…  so U2 wants to create the linked blog post, but cannot since he doesnt have create permission… so U1 goes in to edit the post and link it… but since he is not author, it doesnt take… 

is that what you are saying?

@mr-papa – I have a little trouble as well. As far as I can work out we seem to have been asked to change our permissions/user group system to accommodate people creating topics who have no such permission to do so.

If that understanding is correct, then we would be most seriously reluctant to modify a structure that is working well with a change that runs counter to its whole purpose and that adds no overall value.

The user in question should really be placed into a user group/permission set for the forum in question with the correct set of credentials to do the job.

If I have misinterpreted the request then apologies – perhaps you could couch it in simpler terms.

Also – I sense some confusion over the role of a WordPress Administrator. A person in this WP role is not, automatically, a Simple:Press Admin. They are subject to the same user group/permission structure as all other users. If the desire is to make them an SP Admin then they need to be granted that status.

The user in question should really be placed into a user group/permission set for the forum in question with the correct set of credentials to do the job.

No, it cannot, as I have already explained, because that forum is specifically there to accommodate topics created via the blog posts linking plugin and no other users but administrator can create new topics on that forum directly. If I give that user permissions to create new topics, then he will be able to create them also outside of the blog linking plugin, directly in the forum layout.

Also – I sense some confusion over the role of a WordPress Administrator. A person in this WP role is not, automatically, a Simple:Press Admin. They are subject to the same user group/permission structure as all other users. If the desire is to make them an SP Admin then they need to be granted that status.

I don’t know why you keep getting confused on things that I have clearly explained. U1 – One user is ADMINISTRATOR of both wp and sp. I don’t have the desire to make them an SP admin, they ARE an SP admin, already.

The administrator should bypass any restrictions, due to its super moderation role. The issue is very simple: when an admin try to blog-link a blog post made by a user with no permissions to create new topics, he is not allowed to. This is faulty, whatever you want to try and tell me. It is exactly because a user cannot do certain things that there is an admin who has the power and permissions to override that user limitations. Your plugin limits administrators native purpose, which is, among other things, to perform actions on a users’ behalf which otherwise that user couldn’t perform itself, given its role limitations.

Nobody has asked you to modify the plugin, if you don’t think it’s worth to improve this aspect, but to suggest a workaround or fix for my situation. It might not be a common one, but it is still a totally legitimate and obviously possible one.

I haven’t forced any settings. I have forbidden creation of new topics in a forum, but to admins; and admin cannot create new topics either when using the blog linking plugin on other authors blog posts. And this is against the natural admin privileges.

Now, if you would like to help me out, please: where do I have to look at to do the following:

if is_admin() create the new topic from blog-linking always as admin and not as the blog post author (since as blog post author doesn’t work if author has no permissions to create new topic).

Something as brutal as

if (is_admin()) {
$p->newpost[‘userid’] = ‘1’;
} else {
$p->newpost[‘userid’] = $post->post_author;
}

creates new topic indeed as admin (no matter whom the author of the original blog post and its permissions) and the new topic shows the link back to the original blog post. However, the original blog post does not show the link back to the newly created forum topic (and yes, I have set the right two-ways settings on the plugin options).

As I stated already on my second post above, it seems that the origin of all is on the 

$p->validatePermission();

bit. Is there a way to have validatePermission() not returning ABORT if is_admin() is true? And if you don’t want or can’t answer, can you please tell me where the validatePermission() function is located, as I already asked in my second post above?

Thank you very much.

You know I am going to have to say it – but if you can be a little more polite and less confrontational then we can probably arrive at some sensible conclusions a little quicker. I am not actually stupid.

So you have said:

Nobody has asked you to modify the plugin, if you don’t think it’s worth to improve this aspect, but to suggest a workaround or fix for my situation. It might not be a common one, but it is still a totally legitimate and obviously possible one.

Actually – essentially you have asked for us to modify things and no – there is absolutely nothing legitimate about opening a backdoor to bypass permissions as you suggest – no matter what type of user we are talking about. 

What you can do is alter your code of course. And meanwhile we can discuss the merit of putting some filters in place that would allow a user to make permanent changes with no compromise to the core.

However – if you want to make local edits for now then you should make them in the blog linking plugin – not the core post class code which is used for all topic and forum post creation.

The call to this validation routine is in the file /library/sp-linking-blog.php – as shown in the original error you  pasted on the first post. Line 125 caters for the abort condition so you may want to add your is_admin() call in there.

As I say – we will discuss the merit of some filters in the core which I think will be as far as we would want to go in compromising permission handling.

I really hate it when I pay for top of the price and companies behave as if they can’t sell you anything else (short sighted, i must say). Don’t tell me that I am confrontational. I am asking for support. Which I have paid for, according to your sales pitches. I have been overly polite from scratch. You have dismissed (or not read carefully) my posts. I want to reiterate this: S:P is impressive and one of the best wp plugins I have ever seen. But it is you having an attitude, not me. If you don’t believe me, read back the whole thread, whenever you get a min for your top of the line clients. 

And yes, you are wrong about permissions: administrator should be able to override ANY permissions. You even state it yourself in your documentation and sales pitches. There is nothing wrong with a plugin which doesn’t contemplate a rare (maybe) scenario. What is wrong is to try and let your clients look like fools, instead of trying and reading what their problem is and offering the support they (according to your sale’s pitch) paid for.

All the best and enjoy your weekend.

Well we will disagree on ‘attitude’ and yes – I have read this all several times and I believe our replies so far to be patient and polite. So – sticking to the story…

you are wrong about permissions: administrator should be able to override ANY permissions. You even state it yourself in your documentation and sales pitches

We do not state anywhere – and never have – that ‘administrators’ – and that term means a user in a WordPress  Administrator role – has full and total access and overrides all permissions. This has never been the case with Simple:Press and never will be.

I mentioned earlier the difference between a WP Administrator and an SP Admin and you came back and bit my head off as if you understood it but clearly you do not. So again – a WordPress Administrator has no more permission in the forum than the permissions he is granted for his user group. And we have never stated anything different.

On the other hand – an SP ‘Admin’ as defined in the forum ‘Manage Admins’ panel – DOES have total and 100% access and rights to all aspects of the forum (with the exception of their users private messages if that plugin is installed).