thetuningspoon

@Robin S Great, thanks!

I am also interested in an answer to this for the AdminPageFieldEditLinks module. It looks like I would need to be able to hook renderReady() in order to load the necessary assets in repeater fields. Unless there is some other way that I haven't thought of to do this.

The expected behavior is what is occuring on the front end. I'm not sure why the parent modal is not visible in your back end example. I bet that if you go another layer deep, the parent modal will be visible in the background. Is the parent modal being visible in the background problematic for your use case? My original thought when creating this module was to make each window overlay the previous exactly so that the top parent window would always be visible in the background, but I found the "zoom" approach to be a much simpler and more programatically elegant solution to the problem.

Ah, I understand now! This is actually the intended behavior, and if you look carefully, it is also how it works on the back end. The parent window is expanded to take up the full screen, with the effect that the entire interface zooms inward.

Hi @bernhard I'm not sure that I'm seeing the issue from your screencast. Is the problem that the modal is bigger than you want it?

If you want to be picky about it

You can also put it at the very top of the same template file, as long as you do something like this: if($config->ajax) { // Output your json exit; }

If you have cPanel or phpMyAdmin installed on your server then this is all much easier

If you're doing this from the command line and are already logged into MySQL, here are the commands to use: 1. create database databasename; 2. \u databasename 3. create user 'databasename_u'@'localhost' identified by 'password'; 4. grant all on databasename.* to 'databasename_u'@'localhost'; Replace "databasename" with the name you want for your database.

Did you set up a new database and user specifically for this ProcessWire installation? If so, you would have had to give it a database name, username, and a password. That is what's being asked for here. Usually the port is 3306 and host is localhost, so that should be good. This would be different from just a generic MySQL setup.

Thank-you BitPoet. That was it! I logged into MySQL on the server and used the following to fix it: SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY','')); This was a brand new server that my boss had just spun up and moved the site to. I hadn't thought of whether a configuration issue could be the cause. pagefield.first.title doesn't seem to work on the multi-page fields, but just pagefield.title does, and it seems to behave as I would expect pagefield.first.title to behave.

Thanks arjen. I was thinking that it should definitely be possible (and I feel like I've done this type of sort before without any problems). 1. PW 3.0.28 (just upgraded it to see if that would fix the issue) 2. This particular one is a single Page field, though I have also tried it with a multi-page field (should that work? i.e. pagefield.first.title?) 3. Just tried that. Didn't work I also set the fields to auto-join.

I am trying to sort a PageArray by a Page field. Since I want the sort to be based on the Page field's Title field, I am using a subselector: $this->pages->get('template=People')->children("sort=location_select.title, limit=30"); The error I get is: Error: Exception: SQLSTATE[42000]: Syntax error or access violation: 1055 Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'example._sort_page_location_select_title.data' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by (in /examplepath/wire/core/PageFinder.php line 384) Removing the subselector results in the same error as well, though sorting by any field that is not a Page field seems to work fine.

Is this still a problem with 3.0.23 since Ryan undid his earlier change?

Nothing in the logs. I reviewed Ryan's instructions again and I think everything is correct

Good thought. I will check the logs.

I am taking advantage of the new ability to create users of a template different from "user" and adding them in a different part of the page tree. This is PW3. But when I go to create a new page from the page tree using the alternate user template, some kind of weird redirect happens and I end up on /access/users/edit/bookmarks/bookmarks/bookmarks/bookmarks/ If I remove the alternate "Page Class Name" setting ("User") then I can add new pages again, but the users I create cannot login.

Thanks for your comprehensive and educational reply, LostKobrakai. I didn't mean to cause such a stir. As I get more experience with namespaces I'm sure I will come to appreciate them better. I'm just venting a little because right now they're solving a problem for me that hasn't needed solving, and doing it in a way that I don't find intuitive.

It depends how unique your namespace name is. I guess what I'm really wondering is why ProcessWire\User is preferable to ProcessWireUser. Neither one is any more or less likely to conflict. Adding a slash between the names and the extra bit of complexity that comes with having to work woth namespaces doesn't change the likelihood of a conflicting name one iota. But maybe I'm missing some other advantage. I'm not saying that PW shouldn't support namespaces. If that is where the php community is headed then I think PW should be there with it. I'm just not convinced that the idea is a good one to begin with.

What if the namespaces collide?

I wonder if the difference has something to do with working with an Inputfield vs. a Fieldtype. In what context are you wanting the additional config options to be shown?

Hi Robin, glad you are finding this module useful! The reason why the modal stays open is that there are several scenarios in which I think this would be desirable. One is when you're creating a new page and it is a 2-step process. The modal needs to stay open after the initial page creation so that you can then edit the new page. The second is when there is an error on the page. I wanted the user to be able to see the error and make any corrections before closing. Ideally, I would just have the modal stay open only in those scenarios, but accomplishing that in the PW admin isn't straightforward at this point. It is something that I would like to look into, though right now I'm pretty swamped with other projects.

Ok, I got it working. The problem was with my autoloader, which wasn't accounting for the namespace portion of the class name. Also, there were a couple places I was instantiating built-in php classes, and I had to add a "\" before the class name to specify the global(root?) namespace. I'm still not convinced this namespace thing is worth all the trouble. Seems like a bunch of extra effort to achieve the same effect as using longer class names, but I digress...

Thanks for the link, AndZyk. I did try adding the namespace line, but was still having problems. When I get back into the code I can provide more specifics.

I've built a custom (hierarchical) MVC-like framework for the front-end of our PW sites. I have not worked with PHP namespaces very much before, and when I upgraded one of our projects to PW 3.0 as a test, the automatic conversion process (through the new template compiler) failed to produce a working result. I would like to turn off the template compiler and manually update my templates/framework to work with namespaces. Is there a straightforward explanation somewhere on what steps need to be taken to upgrade templates and classes to work natively in PW 3?