Login for web users with error (no table web_user_attributes)

brezel

It is a clean install.

fourroses666

Some Plug-in or Snippet is using the table. Think you have to explore a bit more and find out where the issue is. That is what I should do.

BBloke

My understanding of v3 was that it wasn't user login ready. Therefore Formlister wouldn't work when signing in users.

I have done a v2 to v3 update. Implemented pathologics modxapi package in order to get users logged in but alas I've been unsuccessful. Yes, I've had the same message which I think relates to the model parameter in Formlister.

What's your Formlister snippet?

I must say though I'm also confused about it. I know someone has had success but I've yet to see it ☹️. I'm happy to wait for it all to be working as my user update snippet works a treat.

BBloke

OK. Success of sorts.

I have succesfully used Pathologics modXAPI and signed in with the admin account only. My normal user gives wrong password.

BBloke

Looks like there is something happening with passwords or maybe something that happens in the backend if the user account password is changed in the manager.

Once the password is changed I can log in. This was before and after my extended attribute conversion.

More digging to do but I'm further down the path of migrating.

bossloper

I have been out of the loop on this for a few months.
Has anyone got the evo v1 / v2 web user functionality working in v3 yet?

I did a clean install of v3 and out of the box it seems impossible to replicate the functionality of web users and 'private' web access pages. I appreciate all users now are part of the same ''users' database but assigning a permission group and resource link only seems to work for managers. I was hoping leaving role as 'no user role' would assume some sort of 'web user' but it seems not as logging this user in with a ''user group' will still not let the user see the public web page.

It seems as soon as 'access permissions' are set then the page is not visible as a public page?

Maybe I am missing something here. I really would like to get to v3 but it is a no go for me still as I do not want to support multiple version of Evo and I have too many sites requiring web user functionality.

Is there a downloadable demo somewhere?

fourroses666

I wonder too. I have no sites which needs it a.t.m. but when I do I'd like to see how its done.
Could be the FormLister documentation has it covered but not yet digged into it because I don't need it.

bossloper

I have not got to FormLister and the front-end part yet, just looking at the manager interface and setting up the basics. ☹️

And not even getting to to old ''web users', I see issues with manager permissions:
1) If I set a page with access permissions then that page is not available as a page to view on the frontend (unless logged in as a manager). Anyone else get that?

2) Any manager with a role not administrator, e.g. 'Editor' also gives a SQLSTATE unknown column _document_groups.document_group error when editing the page.

BBloke

Hi @MrB ,

Our internal website was Modx v1.0.4 > v2.0.4 using all the release updates. I have also branched it off to a development website and upgrade that to v3. I've used my own snippet to convert all our users to fit within the scope of v3 Users and the functionality on the v3 site works as it has in previous iterations.

We have document group, user groups and resource links with no issues. The new backend User Variables should not interfere with the document group mechanic of old.

I'm happy to post my code if you need it?

BBloke

If you are in the backend then you can see anything in the frontend regardless of document permissions as far as I'm aware.

Checking my own installation, my admin account has no access permissions but I'm allowed to preview any document from the document tree regardless of it's own permissions.

If you have a document which is assigned to a document group then unless you have users to sign in with then that document will be hidden.

As a web visitor I would only be able to see documents which are assigned to "All Resource Group (public)".

User roles have nothing to do with web permissions (web user group/resource groups or user/resource group link)

I've never come across your second point but I'll see if I can replicate it.

@Graffx Design is quite right about exploring, although you have a fresh install, maybe one snippet/plugin snuck through and still wants to use the old tables.

BBloke

I've got a fresh installation for v3.1.7.
I created a new page using the default 'admin' account.
I've created a new user 'siteadmin' with 'editor' role.
I edited the page without an issue.

NB: I haven't set any document permissions yet.

I created a new group and new resource group and link them together. I went back to the page I created and assigned the web permissions for it to the newly created group.

Signing in to the manager with 'siteadmin' account which is assigned as an 'Editor' means I cannot see the private document.

I've assigned 'siteadmin' into the private group and I can see the private document in the tree. Clicking it gives me the SQL error. This happens for any document in the tree.

