Leaderboard
Popular Content
Showing content with the highest reputation on 06/08/2021 in all areas
-
More fun (can't upload animated gif) with style switcher... style-switcher.mp45 points
-
Hey Adrian, I like the idea! But I'm not sure what would really be the best way to achieve something like this. I've created a module for my style to make it easy for me to maintain it and also it has lots of helpful background information about admin themes/styles: https://github.com/baumrock/AdminStyleRock The main reason for putting everything into a module is my git submodule based setup. So I can simply add my theme as submodule and pull and push changes to any of my projects. My module can also serve as an example for others that want to provide a style for AdminThemeUikit. It could be simplified even more, but maybe it's good to wait a little to see how and if the community will come up with other styles at all? I think what we have now is only a first step. But I'm really not sure what would be a good next step as there are many good options... ?3 points
-
I don't think there is a "best practice" written down somewhere for this sort of scenario. I agree it can be confusing to figure out the "right solution" when there would seem to be so manyw ays to achieve the same. If all the values from the identifier are okay with being a text type value, I would go with a Table field with two columns, a Page Reference that fills its options with the "catalogue" of "possible IDs" and a text field that acts as the field for the actual value, this way you can have whatever fields you want on each organization, and you can do stuff like: $pages_with_purls_identified_orgs = $pages->find('template=organization, ids_table.id_type.name=purls'); This also guarantees you can also add new identifiers in the future very easily and consistently. You could do almost exactly the same with repeaters. Why table and not repeater? I just prefer the interface of the table field, I think it's less clunky visually when few fields are involved and has a more snappy feel. If each identifier would need more data added, I'd go for a repeater, but since it seems it's just an ID name and the actual value, table field seems enough. Repeaters would also have the "overhead" of loading an extra page on memory per repeater, since each repeater item is a processwire page. Although another scneario, what if the value of each identifier is a different type, then the table field would not work as nicely. Say you need DOI to be alphanumeric and ORCids to be integers, maybe for this case a repeater could work, with the same catalogue of identifiers, except that you create two additional fields (one text type, one integer type) and show them conditionally depending on the value of the page reference field where the type of identifier is selected. Please take this idea with a grain of salt, just something I came up with right now. It might be a hassle to manage the relationship of "identifier - type of value" on the actual code, or it might be worth the trouble, or there might be a better solution out there ?2 points
-
Hey @benbyf I don't run my own servers, but there is some info here about DNS records for people doing self-hosted stuff... The Digital Life on YT: There are other videos on that channel about self hosting email servers - but I note he's recently given up self hosting mail services.2 points
-
Just a wild guess but is it maybe necessary that the port is defined within site/config.php? $config->httpHosts = array('www.localhost:8888', 'localhost:8888');2 points
-
2 points
-
Glad you're finding it useful! You are correct--I don't believe I ever added support for the read-only state of the various inputfields. Feel free to submit a pull request if you do work on this.1 point
-
If you are talking about displaying all the emails in a table, then you can just use the PW API to fetch the children of the contact form page and display them in an HTML5 table. If you can let us know what contact form you are using, maybe we could point you further towards a solution. Also, could you just post the screenshots here in the forum rather than links to screen shots stored elsewhere.1 point
-
ok, so somehow its working.... fingers crossed, not sure what but did a mix of all the settings and something has started working with one of the combinations... FML i hate email also this was really useful by the way1 point
-
Make sure that your from address is the same as your user (login) address, and that you have the dns records defined as netcarver stated. On a similar note, I don't use mailinabox, rather an old squirrel mail install for linuxdude. It is a pita running your own mail server by keeping up with the spammers. And you will have spammers.1 point
-
Hi there. Yup, you guessed it. Thank you, I can't believe after all this time I missed that!1 point
-
1 point
-
@ryan - what about a dedicated "Skins" section - maybe within the modules directory. Perhaps the requirement for adding a skin to the directory would be to link to a Github repo with the admin.less and also an admin.png file which could be used on the skin's page in the directory. Ideally I think it would be nice if it was possible to view all skin screenshots via a gallery of thumbnails to make it easy to browse visually.1 point
-
This may be because only copies can be stolen, never the originals ? But all joking aside. If you want to protect the images at some point, you will probably not get around a very present watermark in the images for the large representations. Additionally you have to prevent access to the original images for non-registered visitors. Both would not be of much work. Example: Watermark a variation of the original images directly (in the same size) and then always use this WM-variation as the starting image for all further image processing. This could be encapsulated in a function or better maybe directly hooked as a new Pageimage->Function or Property. You would then always call your images like $image->wm->width(1280) instead of $image->width(1280). The possibility to create variations without watermark still remains. If you are interested I could create a tutorial for everyone. For watermarking we have the old but still working module PIM2 and for protection there is a description how to set this up. If you are interested I can fast-guide you through this via PM or E-Mail. ?1 point
-
Hi Chris, I have yet to see any issue with image theft. Partly that's probably because the site doesn't get a whole lot of traffic. ProcessWire is far better at handling images than anything else I've used, and I don't utilise it's full potential.1 point
-
I can provide a module for this usecase: https://github.com/kixe/AdminHidePageTreeByRole ... or try one of them: https://processwire.com/modules/admin-restrict-page-tree/ https://processwire.com/modules/admin-restrict-branch/1 point
-
1 point
-
@szabesz No need new Module for Uikit source files ! Node example only for theme development, if you need admin theme customizations you can import uikit source files on your side. Node usage example is not for ProcessWire users, its only for theme development by @ryan or @bernhard. User can import uikit source files inside : /site/templates/admin.less You can add @uikit-source-path variable on wire/modules/AdminTheme/AdminThemeUikit/uikit-pw/pw.less You can change variable value normally on lately loaded file on less. // Import uikit, use less variable for uikit source @uikit-source-path: "../../node_modules/uikit/src/less/uikit.less" @import $uikit-source-path; Change @uikit-source-path variable /site/templates/admin.less @uikit-source-path: 'source/to/uikit/less/uikit.less'; div { border: 1px solid red; }1 point
-
1 point
-
The same code will work in a hook to Pages::delete. Adapted to keep it DRY: // Prevent the trashing/deleting of pages referenced by other pages $pages->addHookBefore('trash', null, 'protectReferencedPages'); $pages->addHookBefore('delete', null, 'protectReferencedPages'); function protectReferencedPages(HookEvent $event) { $page = $event->arguments(0); // Find non-system Page Reference fields $pr_fields = wire('fields')->find("type=FieldtypePage, flags=0"); // Implode for selector string $pr_fields_str = $pr_fields->implode('|', 'name'); // Find any referencing pages $referenced_on = wire('pages')->find("$pr_fields_str=$page->id, include=all"); if($referenced_on->count) { // Replace the trash/delete method $event->replace = true; // Link markup for referencing pages $referenced_on_str = $referenced_on->implode(', ', "<a href='{editUrl}'>{name}</a>"); $plural = $referenced_on->count > 1 ? 's' : ''; // Trigger an error message (using $session in case a superuser is trashing/deleting from ProcessPageList) wire('session')->error("You cannot $event->method page $page->name because it is referenced in a Page Reference field on page$plural $referenced_on_str.", Notice::allowMarkup); // Don't allow the trashing/deleting of this page $event->return = false; } }1 point
-
A hook for anyone still wanting a solution for this: // Prevent the trashing of pages referenced by other pages $pages->addHookBefore('trash', function(HookEvent $event) { $page = $event->arguments(0); // Find non-system Page Reference fields $pr_fields = $this->fields->find("type=FieldtypePage, flags=0"); // Implode for selector string $pr_fields_str = $pr_fields->implode('|', 'name'); // Find any referencing pages $referenced_on = $this->pages->find("$pr_fields_str=$page->id, include=all"); if($referenced_on->count) { // Replace the trash method $event->replace = true; // Link markup for referencing pages $referenced_on_str = $referenced_on->implode(', ', "<a href='{editUrl}'>{name}</a>"); $plural = $referenced_on->count > 1 ? 's' : ''; // Trigger an error message (using $session in case a superuser is trashing from ProcessPageList) $this->session->error("You cannot trash page $page->name because it is referenced in a Page Reference field on page$plural $referenced_on_str.", Notice::allowMarkup); // Don't allow the trashing of this page $event->return = false; } }); When attempting to trash a referenced page from ProcessPageList the page will at first appear to be trashed but in fact it is not, and on the next admin page load a notice will be displayed explaining the situation. I don't think this detail matters much because it only affects superusers.1 point
-
1 point
-
@xportde - hi Thomas. Unfortunately with the way this module is built, it can only ever work for one branch. There are other ways to achieve what you are looking for - this thread (https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/) contains lots of useful info, but keep in mind there are lots of hooks you'll need to implement to ensure everything is locked down - it's one thing to hide part of the page tree, but you also need to hide the pages from the top-level nav under Pages > Tree. You also need to prevent direct edit access to pages outside the allowed branches. You may also want to consider modifying the breadcrumbs (like this module allows). Honestly I think it's a shame that the core doesn't support this natively.0 points