bernhard
-
Posts
6,671 -
Joined
-
Last visited
-
Days Won
366
Everything posted by bernhard
-
Hey @netcarver sorry for the troubles!! Is the file called migrate.php ? It looks like it should work! The only think that I don't do is strict_types=1 - maybe that causes issues? Don't know anything about that. Do you have tracy installed? Then you can inspect the logs panel and you should see everything that RM did. And you see if it did something, because if there are no changes or your file is not watched then changes will not be applied... Yeah this is part of the MagicPages features introduced 2 weeks ago. It creates fake pages in the trash to make sure it can load those pages on init() and ready() and trigger their init() and ready() methods to attach hooks. I'm not happy with that solution yet and it introduced some problems on some of my projects, so I'll fix this as soon as possible! Meanwhile you could just use an older version: https://github.com/baumrock/RockMigrations/archive/742f1fab8c727b3892835bb43d573e4f5aa7be0d.zip -
Randomize order in backend (actual order, not presented order)
bernhard replied to joe_g's topic in General Support
Could you pleas tell us why you want to do that to get a better understanding of the context? Also, what do you mean by "a large set of pages"? -
PS: One goal of the module is to be "zero-setup" and that's why I think some things should be enabled by default. But an option to disable them is of course valid. As another goal is to be "progressive" or "unobtrusive".
-
Hey @maetmar sorry it seems you got me wrong! I really appreciate your feedback!! I was just a little short in my answer, sorry for that ? I'm happy to improve the module of course. Some things are opinionated of course - but you never know if anybody will use your module at all, so it's just inefficient/stupid to think of every edge case upfront. But if people want to use the module I'm happy to hear that ? And if they have suggestions for improvements I'm happy to hear them as well of course. So please tell me what error you got so that I can check if that is something that needs to be changed/improved. That's the goal, yes ? I hate repetitive and boring tasks. And when it comes to Frontend imho there are many of them. This might be partly because I'm more into backend, but still I think the basics like adding fonts from google (gdpr complient) or adding a favicon, or adding a manifest file for better mobile experience, or adding SEO tags etc etc should be easy and fun. Yeah I agree and I thought I've already said that, just wanted to explain that it might not be the best idea to turn it off completely because other modules could rely on it. So it just needs a little more thinking. And it's easier if I get good reports by the community, so a little more details on your mentioned error would be good ?
-
IMHO no. Did you watch my video about that? The reason why it injects that automatically is to have a standardised way to inject scripts or styles to the frontend. So if one has RockFrontend installed every module can then modify the frontend to its needs. Without having to add something to the readme like this: "To make the module work, you first need to add this and that and that to your main markup file..." The ALFRED editor is an example for that, which needs both JS and CSS files to work and then is extremely easy to use (just by calling alfred($page) in your template file). Which errors?
-
Would be great to have ProcessWire listed to get some visibility! Though I'm not sure what benefits those quickstart options have?
-
your host seems to be localhost? it should also be "db"
-
Thx @maetmar for the valuable feedback. I see that this can be confusing ? Something like this: <?php namespace ProcessWire; /** @var RockFrontend $rockfrontend */ $rockfrontend->styles() ->setOptions(['autoload'=>false]) ->add(/path/to/your/file.css) ; $rockfrontend->scripts() ->setOptions(['autoload'=>false]) ->add(/path/to/your/file.js) ; ?><!DOCTYPE html> <html lang="de"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <?= $rockfrontend->seo() ?> Does that help? I'm short on time but I'm definitely happy to improve that part ?
-
Hi @maetmar thx for the report, please check v1.19.2 ?
-
Just a guess, never tried that, but if that worked than only if you call it RepeaterHeroRepeaterPage (both the class and the file) Template "home" --> "HomePage" Template "repeater_hero_repeater" --> "RepeaterHeroRepeaterPage" You should definitely extend "RepeaterPage" as this might have methods that repeater pages have and need!
-
Or just don't use the less files... You don't need to use less if you don't want to.
-
RockFrontend could maybe make your life easier, if you want to install it. You could then use LATTE to get super clean menu markup, see here: https://github.com/baumrock/RockFrontend#menus It comes with a helper method "isActive()" to add classes to your active menu items (the page itself and all of its parents). The example shows uikit markup but it should be very similar in bootstrap... Using LATTE's n:attributes feature (like n:if or n:class or n:foreach) you save you from all these ugly if/else/elseif (not yours are ugly, they are ugly in general in my opinion) ?
-
Yeah I was just wondering if "we" could/should change something in "our" communication... Maybe something like this: ?
-
Thx for sharing @zoeck It's always a little disturbing to read comments on such posts... So many wrong assumptions and judgements... It's such a shame... ProcessWire is such a brilliant and powerful tool. I've been working with PW extensively for several years now and still sometimes get the feeling that I'm just scratching the surface... And with all that power and complexity (beauty) behind the scenes ProcessWire still looks like something that even an intern can read and understand at first sight. How genius is that? And how wrong is this guy with his judgement?! But I can't blame him. I was in the same situation 8 years ago... I think that is a quite common reaction. And I wonder if we could do something about that. Or if we should? I don't know ?
-
yes, new_su has user id 1065
-
Set inputfield image minWidth via API inside repeaters has no effect
bernhard replied to gebeer's topic in API & Templates
Such things where fields need custom settings both on the frontend (page editor) and the backend (processInput) are sometimes not so easy to handle. Another example is customizing the toolbar of ckeditor fields based on the user role. The problem is that hooking into the inputfields render might not have any effect when the inputfield's input is processed. And it might also not have an effect when assets are loaded. Maybe you can set the settings in getInputfield() like shown in the linked thread? But for ckeditor fields even the getInputfield() hook is not enough when it comes to frontend editing... I think that are issues but I have not investigated further and chosen to go the easy route and create custom fields for every case... If you want to tackle that problem and find a better solution I'd be grateful ? -
Hey @gebeer thx for that great message, really happy to hear that ?
-
Just to clarify... I didn't want to make repeaters bad. RockMatrix is based on repeaters and it is absolutely great (for flexible page building). But what I found is that Repeaters are not my first choice when it comes to storing data. For example I've built a survey tool where I saved all the votes in a repeater field of the survey template. That sounded good because every vote belongs to the survey and in the admin gui you can easily inspect all the votes and you can easily loop through all of them via foreach($page->votes as $vote)... So far so good, but then I needed to do complicated calculations and it turned out that would have been a lot easier and more efficient if all the votes had been pages under one parent. Selectors would have been easier, calculations could have easily done in SQL rather than looping all the results in PHP (because you need the parent/child relationship which is easily available in PHP/in memory but not so easy to get from the DB/SQL). What I said might not be 100% accurate and there might have been good solutions even with repeaters, but I had troubles back then and I now have to tools to display all kinds of page data easily and in a great way using RockGrid. Because that's the other side of the coin: If you store everything in pages under one parent it might need a little more thinking where and how you present things. That's obviously easier with repeaters...
-
Well, more of a suggestion than a recommendation in https://processwire.com/blog/posts/pw-3.0.152/#custom-page-classes-vs-hooks Thx. He is just showing what you CAN do, if you want to. But there's no need for doing that. You could for example create a specific page class for your project that all custom page classes extend on. That could be helpful to share some common business logic. Let's say we had a project FOO and we had custom page classes EVENT and NEWS. Maybe both EVENT and NEWS share a common method that returns the slogan of our FOO project, which is "FOO is a great project!". You could create a FooPage: class FooPage extends Page { public function slogan() { return "FOO is a great project!"; } } and then if you extend that FooPage rather than the PW Page from your EVENT and NEWS pageclasses you can access the slogan from both: class EventPage extends FooPage {...} class NewsPage extends FooPage {...} $event = new EventPage(); echo $event->slogan(); $news = new NewsPage(); echo $news->slogan(); Now if you wanted to change the slogan you'd just need to change the slogan in FooPage and all other classes would reflect that change. You can also use traits for a similar thing which is even more flexible since you can let your classes use multiple traits. That's what I'm doing with my RockMigrations MagicPage to make those pages have (and also trigger) init/ready/migrate methods. But still they are just extending the "Page" class. Absolutely, but it is a rather large app, so difficult to encapsulate. The context is the same as the worked example here (which I will repeat for ease of reading): I'm still not sure I fully understand but I'm not using Repeaters or RepeaterMatrix at all nowadays, so I can't say much about them. The problems you are facing might just be another reason why I'm avoiding them ? But I might be wrong. I don't know ? I've built several apps based on Repeaters and I always got into trouble later. So I stick to the fundamentals, which are Pages rather than repeater items. Another example would be RockMatrix, where all items are just Pages and all have a common base class that they extend. So that could also be an example of the first question I answered above.
-
Where's that recommendation? I'm not sure I understand the question. Do you have an example or use case?
-
PS: If you are using RockMigrations you can simple use the MagicPage trait and you get an autoload pageclass that automatically triggers init() ready() and migrate()
-
processwire-rocks.com ?
-
I'd be very interested in some details and explanations on this ? I've been working with forms quite a bit and sometimes things where a little unclear to be honest. For example sometimes I had to do a $this->trackChange('value') to make my inputfield module save anything. While I found a way to make it work it would be nice to better understand the inner workings of the whole process ?
-
Celebrating 250 commits since Jan/2022 ?
-
There was no sarcasm at all. I was just asking for more information to help everybody (being it me or robin or teppo or anybody else) to provide the best solution for his exact problem... That was all the information provided. And that's exactly what my hook does: markup in edit page. "I want to add markup+css+js easily to page edit. I want to add field markup to page edit and also lister etc...". That are obviously different things and maybe not as easy to do as with just adding one simple hook. You'd maybe need two. That was sarcasm ?
