-
Posts
6,674 -
Joined
-
Last visited
-
Days Won
367
Everything posted by bernhard
-
How many documents? How many users? If you only have a limited number then a simple page reference field would be all you need. Just add a field "readby" to your documents page and add users to that field via API. You just need to make sure that you don't have too many pages stored in the page reference field. So if you have many documents but just a few users add the page field to documents. If you have many users but just a few documents add the page field to the user template and add read documents to the field. If you have many documents and many users go with the custom table solution that I showed here:
-
I'm quite sure you did, but just in case: Did you check if there is a plugin that can fix your issue?
- 31 replies
-
- 12
-
-
Checkbox Values Not Saving in Custom Module
bernhard replied to froot's topic in Module/Plugin Development
You have to read carefully. What I showed was the syntax for saveCustomField() method. You now posted the one for addCustomFieldToPageEditForm() - that are two different things. saveCustomField hooks into Pages::saveReady, therefore the $page is available as the very first argument of the HookEvent: $event->arguments(0) or $event->arguments('page') addCustomFieldToPageEditForm on the other hand hooks into ProcessPageEdit::buildForm, therefore the edited $page is available as $event->object->getPage() Your solution is fine as well, but it will only work for situations where the page id is available as a get parameter. So I'd recommend you read again my post/video about hooks here: https://processwire.com/talk/topic/18037-2-date-fields-how-to-ensure-the-second-date-is-higher/#comment-158164 -
Checkbox Values Not Saving in Custom Module
bernhard replied to froot's topic in Module/Plugin Development
Ah and I'm not sure if that is a good idea. wire('page') is the current PW page. Did you check if that is really the correct page and not the page with id 10 that is responsible for rendering the page edit form?? I'd better get the edited page from the HookEvent: $page = $event->arguments(0); -
Checkbox Values Not Saving in Custom Module
bernhard replied to froot's topic in Module/Plugin Development
I think you are just missing this after $field->description = ... $page = $event->object->getPage(); $field->value = $page->meta('custom_text_field'); ... and maybe some sanitisation in saveCustomField() ? -
Adding custom PHP code to any page in the backend is extremely easy as well (if you know how) ? <?phhp // in site/ready.php $wire->addHookAfter("ProcessPageEdit::buildForm", function ($event) { $form = $event->return; $page = $event->object->getPage(); if ($page->template != 'home') return; $existingField = $form->get('title'); $out = "Show 5 random pages:"; $pages = $this->wire->pages->find("limit=5, template=basic-page, sort=random"); foreach ($pages as $p) { $out .= "<div><a href={$p->editUrl}>{$p->title}</a></div>"; } $newField = [ 'type' => 'markup', 'label' => 'foo', 'icon' => 'check', 'value' => $out, ]; $form->insertAfter($newField, $existingField); });
-
How did you upload the file via api? Can you give a quick example to reproduce the issue? If you do that and post it to this issue and mention Ryan I guess chances are high that he will fix this quickly. At least I suggested the uploadName feature on Feb 16 and he implemented it on Feb 17 ? Maybe he just didn't think of API uploads.
-
New video about DDEV is out ?
-
We are live and have a very special guest in the video ???
-
Hi @ryangorley and welcome to ProcessWire and the forum. Thx for your introduction, this sounds impressive and it sounds like you can have a lot of fun with PW and maybe even help us to make PW more popular one day as PW really lacks good marketing in my opinion, but that's another story ? Back to your questions and back to the mentioned modules RockMigrations and RockFrontend, which I created. This is definitely a topic for me and I've talked to many other PW devs and it's a topic for many. I don't know what to do about that, but it's a fact that PW is very unpopular and infamous and it's also a problem for many that it's basically developed by one single guy somewhere in the world and nobody really knows what happens if something happens to Ryan. Also I often hear from clients that with wordpress they just use google or youtube and instantly find a solution for their problems. If that is good or bad is another story (I'm talking about the plugin ecosystem and the idea that anybody can build a website without any knowledge). But in my experience this is a very common opinion or perception among clients when they think about websites. "WordPress is so easy to use" is another one. On one hand I totally disagree, because the PW backend is usually so much cleaner than WordPress and my clients usually can manage their websites on their own instantly without any education, but on the other hand every website that we create with PW is an individually developed piece of software and works like the developer thought it should work. There are almost no restrictions and no standards, which most of us here love because we can develop everything the way we want and we think it's best, but on the other hand everybody knows how hard it can be to take over a PW website that someone else developed... Maybe it's a little like Windows vs. Linux - you can customise Linux a lot more, you have a lot more options, you have a lot more security, maybe a lot more power and possibilities. But it's more work. Windows is easier to understand. It has a solution for everything that you just install (like WP with its Plugins). Is it hard to convince clients to use Linux instead of Windows? I guess nobody here knows that better than you ? RockMigrations TracyDebugger RockFrontend RockMigrations is #1 because it installs #2 and #3 for me ? Actually the very first thing I install is RockShell, but that might be very opinionated and advanced. RockMigrations is also advanced whereas Tracy and RockFrontend are a no-brainer in my opinion. TracyDebugger A must-have for me in every project. It made me understand PW and PHP a whole lot better. It makes me a lot faster in my everyday work. It's an invaluable tool and I can't thank Adrian enough for developing it and sharing it with us. Pssst: https://github.com/sponsors/adrianbj The beauty of PW is that you don't need all this if you don't want to! Just use direct output for your first project and just put <?= $page->something ?> in your template files and enjoy the magic. Once you are familiar with the basics and you found out about the limitations of direct output have a look at the delayed output approach. I've been using markup regions for a while, but I don't like them any more. I think they are confusing and I think they should be removed from the default profile as they are adding another layer of complexity that should not be there at the very first impression that someone gets when discovering PW. Usually PW does a really good job in hiding complexity. It is really easy to use from the very beginning (both for the developer and the clients) but it provides all the power once you get more familiar and your projects get more complex. Markup regions violate this concept and your statement seems to support that impression. RockFrontend Whatever output approach you choose RockFrontend can make your development life a lot easier. It does not dictate you anything and there is not really anything you need to learn unless you want to. You can use RockFrontend solely for it's invaluable live reload feature. Just enable it in your config and you get instant reloads whenever you change a file. This can even be combined with TracyDebugger: I'm often using /site/ready.php to quickly test something and I'm using bd($foo) to dump the result to the tracy debug bar. Whenever I save the file I instantly get the result in my tracy bar without moving my hands away from the keyboard. Productivity ? If you want, you can then discover all the other great options that RockFrontend provides. LATTE/TWIG for example which is really just "echo $rockfrontend->render(your/file.latte);" or helpers for asset handling (you get automatic cache busting timestamps for example). I've created a video about all that one year ago: But again: If you only want to use the live reload feature - only use the live reload feature and nothing else ? RockMigrations This is a gamechanger. For me and in the meantime for several others. But it is totally worthless for others. It's an advanced module, but this does not mean that it is hard to use. Quite the contrary is true. Once you get the concepts it is really easy to use and it makes you a lot more productive and a lot more professional. It's like driving a car vs. going by foot. Learning all the rules and signs is not that easy. It takes some effort. But driving the car itself is not hard. It's in fact very easy. Steer, gas, break. That's it. When using RockMigrations you simply do in code whatever you usually do via mouse clicks. $rm->createField(...); $rm->addFieldToTemplate(..., ...); That's it. If you prefer to do that manually - do it manually. Carrying a bike from A to B might be easier by foot than by car. You might even ride the bike which makes it even easier if the road goes downhill. But what if it goes uphill? A car might be easier. What if you need to carry two bikes or three? A car might be easier. What if you want to carry the bike 200km? A car might be easier and a lot faster. So if you want to create reusable components (like modules) RockMigrations can be invaluable for you. If you want to develop projects in a team of multiple developers RM can be invaluable for you. If you want to deploy your project to several places (like DEV/STAGING/PRODUCTION) RM can be invaluable for you. Video time again ? Have fun with ProcessWire! PS: As @elabx mentioned DDEV is a great tool as well! I've done a talk about it lately and the video about it will be on my channel next week, so if that's interesting for anybody just subscribe to my channel or to the Rock-Monthly newsletter: https://www.baumrock.com/rock-monthly/
-
module AdminStyleChroma - Set AdminThemeUiKit Color Palette and Fonts
bernhard replied to gornycreative's topic in Modules/Plugins
Very cool to see a new AdminStyle! ? Also the font downloader looks great!! Need to take a look how you did that... -
[SOLVED] How to prevent users from uploading 300 dpi images?
bernhard replied to howdytom's topic in API & Templates
Thx @Jan Romero and both images have 25,7kB which is exactly what I tried to show ? -
[SOLVED] How to prevent users from uploading 300 dpi images?
bernhard replied to howdytom's topic in API & Templates
Hey @howdytom I might be wrong, but I think that you misunderstand the concept of DPI on images on the web. This is a good blog post to read: https://daraskolnick.com/image-dpi-web/ So as far as I understand DPI should really not matter at all on the web. All that matters are the pixel dimensions of the image. More pixels --> bigger file size. Less pixels --> smaller file size. I think that this statements are wrong. I tried to prove that using affinity photo but it doesn't even offer a DPI setting for exporting JPG images. You only get a DPI setting if you export a PDF, which makes sense, because there the DPI define the size of the image when printed and there it makes a huge difference if you print 1000 pixels ad 72dpi or 300dpi ? -
@heldercervantes shared a very cool project lately that has a neat text-reveal animation. I was wondering if it could make sense to add these effects to RockFrontend. Now I have two questions: Do you think it makes sense to add these to RockFrontend? As @Stefanowitsch was asking how it is done and is also using RockFrontend we'd at least be 3 users ? What about the technical part? What would be the best way of adding such scripts to RockFrontend? The problem that I see here is that adding everything to a global RockFrontend.js file will bloat that file over time. On the other hand having a single .js file for very small features will maybe result in many many JS files loaded in the document's <head> Or would you just use NPM or something to load all needed scripts? Or would it maybe be possible to load js snippets on demand via JS itself? What about the pro's and con's of every approach? I'm not so much into frontend development and I'm mostly using UIkit so I just include one file and have (almost) everything that I need. So maybe that's totally basic questions, or maybe it's something that can't be done "right", I don't know? Thx for your help in advance ?
-
setPageName method forces unpublished state?
bernhard replied to gornycreative's topic in RockMigrations
Hey @gornycreative thx for your question. Sounds like a bug, but I just tried on my website and it works as expected. It sets the page name and doesn't change the published state. -
Interesting idea! I've just found https://github.com/meyfa/php-svg which looks also like a good option?!
-
I don't understand what you are saying here. And it sounds totally contrary to what you say afterwards. RockFrontend's "addIf()" for adding single scripts depending on conditions is one thing, but replacing the whole markup is something totally different. If you are trying to do the latter you have two options. One is what you describe and make ProcessWire NOT use the _main.php file. Another option would be to be more explicit in _main.php and put something like this on top of the file: <?php if($page->template == 'foo') return $rockfrontend->render('my/custom/markupfile.[php|latte]'); ... // content of _main.php here that will be loaded for all templates except 'foo' Another concept that RockFrontend provides is the renderLayout() method. The concept is to put this in _main.php: <html> <head>...</head> <body> <?= $rockfrontend->renderLayout() ?> </body> </html> Which will tell RockFrontend to load /site/templates/layouts/default.php by default and load /site/templates/layouts/foo.php for all pages with template "foo". So you have lots of options ?
-
Thx. Yeah sounds good. Regarding the text I was wondering if it is a good idea to have that as text rather than converted to paths. Usually I convert it to paths for maximum compatibility, but that would make things more complicated I guess. But I didn't do any research here, maybe there are some linux tools update, seems I could do that with inkscape: https://stackoverflow.com/questions/15203650/programmatically-convert-svg-shapes-to-paths-lineto-moveto Or maybe I can include the font file in my svg?? https://stackoverflow.com/questions/71060147/why-is-my-svg-file-not-using-my-font-file Any advice would be welcome ? Edit: transfonter is an interesting tool! https://transfonter.org/ --> ubuntu bold with letters A-Z and a-z results in an 13kb css file, wich sounds ok compared to the alternative of installing inkscape on my server and converting text to curves on save...
-
I'm working on my new website that will list all my modules with docs etc.; I also want to have a logo for every module, but I don't want to have to manually create it. It's basically always the name of the logo plus an icon on top of a green hexagon: https://raw.githubusercontent.com/baumrock/RockFrontend/main/docs/logo.svg Are there any SVG experts that know how I could create those SVGs dynamically? I'd like to really create an SVG file, not only the SVG markup or a fake image with some CSS layering magic. I'd like to have an SVG created on page save so (after entering the module name and uploading the icon) that I can then instantly use for the docs on Github as well. Any ideas are welcome, but obviously if that is too much work it would also be an option to just create those images manually... It's just more fun if it's automated ? Thx in advance ?
-
I'd love to help, but I don't think I understand the question. This would be very easy: <?php foreach($pagearray as $page) { echo "<div>Parent: ".$page->parent->title."</div>"; echo "<div>Grand-Parent: ".$page->parent->parent->title."</div>"; } But I think that was not your question, was it? I guess your code-block with all the venues has some meaning as well, but I can't imagine what exactly you are asking for. And I also don't understand what exactly you mean by things becoming "unwieldy" at some point? If you are asking for some kind of search engine that's a whole other topic and can quickly become a lot more complex depending on what you need or want, but then again you'd have to be a lot more specific with your questions (at least for me to understand, maybe it's clear for others already). In general looping through pages and requesting data from parent or grandparent pages via API means that you load pages into memory. That can be inefficient if you are dealing with lots of pages. That's why I have built RockFinder and later we got findRaw() in the core. Both can load lots of data with an efficient and fast SQL query rather than loading everything from PHP. That's especially handy if you work with tabular data like data grids or such where pagination and sorting is done on the client side. For search results you could also add pagination and limit the number of results to 20 for example, then it shouldn't really matter if you load data via SQL directly or you loop some pages via PHP.
-
Hey @Stefanowitsch thx for the question. I tried, but it's not so easy. The feature has been developed for RockCommerce where I ship a fully working checkout that is both easy to integrate and to customise. All files are in /site/modules/RockCommerce/frontend/... and can be overwritten by placing the same file in /site/templates/RockCommerce I don't think that this will be very helpful to anybody else, so I thought it's better not to bloat the docs with that feature at the moment. But I've added docs for the static rendering feature, which can be very helpful for many projects I think: Static Rendering Static Rendering is a convenient feature offered by RockFrontend that simplifies the process of developing new websites or features. It provides an alternative approach to generating markup by allowing developers to write static markup for specific pages or components, rather than utilizing multiple includes and delving into the intricacies of the entire project's architecture. How it Works If your project is already using RockFrontend's renderLayout() method to generate page layouts, integrating the Static Rendering feature is straightforward. All you need to do is create static markup files and place them within the designated folder: /site/templates/static. When a user requests a particular page, RockFrontend's Static Rendering functionality kicks in. It examines the requested page's URL and checks whether there is a corresponding static file in the /site/templates/static directory that matches the URL's structure. For example: If a user requests your.site/foo/bar, RockFrontend will search for a static file located at /site/templates/static/foo/bar.[php|latte]. Benefits Static Rendering offers several benefits for developers, including: Simplified Development: Writing static markup can be more straightforward than dealing with complex includes and understanding the project's full architecture. Quick Prototyping: Static Rendering enables developers to quickly prototype ideas without the need to set up dynamic functionality. Unique Custom Layouts: With Static Rendering, you can craft highly distinctive layouts for individual pages, allowing you to create designs that stand out from the rest of the website and cater to specific visual and functional requirements. Isolation: Developers can work on specific pages or components in isolation without affecting the rest of the application. Implementation Steps Create Static Files: Write the static markup for the desired pages or components and save them with filenames that match the URL structure. Place these files in the /site/templates/static directory. Access Static Rendered Pages: Once the static files are in place, RockFrontend will automatically use them for rendering when a user accesses the corresponding URLs.
-
Thx guys that helps a lot and I'll try to check your suggestions when I experience the issue for the next time!
-
Thx for the input @netcarver I don't think that it can have anything to do with anything on the backend. PW itself is fast, I'm just experiencing a very laggy console on the frontend. Sometimes even the mac os spinner pops up for some seconds. Do you think that can have anything to do with sessions or cookies? I'm thinking maybe the SSE stream of RockFrontend/RockMigrations livereload could interfere somehow? Just throwing in an idea as well ?