Jump to content

bernhard

Members
 View Profile  See their activity

  • Posts

    5,711

  • Joined

  • Last visited

  • Days Won

    269

 Content Type 

Everything posted by bernhard

  1. bernhard
    Well said @LostKobrakai! Agreed 100% IMHO that depends a lot on your skills. For me it took very long to understand how the backend works and what all those (process)modules do and how all this plays together. That's why I wrote my tutorial blog post (which by the way took also very long, so I perfectly understand that ryan does not have this time - especially if it is correct that CMF users are not the target audience (and that's what I meant in my short statement above where I said that I think that ryan does not really care). And even if you are highly skilled it would be a lot more efficient to read good docs than to read good code. I liked to read @Robin S answer and I'm sure it was not meant bad ? I agree with you that it would be a lot easier if we had proper tutorials (not just api docs and example modules) about all the backend stuff. I've mentioned several times that I think that the community management and teamwork on the project could be improved. It feels like ryan does all the work and if he has no time for something, it's just not done... On the other hand writing my guest blog post was easy: I just asked ryan if he was interested and I got a login and started writing... It's for sure not a perfect documentation about the backend, but it's a first step and I invite others to follow ?
  2. bernhard
    That's a different topic then, so you might be right ?? You can see this thread how @Noel Boss developed his theme and a new question that I asked right now: It might also be possible to build a custom theme easily by replacing the _main.php file of the uikit admin file. You can try that out by copying the AdminThemeUikit folder to the /site/modules folder, then refresh your modules und tell PW to take the /site/modules version of the uikit admin theme. Then you can use a _main.php file like this: <body class='<?php echo $adminTheme->getBodyClass(); ?>'> <div class="uk-text-center uk-padding" style="border: 5px solid red;"> this is a demo header </div> <div uk-grid> <div class="uk-width-auto uk-padding" style="outline: 5px solid green;"> this is a demo sidebar </div> <div> <!-- MAIN CONTENT --> <main id='main' class='pw-container uk-container uk-container-expand uk-margin uk-margin-large-bottom'> <div class='pw-content' id='content'> <div id='pw-content-body'> <?php echo $page->get('body'); echo $content; echo $adminTheme->renderExtraMarkup('content'); ?> </div> </div> </main> </div> </div> <?php echo $adminTheme->renderExtraMarkup('body'); ?> </body> So I still think that building a wrapper around the pw admin will be a lot easier than building a GUI for the frontend on your own. Think of repeater inputs, file inputs with AJAX, security, CSRF and multi-post prevention, session handling, tabs, sidebar panel / modals, input validation and and and... PS: Just tried the upgrades process module, it looks like this: And the hello world process module: It does not show the warning and error messages - so this approach needs some tweaking, but it's a good first step and I'd be happy to see what you come up with!
  3. bernhard
    Hey @Noel Boss, me again ? I still don't get how your theme works or how you built it. Where do all those LESS files come from? I see you include a copy of UIKIT in your module including all the regular uikit less files. But there are lots of pw related LESS files in it as well: Did you build those files on your own? I can't find any less files in the PW core... I've already successfully built a custom UIKIT frontend theming module where LESS parsing is done on the fly via PHP: https://screencast-o-matic.com/watch/cFXnX1Y72l It would be great to have such an easy way of customizing the backend as well.
  4. bernhard
    Don't think you are missing anything. My first idea was a repeater.
  5. bernhard
    I think you are wrong ? Bringing custom functionality into your PW backend is simpler than you might think: The benefit is that you have ALL the features of PW built in, as @teppo already mentioned. You can build things like this: You should also have a look at RockGrid, if you want to show tabular data: PW is great for building backend applications. The only part that is not so clean/easy is how you handle migrations/upgrades. But that would not be different if you chose to build a custom frontend GUI for your users rather than using PW's backend. I had the same desicion to take before I started with my CRM and I'm really, really happy that I chose to stay in the PW backend.
  6. bernhard
    Same here: I usually put those things in a tab on the root page: Rendering the menu is easy: <div> <?= $pages->get(1)->footermenu->implode(" | ", function($p) { return "<a href='{$p->url}'>{$p->title}</a>"; }); ?> </div> Config Settings is a repeater field that populates a custom API variable with site settings: $uk->config->company and branding:
  7. bernhard
    Could you elaborate "bad sign" a little more please? I guess you are right and I guess ryan does not really care ?
  8. bernhard
    RockGrid is perfect for such scenarios: You get nice, condensed, sortable, paginated tables You can style cells easily (like statuses for sent, pending, draft etc) You have a batcher built in, making it possible to send x mails at a time, running via AJAX so you don't get server timeouts The main reason why I released it under the MIT license was that it can be built into other modules easily. That would be a process module and MarkupAdminDataTable and LOTS of custom code...
  9. bernhard
    I'd load all quotes on page load and display one random quote via javascript. Similar to this example https://embed.plnkr.co/plunk/RHIPp8
  10. bernhard
    Some what? 5-10? 100s? 1000s? Yes ? But I don't get what you are trying to do exactly. Where does the user click? What should then be showed? Some quotes randomly sorted? Or one random quote of many? Please be more precise in your question - there are always many ways in ProcessWire and the best depends a lot on the scenario.
  11. bernhard
    Just read "headless" on their site and thought this would be an important keyword for processwire.com as well. Maybe something like: I'm neither a native speaker nor a marketing slogan guru, but I hope you get what I'm trying to say. And as a proof, this statement could be linked to this video as discussed here: While I love that video content and know how true every word in it is, I think for new users this might not be obvious. Quite on the contrary, I think a video with one stranger telling something about a great system that he developed in his living room (sorry ? ) does not have the professional impression that it deserves. Also 33k views since 2010 is really not a lot - all of us know that these are no fair indicators for the power or greatness of processwire, but new users might not get that. I think it would be great to have a 2minute introduction video in a modern and professional design. I even think that it would be great to let this video have 100% the same text of the first 2min of the ancient video from 2010 to show how revolutionary the platform was back then (all modern CMSs sell that as the new big thing) while on the other hand PW has it for 10 years and has been stable all the time! Maybe someone could help with such a video? @heldercervantes or @Jonathan Lahijani ? One more thing that I like on modern websites about products is a section where the product is compared to other players in the market. Like runcloud does it on their website: Here is how such a page looks like: I think such pages could make a LOT of sense because people already know DroomlaPress and such a comparison page could outline the differences and show the strengsths of processwire in a fair and efficient way. If you try to compare it via google/youtube searches processwire will always lose the game because it's just not focussed on marketing the way the other platforms are. But that could easily be outlined on such pages, e.g. comparing CMS XY to PW: Good luck with the new processwire.com and happy and successful new year to everybody ?
  12. bernhard
    Maybe it's easier to let Google do the heavy lifting and just display the results on your website... https://processwire.com/blog/posts/composer-google-calendars-and-processwire
  13. bernhard
    Never had any problems loading the tracy settings.
  14. bernhard
    In general there are 3 things to watch out Any redirects in .htaccess file? Any redirects in Apache config (see your webserver or panel config) Any redirect settings in pw backend (template settings for http/https, trailing slash yes/no) Two of them are likely working against each other and leading to an endless redirection loop
  15. bernhard
    This post by Ryan shows how you can do it. I've never done it on my own, so I'd be happy to see a step by step guide that I might add to my custom admin pages tutorial!
  16. bernhard
    Hi @tpr I've had a problem when using the skip trash feature of AOS with ProCache, here is Ryan's explanation: Is this feature only enabled for super users or for everyone in the admin? Maybe it would be better to trash pages first and delete them thereafter (automatically) rather than skipping the trash? Here is the complete post: Are you aware of that?
  17. bernhard
    Thx @Robin S, interesting points. As always it's not black/white - the question is how far one can/should go in terms of packing things into a module vs. building it from scratch all the time via the API. IMHO there are standard things like blogs, forum, sliders, guestbook etc. that are not that easy and quickly to create with PW and therefore cost a lot of time and money on my end. I wished I had more reusable products for such tasks. And I'm working on it. On the other hand I love the freedom of PW. But I think both worlds can live well together in our universe. And that might be another argument for using regular fields over custom fieldtypes @kongondo: When using regular fields, the user can easily customize those templates to their very own needs. Imagine a blog module that ships with fields blog_title blog_date blog_content blog_gallery If the user needed a field to store files he could either create a PR with an update script (again both migrations and export/import would not work) or create this single field on his own and just use it for himself. This would not be that easy if those 4 fields where wrapped in a single custom blog fieldtype (that would be the WordPress way of a plugin). Do you understand what I'm trying to say? ? Not trying to convice anybody here - just enjoying to get valuable input as this is in my head for quite a long time...
  18. bernhard
    I don't think that this is a special case at all. Imagine a slider module that could help us to create an image slider for our websites. It could create the markup (maybe let the user choose the css framework) and it could also create the necessary fields in the admin and add those fields to the templates that should display a slider. I've had lots of those situations finding myself copying and pasting code snippets from one site to another. Finding a bug in one page, having to fix it in all my sites manually etc etc. Now, that's what I call messy ? If we had a proper API that made those tasks easy, I think we would get a lot more reusable modules just like the SEO module, because then it would be a lot easier to create such modules and push fixes, changes or updates. And upgrading existing projects would only be one click (or git pull). Agree! I've learned a lot from your modules. But I still think the API need one abstraction layer on top of that. See for example how hard it is to edit a field in template context: https://processwire.com/talk/topic/6656-change-field-description-in-context-via-api/ It should be somethink like this, imho: $api->editInTemplateContext('mytemplate', function($field) { $field->label = 'Custom label for mytemplate'; }); The migrations module offers some of those helpers. It's one step. But there is at least one more step missing...
  19. bernhard
    It's a perfect example of what I'm talking about: It creates these fields: And as you can see in this example it automatically adds these fields to two selected templates. These tasks are really not as easy to develop as they could (should) be imho. Once installed, you can then input data on all pages with selected templates: You can't do that using process modules, or am I missing some concept here? There are MANY use cases for this. Interesting you mention this. It's something I've thought about previously. If I had to redo the Blog module, I would combine some of the fields. Your example of an address field would maybe make sense to be combined in one new fieldtype. But in many cases I think this is not the best option. I care! Developing a new Fieldtype is a lot more effort than just creating fields, assigning them to templates and creating new pages! But as soon as you want to make that process reusable (eg for dev/staging setup)/revertable you need to use something like the migrations module. But what if you wanted to use 3 of the fields that you created via migrations in another project? Bad luck, not possible - or is it?
  20. bernhard
    JSON export/import IMHO is really not a good way of doing that programmatically. There are always situations where you FIRST need to have the templates existing and THEN you set the correct settings. You can't do that in one step. Simple example: - create template "blogposts" - create template "blogpost" - set allowed children for "blogposts" to "blogpost", parents to "home" - set allowed parents for "blogpost" to "blogposts", parents to none You simply can't do that via import/export, can you? That's a special case because it's a module that is all about PW fields, templates and pages - indeed anything in the PW API. Reading this I have to clarify: Didn't want to say that the module is bad in any way. The module is great, but the situation we have is not great...
  21. bernhard
    So you think MarkupSEO would be better as a single Fieldtype having all those inputs and storing it in one db table? I don't think so, but maybe I'm wrong, so I'm curious to hear your and other's thoughts. What about creating a blog module where you can add new blog posts that have a title, content, publish date, date, image gallery etc etc. - create a fieldtype for that or just use PW's core fields and put them together in one template, setting a parent template to allow only these kind of pages as children. What about creating a slider module? Using a repater with images and text fields for headlines. That's easy using core fields. But the problem is that we are always building custom solutions that we can not reuse in other projects. Because it's so easy to create fields/templates/pages in the admin GUI, but it's so hard to create then via code (compared to the GUI). Using Migrations is a first step in the right direction, but you cannot split those migrations up to several places (meaning: modules). IMHO that's a real problem. Exactly. At the moment! I wished there was a better way. Something like migrations for each separate module. I mean... Fields are the way to store all the user input in processwire, so I think it's a real problem that we cannot properly use that core features easily in our modules.
  22. bernhard
    That might be true, but IMHO that's a huge limitation of PW. I've had the need to create fields/templates/pages a LOT over time. Many of us are now doing it manually (creating fields on dev, then importing them on the live system). We also have the Migrations module, but that's only half as good as it could be. At the moment it is really hard to develop modules that ship with a certain setup of fields/templates/pages and maybe on later versions upgrade those settings. I'm thinking for a long time now of a new kind of API that makes these operations a lot easier (adding and removing fields/templates/pages etc. is not easy, especially if you need to take care of collisions (field already exists, can't remove field because it's used by a template etc.). If anyone is interested in helping on developing such a module - similar to the Migrations module - send me a message.
  23. bernhard
    I guess @Gadgetto is talking about how to create/edit/remove/move/etc fields/templates/pages/etc. when they are necessary for an installable and reusable module? Then pages import/export is no option. You can have a look here how you can do that: https://github.com/nicoknoll/MarkupSEO/blob/master/MarkupSEO.module#L971-L1095
  24. bernhard
    Finally ?? Thank you adrian for this awesome tool and your great support in the forum!
  25. bernhard
    @jmartsch now you can:
×
×
  • Create New...