Jump to content

gebeer

Members
  • Content Count

    1,007
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by gebeer

  1. Thank you for taking your time! I am using UIkit icons to be consistent with the UIkit admin theme. But I could switch to fa icons for users that still have the default theme enabled. This is what it would look like with fa-upload
  2. Happy to receive suggestions with visuals πŸ˜‰ Thanks for the idea. In my experience users hardly ever use image tags. They'd be a good way to categorize thumbnails, though. Will think about some more how to best implement this. Maybe automatically categorize if tags are there. Don't want to offer another option for this to avoid clutter in the field settings. You sure do love panels 😁 Thank you! I thought about this option. 2 things that kept me from using panels: First, they don't offer hooking into close events easily out of the box like pw-modal. Second, in my opinion for this use case it is cleaner to have an overlay over the whole page. It is more distraction-free. But thank you for taking the time and demonstrating! Interesting thought. I'd say for those cases also offer a normal image field and then in your template render only the one that has content. What you describe sounds like a hybrid between normal image field and my fieldtype. Actually I am thinking a lot about how to best present the input for my fieldtype. And I'd love to use the standard image input from PW. Basically make my inputfield extend InputfieldImage or InputfieldFile and modify according to the needs. Only had a quick look and it involves quite a lot of changes to the original classes. It is on my personal wishlist and I will fiddle with it and see if I can produce something that makes sense and is usable without being confusing.
  3. I saw that one. It would add an attribute to the wrapping inputfield which in my case is InputfieldWrapper which does not allow attributes. I'd need them on the InputfieldMarkup fields which inherit InputfieldWrapper. So no way. Anyways I found a workaround and attached my attribute in my markup.
  4. Updated to v0.0.5 on github New features: optional Ajax loading of thumbnails. Especially useful when field is used inside repeaters or has many images. edit link right next to the thumbnails for the page that supplies the images. When clicked, the images field that holds the images will be loaded in a modal window. After making changes to the images and saving, the thumbnails are dynamically reloaded Side note: while working on these, I discovered that you cannot assign custom attributes to InputfieldMarkup and InputfieldWrapper (both inherit from Inputfield class) with $field->attr('data-sth', 'value'). $field->setAttribute() also doesn't work. Anyone else also experienced this? Is it deliberate or a bug?
  5. Thanks for testing. I have this behavior in my other module that allows to pick images from a single folder. But now that there is an option to also choose images from child pages, it would make the inputfield grow too high. Also if there are many images. I will implement ajax loading for the thumbnails on open and think that is better, especially for cases with many images or child pages or when the field is used inside repeaters. Good idea! Will add this. Maybe open in modal window and refresh thumbnails on close. Will be easy to implement once the ajax thumbnail loading is there. Thanks for the link. That would be one option but only works for installs which are up to date on the PW version. Repeater fields also open automatically if they have an error attached to them. That is another option. But implementation is quite complex. Still experimenting with this feature.
  6. Will do that. Also think it is better. Only have to find a way how to open the respective repeater field on that page and ideally scroll to it. There should be a built in way to do this. I remember having read sth about it but can't recall where it was.
  7. @adrian Yes, pretty useful 😎 I tested this in repeater matrix context and it works, even the deletion prevention. Only thing which is not so nice: when you have this field inside a repeater, the edit links to the pages that contain the image references are pointing to the repeater pages, not to the pages containing the repeater field. Do you think this could boggle editors? They normally never see the repeater pages in the system.
  8. New version v0.0.4 released https://github.com/gebeer/FieldtypeImageFromPage Is now fixed Implemented this. Also think it is better to prevent deletion of images as long as they still are referenced from other pages. In this case now a detailed error message is displayed which contains a list of pages that have references to the image, with edit links for those pages. Following the edit links (they open in new tab) shows only the relevant field to be edited on that page. Not sure this works in repeater contexts, though. Will have to test. Sorry for that, it was late last night. It is now fixed.
  9. That error is fixed on the latest release. To install it, download a new module zip from github and replace all the files inside the module folder with files from the zip.
  10. No need to wait any longer 😎 Option for including child pages is added and live on github in the new master v0.0.2 . EDIT: It's the v0.0.3, getting late here
  11. Thanks for spotting this. Will be fixed for the next release soon. This is not planned, as of yet, sorry. But if more people like to have that feature, I will eventually add it.
  12. You can install this module from URL. Have a read here how to do this. In the 'Add Module from URL section' of the Module install page, paste this URL that points to the zip download from my github repo: https://github.com/gebeer/FieldtypeImageFromPage/archive/master.zip No need for the module name.
  13. @szabesz ATM there is no option to choose whether child pages of the "image holder page" (home in your case) should be included or not. This would be a necessary option in your use case. Otherwise the inputfield would list all children of home as sources for images. Couldn't you just use another page as source for the images and than create the 2 fields "header image normal" and "header image tall" as fields with my fieldtype and assign them to all top level pages' templates? Anyways, sounds like an option to exclude child pages would be good. Think, I'm going to add this to the next release.
  14. You can use a hook to ProcessPageEdit::execute to redirect users with those roles to the frontend page. Make a new file /site/ready.php and put this code inside: wire()->addHookBefore('ProcessPageEdit::execute', function (Hookevent $event) { $restrictedRoles = array('admin', 'frontendeditor'); // list your roles here foreach ($this->user->roles as $role) { if ($role->name !== 'guest' && in_array($role->name, $restrictedRoles)) { $this->session->redirect($this->config->urls->root); } } }); This will redirect users with given roles to the homepage of your site. Note that this will restrict them only from accessing page edit screen in the admin panel. If you like to restrict access to the whole admin area for those roles, you would need to hook into Page::render or Page::viewable and than check if the Page has template admin.
  15. Hi @shogun and welcome to the forum You can also try echo page()->featured_image->render(); This should output a standard img tag. Read all about handling images in ProcessWire. And the API documentation is always a great place to look up stuff.
  16. @adrian @szabesz and everyone who followed this discussion. I opened a new thread for the Module FieldtypeImageFromPage which is the new module that evolves out of this one after the discussion. Had a happy weekend of module coding 😎. Please try the new module and let me know what you think. Cheers.
  17. EDIT: all development and discussion of this module has been moved to Module FieldtypeImagePicker which now contains all features of this module and more. This module will not be maintained any further. The information below remains for pure historical reasons. I am happy to present my new fieldtype FieldtypeImageFromPage. It is made up of 2 modules: Fieldtype Image Reference From Another Page is a Fieldtype that stores a reference to a single image from another page. The image can be selected with the associated Inputfield. Inputfield Select Image From Page is an Inputfield to select a single image from images on a predefined page and it's children. And there also is a helper module that takes care of cleanup tasks. This module evolved out of a discussion about my other Module FieldtypeImagePicker. It caters for use cases where a set of images is being reused multiple times across a site. With this fieldtype these images can be administered through a chosen page. All images uploaded to that page will be available in the inputfield. When to use ? Let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site. Suited for images that are used on multiple pages throughout the site (e.g. icons). Other than the native ProcessWire images field, the images here are not stored per page. Only references to images on another page are stored. This has several advantages: one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Features Images can be manipulated like native ProcessWire images (resizing, cropping etc.) Image names are fully searchable through the API Accidental image deletion is prevented. When you want to delete an image from one of the pages that hold your site-wide images, the module searches all pages that use that image. If any page contains a reference to the image you are trying to delete, deletion will be prevented. You will get an error message to help you edit those pages and remove references there before you can finally delete the image. How to install and setup Download and install this module like any other modules in ProcessWire Create a page in the page tree that will hold your images. This page's template must have an images field Upload some images to the page you created in step 2 Create a new field. As type choose 'Image Reference From Another Page'. Save the field. In 'Details' Tab of the field choose the page you created in step 2 Click Save button Choose the images field name for the field that holds your images (on page template from step 2) Click Save button again Choose whether you want to include child pages of page from step 2 to supply images Add the field to any template You are now ready to use the field View of the inputfield on the page edit screen: View of the field settings The module can be installed from this github repo. Some more info in the README there, too. In my tests it was fairly stable. After receiving your valued feedback, I will eventually add it to the modules directory. My ideas for further improvement: - add ajax loading of thumbnails Happy to hear your feedback!
  18. This is what I'm trying to accomplish. Also I want to add a new property to Pageimage that holds the svg markup for inlining. Even if I add my hook inside the formatValue() method, it is not executed. Still fiddling. Will find a solution, eventually...
  19. Yes, I am using Pages and Pageimages to retrieve and list them. Everything is working fine so far. Doing some more fine tuning. Have to cater for cases where an image got deleted from the page that holds all images but is still referenced from my Fieldtype on a page. And things like that... Can I make a fieldtype module autoload so that I can attach hooks to Pageimage and Pageimages from init() within my fieldtype? I tried, but it doesn't work.
  20. @adrian @szabesz I am already working on implementing with child pages.
  21. @adrian I'm with you here. After contemplating some more, I think the page approach should be the only option, discarding the folder option in site/templates/. Since PW is all about pages, this makes more sense. Also editors can easily add/remove images as they see fit without having to use other tools like FTP clients. This also provides the manipulation methods from Pageimage class to all images. What do you all think?
  22. @adrian While I think that this is a good idea, I am not sure yet, if I want to go that far with this module. This would add additional complexity when installing and I wanted to keep it as simple as possible. This addition would make it kind of a "mini media manager" and I don't know how high the demand for it really would be since we have kongondo's excellent media manager already. But if more people would like to have that option, I can implement it. Please vote.
Γ—
Γ—
  • Create New...