Jump to content

MrSnoozles

Members
  • Posts

    46
  • Joined

  • Last visited

Recent Profile Visitors

1,107 profile views

MrSnoozles's Achievements

Jr. Member

Jr. Member (3/6)

84

Reputation

  1. If you need any more support for this module please let me know. It's just so useful. Going to try a few more use cases in the coming days.
  2. Thanks for the reply. Will try in the evening and report back. I'll also try to have a look into why ProcessUser is removing the GET parameters. EDIT 1 (FieldTypeSelect): I did test the new version. When I configure "option1\noption2" the select shows: option1 option2 option1\noption2 This is because in line 387 $inputfield->option = trim('option1\noption2'); is being called, adding the full settingValue as another option. If you continue; in the block where you're checking if the inputfield is a select, it should be working. Also instead of using "\n" or "\r\n" you could probably use the constant PHP_EOL which contains the line separator for the operating system PHP is running on. EDIT 2 (Editing pages of template user): So far I've found out that the redirect is because of the method ___setEditor() in wire/core/User.php. It leads to a redirect that strips the two parameters &forpage und &forfield. If they are appended, everything works correctly. One way to solve it would be to not use ProcessUser and use ProcessPageEdit instead by adding this code to your init method: // do not redirect to a page using ProcessUser when editing a page relation $this->addHookBefore('User::setEditor', function (HookEvent $event) { if(!$this->input->get('forpage') || !$this->input->get('forfield')) { return; } $event->cancelHooks = true; }); This is not yet optimal though, because in the edit screen the "name" is shown in all languages. But imo it's good enough for now. A better way would be if the method editUrl() in the User class would keep the url parameters. But that would be a core issue.
  3. @LuisM This is really sweet. ProcessWire is awesome but for bigger projects, that go beyond a simple website, managing business logic and templates can get messy really quickly. I really like your attempt on integration with Symfony. I thought about a couple experiments to "professionalize" ProcessWire development too, e.g. having the PW core and PW admin be independent packages being able to load these packages through composer having proper namespacing with autoloading being able to use bundles for easier separation of business logic going headless first (PW is so close to being there although not focusing on it at all) One question: How would you manage to stay compatible with future PW version? Would that be possible without additional work in the future?
  4. This is amazing! I have missed this functionality in ProcessWire for a while already. Installation Install AdminPageFieldEditLinks: https://processwire.com/modules/admin-page-field-edit-links/ Install FieldtypePageContextData (this module) Create a new field of type "Page Reference Context Data" When setting up the field: in tab "Details" enter configuration in "Additional page fields in Pagefield context". You can see many examples here https://github.com/kixe/FieldtypePageContextData in tab "Input" select "Enable view/edit linnks on selected pages?". If you don't see this field the module AdminPageFieldEditLinks is not activated in tab "Input" when changing the label field: you can also use the additional context fields as label in the page reference. Symply change your label to a custom label and define it like so: {title}, {_customfield1}, {_customfield2} assign the field to your template Screenshots When installed and configured correctly you see the page reference like normal. But now you can click it and edit the page in a modal. This modal also contains a new tab "Pagefield Context Data" (the name of the tab can be changed in field settings). Bugs found so far On Windows: separating option values for select by \n is not working correctly. Maybe use | instead? (as that's how ProcessWire separates fields) for the user template the tab "Pagefield Context Data" is not being displayed Very well done. This is SO useful! ♥
  5. This looks like a timing made in heaven. Thank you so so much! Going to try it out right now. Very good idea! That would probably work (having a repeater that repeats a single page select and an additional information field). However it probably has a few downsides too (especially api wise, but it's also a bit more cumbersome to input, because you don't get feedback which pages have already been referenced).
  6. Hi, I would like to see the possibility to specify additional data when using the page reference field. I've come to need this many times already, but always used some workaround so far. Examples: 1) Team members with different roles Imagine there's a template "team" referencing many "user"s. Now in the team there are different roles, e.g. "coach", "member" and "trial". Right now we would have to add different page reference fields (that are all referencing "user" objects). Having additional data on relations would make this much easier. 2) Join-date for team members Staying with the team members example, it would be useful to store, when each member joined the team. So far I would not know how to achieve that with the current feature set. Probably by storing some information in a JSON textfield in the team. Edit: this feature request has also been posted here: https://github.com/processwire/processwire-requests/issues/421
  7. Haven't heard about ModuleReleaseNotes until now. It looks incredibly useful. A bug I noticed in the PW API variables documentation: The flash icon is not displayed anymore for hookable methods (or is it just my pc?). If that has to be touched it would also be useful if a unicode character (e.g. 🗲, ♆, ★, ⚓ or ⚡) would be used instead of the SVG icon, so people can ctrl + f for hookable methods.
  8. This is a great feature for larger sites. Really excited about this. Speaking of scaling: I would imagine a limiting factor right now would be, that the uploaded assets are bound to the local drive. Is that a problem for your setup / would proccesswire.com benefit if it was possible to store files on S3? And is there a post somewhere explaining your setup on AWS?
  9. I really love the syntax of the migrations. I wonder though if RockMigrations could be additionally used like @LostKobrakai described: to manage the state of templates and fields in a website and create a reproducible deployment. For that as far as I see two parts would be essential: - having a global place to put site-deployments (e.g. site/assets/RockMigrations) where deployments can be put with a timestamp instead of a version - a way to run (and track) the run migrations during deployment (maybe as extension of wire shell?) Having a way to track schema changes between staging and live environments and run them automated in a deployment pipeline would be a huge gain for Processwire.
  10. Hey everyone, I was just wondering what is the purpose of autoloading the file wire/core/ProcessWire.php in composer.json? As far as I can see that file gets required again anyway in index.php, around line 32. For me this line has no purpose but one major drawback: When requiring ProcessWire as dependecy in a module (e.g. to write tests against a clean ProcessWire installation), an error is thrown that the class is already in use. Fatal error: Cannot declare class ProcessWire\ProcessWire, because the name is already in use Does this autoloading have any purpose?
  11. Want to add to this rather old discussion, because state of tech changed a bit: No - probably it could have been simplified a lot. It was my first project with Jsviews and I probably didn't use everything it has to offer. Anyway: what caught my attention recently with regard to the ProcessWire backend is https://svelte.dev/. I haven't worked with it yet, but it seems like it could be a nice match for ProcessWire. It compiles to native Javascript, meaning even if there will be a next big thing in the future we don't have to include an outdated framework in the backend. The syntax looks really nice too and very Vue-ish which I personally like a lot.
  12. And the community loves you (two). Thank you for releasing the files, I'll definitely have a look into it after holidays. I'm sure it will be tremendously useful and I hope I will find the time to provide some improvements to it. Thank you so much.🤩
  13. And again, this has nothing to do with the Inputfield that is currently being worked on but what I was wishing for a couple times lately was some kind of "strtotime" support for page selectors when used on date fields. This would for example allow for filtering for users that signed up in the last 6 months, and that list is updated automatically, without any custom code involved. $pages->find('template=user,created>"-6 months"'); I know, this is not related to the Inputfield, but I wanted to bring it up in case it's an easy addition while working on dates.
  14. Wow, just wow. Unique values are going to be so useful, looking forward to it. And login by email sounds exciting too. 💪
  15. Hello Milo and welcome to the forums. $config->userAuthSalt For security reasons this should be different for every page. This value is used to hash your passwords to add an extra layer of security. That means when you change it you won't be able to log in anymore without regenerating the password. $config->httpHosts This should be just the host, without the protocol. So without http/https site/assets/files As far as I know there is no better way to do this, so you would have to delete files that are not needed on the new site manually. I could be wrong tho. As for the title of the topic: try to add a couple more words so people with the same questions will have it easier to find your topic in the future 😉 Best regards and again, welcome to the community
×
×
  • Create New...