Jump to content

MrSnoozles

Members
  • Posts

    56
  • Joined

  • Last visited

Recent Profile Visitors

1,313 profile views

MrSnoozles's Achievements

Full Member

Full Member (4/6)

92

Reputation

  1. Neither am I. πŸ™‚ It was just a thought that came while watching your video. rockFrontendEditing for example wouldn't sound as catchy, but would be clearer for newcomers. I really like the new syntax. I wanted to suggest a Latte attribute first, but then decided to keep it simpler. Your approach looks nice. Imo it would b good to explain why and when this is needed instead of just using $page->edit('myfield') Perfect! So you get the best of both worlds. I'm sick at home this weekend, hopefully I will find time to give it a try already.
  2. BOOOOOOM πŸ’₯πŸ’₯πŸ’₯πŸ’₯ Bernhard dropped the bomb. I'm halfway through the video and so far love everything about it. Nice video setup and editing there too. Going back to the video now πŸ˜€ ------------------- Edit: Okay, I'm through and this is definitely super cool. Looking forward to trying it out. There are two things though that I'm not sure about and wanted to mention: 1. The name Alfred. While you've found a sweet acronym it (in my opinion) has the huge drawback that new developers looking at the code and seeing alfred($page, ['fields' => 'gallery']) will have absolutely zero clue what's going on. Most of us love ProcessWire because it's intuitive. With this name you have to first learn that alfred is an inline editor to understand what the code is supposed to be doing. 2. I'm not sure about this one, but adding assets to the header through hooks reminds me of dark Wordpress times. I like that with ProcessWire you are able to to see where things are coming from and you have total control over what's happening.
  3. Does that mean we will be able to attach images to comments? I've been looking for such a functionality for a while, that would be great. Could you share a code snippet on how to do it?
  4. Article editor is nice and much more lightweight than CKEditor. @Marcjust posted an example of how an integration could look: And while CKEditor might have more features in general, for editing website content I think Article offers greater flexibility and is easier to use. ---- @ryanI once wanted to add images to FieldtypeComments, so each comment can optionally have one or multiple images attached to it. Is that something that could be supported too? If not, could you think of an easy way to integrate images into comments?
  5. @Jonathan LahijaniI'm just planning a project that would benefit a lot from a page builder. Were you able to work more on yours?
  6. @ryan Digging out a 9 year old topic: A common use case for me would be to sort users by `created`, so newest users are displayed first. Unfortunately the column `created` can not be selected in the module settings, as it's a system field. Neither can the default order be specified in the module configuration. Would that be something to consider for future updates?
  7. Ah, good point. Thanks for the clarification. Looking forward to seeing what you're coming up with.
  8. I've played with RockMigrations over the last week to get a better feeling of what it does. I didn't like the approach at first, because imo migrations should be run once to bring the system to the required state. Having them run on module refresh seems a bit too dangerous for production sites. I agree though, that for the sake of getting things done, your approach is very convenient. What you have planned for the next version could combine the best of both worlds: - a directory is added to the watchlist - migrations in that directory are executed in an alphabetical order - a hash-value for the file contents is stored somewhere when the migration is run - as long as the file contents does not change, the migration is not executed anymore That way the quick protoyping, as well a "proper" 1-file-per-update migrations could be achieved. Is this what you have in mind too?
  9. @bernhardAny idea already what will be different in the new module? Also it feels like it's not encouraged to use the old version anymore, because the Readme has been stripped from the repository. Is that feeling correct?
  10. Agree with @FireWire. This looks like the behaviour is wrong and an issue should be raised in the issues repository. The problem seems to lie in this line: https://github.com/processwire/processwire/blob/d78276e2c265f6b70384a13eb4febd4811a1db77/wire/core/WireHttp.php#L563 Every statuscode should be treated as a successful response, as long as the server was able to contact the remote server. EDIT: The comment on top of the line of code linked above says `no need to fallback to sockets`, but then the $result is set to false. I think this is meant to be a `$result = true;` instead of `$result = false;`. Then the rest of the logic would seem to be correct again.
  11. 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.
  12. 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.
  13. @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?
  14. 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! β™₯
  15. 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).
Γ—
Γ—
  • Create New...