I've posted something in github to let them know! Looks like a bug transitioning over to the new users mechanic.

bossloper

BarnsleyBloke
Hi BB,

Thanks for all your replies.

The problem I have is with:

"As a web visitor I would only be able to see documents which are assigned to "All Resource Group (public)".

This was not so using Evo 1.4.x (not sure about 2.x)

You could have public pages ( i.e. on resource overview for a resource these would be 'Web access: public'). But you could assign them as 'Manager access: Private'. I.e. you could have some manager groups able to MANAGE different subsets resources. But all these resources are still public to the frontend visitor.

It does not seem to work like this now. i.e. the ''Web access: public' part is not working?? As soon as a page is assigned an access permission it becomes private to frontend webusers, whereas it should just be restricted as to which managers can edit it from the backend manager.

I have 30-40 sites where I have multiple managers set up to edit different subsets of resources. I also have 'web users' that can see all the pages (managed by the various backend managers) and also a login to be able to see some hidden pages 'web access: Private' resources. This merging of managers and webusers to one data table seems to have simplified and lost a great deal of functionality as far as I can tell.

BBloke

MrB I've never used that and didn't know it was there. Crazy. Been using it for ages too.

Well, as far as I can see you stumbled on a bug which is never a bad thing.

Realistically then, in your case, the move forward has a bad step.

I think as it stands the program will not be able to do it out of the box. Whilst roles allow for manager restrictions. It doesn't allow for document restrictions as before and you will be either to edit or not on everything.

There may be a way to have a system where you will be able to achieve the same or similar affect but in my case, I'm not sure on which bits to attack in order to do it. It wouldn't be for the average site builder. You certainly have a need for it.

The only way I can think about it at the moment is giving all pages a TV and assigning a number to it to represent the user who can edit (or maybe access group name to represent a group of users) and have all the docs as public.

Then maybe a plugin that checks the user and group against the document being edited and allow if it matches. Maybe an Evo guru could say whether this is a way to go. Sadly it would mean a lot of work in populating the document TV unless there's a programmatical way to do it. It's quite a task for 30-40 sites. There's nothing stopping you having user groups.

BBloke

You've peaked my interest. So I've written a small plugin which checks a document TV value against a user access permssion. If they match you can edit the document. Otherwise you cannot. It wouldn't stop the tree being filtered, sorry.

I have one issue. Whilst it works I cannot stop the document making it to the screen.

All that is needed is a new TV which should contain the name of the user group who can edit that document.

The plugin runs against the OnDocFormPrerender.

bossloper

I have been using Evo aka MODx for 10+ years from way back in the v0.97 days and filed and submitted countless fixes and improvements over the years to help get 1.4.x bug free. I have build custom imports export modules for web users and quite complex usages of permissions for both multiple manager access and membership databases and logins. Which is why I am particularly sad that the guts of the permissions system has been ripped apart in 3.x as it stands. :-(

Effectively you are trying to bake back in what was ''web users' vs 'manager users' and their associated 'Web Permissions' and 'Manager Permissions'? :-)

It seem like access permission in v3 at the moment have take the manager aspect of permissions to edit resources but applied them in a 'web user' way to the frontend, which makes no sense at all. I really think 3.x should be flagged beta software in its current state.

I don't see how a single set of 'Access permissions' in 3.x as it stands can reproduce all of the functionality of what was 'Web Permissions' and 'Manager Permissions' in 1.4.x and 2.x. That is why I was sort of hoping there was going to be something new added to the roles I had missed (yes I appreciate they are manager only in a v1.4 and 2.x sense but now there is no distinction between managers and users - users also effectively have roles)

Besides pushing for fixes and additional functionality I think I am at a road block for now.

nick0

MrB It seem like access permission in v3 at the moment have take the manager aspect of permissions to edit resources but applied them in a 'web user' way to the frontend, which makes no sense at all. I really think 3.x should be flagged beta software in its current state.

I don't see how a single set of 'Access permissions' in 3.x as it stands can reproduce all of the functionality of what was 'Web Permissions' and 'Manager Permissions' in 1.4.x and 2.x. That is why I was sort of hoping there was going to be something new added to the roles I had missed (yes I appreciate they are manager only in a v1.4 and 2.x sense but now there is no distinction between managers and users - users also effectively have roles)

Agreed MrB . I personally liked the idea of Manager Users and Web Users as separate groups - for both organisation and perceived security. In sites like WordPress with lots of frontend users where all the manager and frontend users are jumbled into one spot to manage, it can be harder finding the 3 x manager users. So important to know who can access what and it was much better how it was. Backwards compatibility issues highlighted again with Mr B's complex needs that worked well in 1.4.X.

risingisland Another reason why I am not ready to move to 3.x.
I am trying to see if I can have everything at least up to 1.4.15 with hope to migrate over to 2.x, but I need a smooth transition for both myself as well as my clients.
At the moment, I just see too many hiccups in the path. Whether it be permissions, Tinymce, language, or other. There just seems to many bumps in the road for me to comfortably move over. At the moment, for my needs, I just dont see any benefit.
I do appreciate both the bravery as well as the know-how of others to power through this and share their discoveries with the rest of us.

Agreed risingisland, it feels a little patchy.
At least there is a sort of automatic upgrade available via the Migrator plugin (manual updates needed for me afterwards to iron out some of the bugs).
In my speed tests of the exact same site in 1.4.15 vs 3.1.17, 1.4.15 wins slightly.
In fairness to the devs most things do seem to work but there are lots of minor annoying things that makes it seem a bit beta as Mr B notes. You'd think 3.1.17 would have enough sub versions to get past that stage. Backwards compatibility should always be a focus. Evo 1.4.X works so well and as a non programmer, I don't care about Lavarel, I want Evo to just work like it normally does.

MrB I would put a big warning out for anyone going to 3.x that unless you have a simple system with all managers just editing all the resources with no permissions and no 'frontend' user/membership or whatever then it will very likely as of 3.1.7 not work out of the box. Which, putting my public relations hat on, could alienate existing Evo 1.4.x /2.x users if they upgrade and it breaks. Better to keep the userbase happy vs frustrated or over time they will go elsewhere.

Fingers crossed it gets sorted out soon, as there has obviously been a great deal of effort put in to 3.x and it is so close...

Agreed MrB. Unless its a fresh install of v3, even small sites updated from 1.4.X will be a little frustrating / provide some head scratching issues to existing Evo users.

risingisland

Another reason why I am not ready to move to 3.x.
I am trying to see if I can have everything at least up to 1.4.15 with hope to migrate over to 2.x, but I need a smooth transition for both myself as well as my clients.
At the moment, I just see too many hiccups in the path. Whether it be permissions, Tinymce, language, or other. There just seems to many bumps in the road for me to comfortably move over. At the moment, for my needs, I just dont see any benefit.
I do appreciate both the bravery as well as the know-how of others to power through this and share their discoveries with the rest of us.

bossloper

@risingisland - agreed, my clients will not tolerate numerous errors and reduced functionality. For them it is about the end user experience and functionality.

I hope it gets sorted and I don't want to come over as negative, just realistic! :-) I really wish I could upgrade as I like to follow the leading edge and help fix things, but it is still too ''beta' for me to be able to do so for now. I would much rather spend my time helping with 3.x and I hope I don't have to resort to making 1.4.x php8 ready.

I would put a big warning out for anyone going to 3.x that unless you have a simple system with all managers just editing all the resources with no permissions and no 'frontend' user/membership or whatever then it will very likely as of 3.1.7 not work out of the box. Which, putting my public relations hat on, could alienate existing Evo 1.4.x /2.x users if they upgrade and it breaks. Better to keep the userbase happy vs frustrated or over time they will go elsewhere.

Fingers crossed it gets sorted out soon, as there has obviously been a great deal of effort put in to 3.x and it is so close...

nick0

I have a question related to this and the FormLister web login form I test with and wondering if anyone can please help?

I get the following error when trying to log into the FormLister form.

Parser / SQLSTATE[42S02]: Base table or view not f - System Events
Event Id: 	0 	Source: 	Parser / SQLSTATE[42S02]: Base table or view not f

« Evolution CMS Parse Error »
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'my-table.modx_web_user_attributes' doesn't exist

Basic info 	
REQUEST_URI 	http://my-site.com:443/demos/my-account/login
Resource 	[38] Login
Referer 	https://my-site.com/demos/my-account/login

I think perhaps the error is because web users and manager users have been merged into the one group in Evo 3 and &userGroups=WebUsers is no longer correct usage.

In my Formlister login forms I have the following parameters - does anyone know what I need to change these to so that the login form works in Evo 3.1.17

[!FormLister?
	&controller=`Login`
	&context=`web`
	&userGroups=`WebUsers`
	etc

Many thanks.

BBloke

Hi @nick0

You are right. The update and centralisation of the users is why you have this error. There is a package which will get you passed this.

You will find instructions here: https://github.com/Pathologic/MODxAPI

As well as that you need to make a small adjustment in the userHelper plugin. Goto the plugin and change the configuration Model to

Pathologic\EvolutionCMS\MODxAPI\modUsers

That should help. Hopefully!

nick0

BarnsleyBloke Hi @nick0

You are right. The update and centralisation of the users is why you have this error. There is a package which will get you passed this.

You will find instructions here: https://github.com/Pathologic/MODxAPI

As well as that you need to make a small adjustment in the userHelper plugin. Goto the plugin and change the configuration Model to

Pathologic\EvolutionCMS\MODxAPI\modUsers

Hi and thanks for the assistance BarnsleyBloke ...
Hmmmmm, I must have messed something up trying this hack as now the user login form doesn't show at all in the frontend... where's the facepalm emoji when I need it 😆.
Following the Installation instructions on the MODxAPI page is no doubt where I went unstuck

Add "pathologic/modxapi" to "require" section of your core/custom/composer.json, then run "composer update" in core folder:

In particular scracting my head at run "composer update" hehe.

1 I changed my userHelper > configuration > Model to: Pathologic\EvolutionCMS\MODxAPI\modUsers

2 I changed my Formlister form from:

[!FormLister?
	&formid=`loginForm`
	&controller=`Login`
	&context=`web`
	&userGroups=`WebUsers`
	&checkActivation=`1`
	etc

to (removing &context and &userGroups and adding &model):

[!FormLister?
	&formid=`loginForm`
	&controller=`Login`
	&model=`Pathologic\EvolutionCMS\MODxAPI\modUsers
	&checkActivation=`1`
	etc

3 I added the "pathologic/modxapi: *" line to the composer.json file with this path - /core/custom/composer.json:

{
  "name": "evolutioncms/custom",
  "require": {
    "barryvdh/laravel-ide-helper": "~2.4"
    "pathologic/modxapi": "*"
  },
  "autoload": {
    "psr-4": {
      "EvolutionCMS\\Custom\\": "src/"
    }
  }
}

4 To /core/src I uploaded the following 7 files (full path shown):

/core/src/Traits/ContentTV.php
/core/src/Traits/RoleTV.php
/core/src/APIhelpers.php
/core/src/autoTable.php
/core/src/modResource.php
/core/src/modUsers.php
/core/src/MODxAPI.php

5 This is what I interpreted as then run "composer update" in core folder:...
I added the require line

    "pathologic/doctrine-cache-bridge": "*"

and the autoload psr4 line

      "Pathologic\\EvolutionCMS\\MODxAPI\\": "src/"

into the existing composer.json file located at core/composer.json so that it's content became:

{
  "name": "evolutioncms/core",
  "type": "project",
  "description": "Evolution CMS is a Content Management System, ex MODX Evolution",
  "keywords": [
    "content",
    "CMS",
    "routing",
    "templating",
    "core"
  ],
  "homepage": "http://evo.im/",
  "license": "GPL-2.0+",
  "authors": [
    {
      "name": "Evgeniy Borisov",
      "email": "modx@agel-nash.ru",
      "homepage": "https://agel-nash.ru",
      "role": "Developer"
    },
    {
      "name": "Dmytro Lukianenko",
      "email": "dmi3yy@gmail.com",
      "homepage": "http://dmi3yy.com",
      "role": "Developer"
    }
  ],
  "require": {
    "php": ">=7.3",
    "ext-SimpleXML": "*",
    "ext-dom": "*",
    "ext-iconv": "*",
    "ext-json": "*",
    "ext-libxml": "*",
    "ext-mbstring": "*",
    "lib-iconv": "*",
    "lib-libxml": "*",
    "doctrine/dbal": "~2.3",
    "phpoption/phpoption": "*",
    "vlucas/phpdotenv": "^5.2",
    "guzzlehttp/guzzle": "^7.0.1",
    "composer/composer": "*",
    "illuminate/cache": "8.*",
    "illuminate/redis": "8.*",
    "illuminate/config": "8.*",
    "illuminate/console": "8.*",
    "illuminate/container": "8.*",
    "illuminate/database": "8.*",
    "illuminate/events": "8.*",
    "illuminate/filesystem": "8.*",
    "illuminate/log": "8.*",
    "illuminate/pagination": "8.*",
    "illuminate/routing": "8.*",
    "illuminate/support": "8.*",
    "illuminate/translation": "8.*",
    "illuminate/view": "8.*",
    "illuminate/validation": "8.*",
    "illuminate/http": "8.*",
    "league/flysystem": "^1.0.8",
    "phpmailer/phpmailer": "6.*",
    "tracy/tracy": "~2.5",
    "wikimedia/composer-merge-plugin": "2.*",
    "symfony/process": "^5.1",
    "dmitry-suffi/redis-session-handler": "*",
    "rosell-dk/webp-convert": "*",
    "predis/predis": "*",
    "james-heinrich/phpthumb": "1.*",
    "evolutioncms-services/user-manager": "1.*",
    "evolutioncms-services/document-manager": "1.*",
    "evolution-cms/salo": "1.*"
    "pathologic/doctrine-cache-bridge": "*"
  },
  "require-dev": {
    "roave/security-advisories": "dev-master"
  },
  "config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "prestissimo": {
      "maxConnections": 6,
      "minConnections": 3
    },
    "vendor-dir": "vendor"
  },
  "extra": {
    "merge-plugin": {
      "include": [
        "custom/composer.json"
      ],
      "recurse": true,
      "replace": true,
      "merge-dev": false,
      "merge-extra": true,
      "merge-scripts": false
    }
  },
  "autoload": {
    "psr-4": {
      "EvolutionCMS\\": "src/",
      "Database\\Seeders\\": "database/seeders/"
      "Pathologic\\EvolutionCMS\\MODxAPI\\": "src/"
    },
    "classmap": [
      "database/migrations/"
    ],
    "files": [
      "functions/actions/bkmanager.php",
      "functions/actions/files.php",
      "functions/actions/help.php",
      "functions/actions/logging.php",
      "functions/actions/mutate_content.php",
      "functions/actions/mutate_plugin.php",
      "functions/actions/settings.php",
      "functions/helper.php",
      "functions/laravel.php",
      "functions/nodes.php",
      "functions/preload.php",
      "functions/processors.php",
      "functions/rss.php",
      "functions/tv.php",
      "functions/utils.php"
    ]
  },
  "minimum-stability": "dev",
  "prefer-stable": true,
  "scripts": {
    "upd": "composer update --lock --ansi",
    "post-autoload-dump": [
      "@php artisan package:discover"
    ]
  },
  "scripts-descriptions": {
    "upd": "Updating sub-levels composer.json files"
  },
  "support": {
    "email": "dmi3yy@evo.im",
    "issues": "https://github.com/evolution-cms/evolution/issues/",
    "source": "https://github.com/evolution-cms/evolution/",
    "docs": "http://docs.evo.im",
    "telegram": "https://t.me/evolutioncms"
  }
}

6 Now I have no login form visible (even after cache clearing) and I laugh out loud at my lack of skills... you may have guessed I am no programmer hehe.

Can you see where I went wrong with that @BarnsleyBloke ? Thank you kindly for any assistance.

The thing is - the frontend login form is on my starter / test site with a login section using FormLister. There is only one front end "web user" and I would happily use the Evo 3 FormLister method without hacking... if only I knew what to put into my FormLister login call 🙂