Jump to content

bernhard

Members
  • Posts

    5,676
  • Joined

  • Last visited

  • Days Won

    264

Everything posted by bernhard

  1. Had the same need and also needed to show the labels of the field in template context: echo $fields->my_field->getContext($page->template)->getLabel();
  2. Couldn't you do something like this? $( document ).ajaxComplete(function() { yourFunction(); });
  3. Hey @SIERRA could you please read the community rules, especially the section about "Rules for posting"? You have posted several questions over the last years and often you just disappear. It might increase your chances to get helpful answers if you try to ask in a more polite and less demanding way and at least say thank you after someone replied and tried to help in his/her spare time for free. Have a nice weekend and good luck with your project.
  4. I think this is a big issue with quite an impact in many areas: https://github.com/processwire/processwire-requests/issues/176 https://github.com/processwire/processwire-issues/issues/1856#issuecomment-1878431067 We also have no events for modals, panels etc. We have a JS API for Inputfields already, so it would make sense to expand on that concept: https://processwire.com/blog/posts/pw-3.0.145/#inputfields-javascript-api I think this is one of a few cases where there are conceptual problems that Ryan should take more care about. I think these problems are not present enough in his head. Maybe someone can came up with a good writeup and maybe also propose a good solution? Sometimes that helps wonders, eg in 2020 I asked on stackoverflow about missing events in tabulator.info and the author of the library didn't seem to understand. Then in 2021 I posted the same thing in other words and he liked the idea a lot and it was instantly built into v5 and is now an integral feature of tabulator. I think it would be great to have a unified events system for the PW backend similar to https://tabulator.info/docs/5.5/events I could think of something like this: ProcessWire.on("repeaterItemAdded", function() { ... }); ProcessWire.on("panelClosed", function() { ... }); ProcessWire.openPanel(...); ProcessWire.addRepeaterItem(...); And I could imagine that Ryan likes the idea as I think code would get cleaner and easier to maintain - just like it happened with the Inputfields api some time ago...
  5. That sounds like a huge task πŸ™‚ Do you have any reference for that? From what I read it's "maintenance-only", so we'll not see any new features. That's a different story then I guess. But of course I agree that it would be nice to get a more modern looking/working backend. But compared to other CMSs I think it's still really not bad. And it's very well thought out for all the complexity it needs to handle. https://blog.jqueryui.com/2021/10/jquery-maintainers-update-and-transition-jquery-ui-as-part-of-overall-modernization-efforts/ But remembering when AdminThemeUikit was born I guess Ryan will come up with a genius solution once it is necessary πŸ™‚
  6. seems @teppo created an issue for this and it seems to be fixed now: https://github.com/processwire/processwire-issues/issues/1867
  7. Hey @FireWire looks like fluency has problems with & πŸ™‚ I also checked on on older project - same problem. Reproduce: "Foo & Bar" and hit translate Thx πŸ™‚
  8. Developing is always so complicated πŸ˜„ Haha thx for the spot! I'll have another look πŸ™‚
  9. @netcarver and @Christophe please check out v5.1.1 that fixes the issue! https://www.baumrock.com/en/releases/rockpagebuilder/ The demo is also updated: https://pagebuilder.baumrock.com/
  10. Using RockMigrations you can now do this in /site/ready.php. It will remove the publish button and it will prevent publishing via API as well: <?php // prevent publishing of pages with id 1010 and 1012 rockmigrations()->preventPublish("id=1010|1012"); // optionally allow publishing for superusers rockmigrations()->preventPublish("id=1010|1012", true); @Robin S code was not working for me, because removing the checkbox from the form means that on every submit the page will be automatically published even when clicking the "save + keep unpublished". Here's what I did: https://github.com/baumrock/RockMigrations/commit/de7a39b7ad0e58ed7f174db8954672f3dcbf103e Ah! And it will inform you about where the preventPublish() call happened πŸ™‚
  11. hey @gornycreative seems that I missed that one. @millipedia created an issue (https://github.com/baumrock/RockFrontend/issues/21) and referenced your post. The issue should be fixed now on the latest commit of the dev branch (https://github.com/baumrock/RockFrontend/commit/594dd2b1090519cc43f585919e7d47d9c472f381). 😎
  12. Hi @Christophe I don't think that this is related, because I don't get any 404s (except the one for the missing favicon.ico) on FireFox. You can easily cross-check that on pagebuilder.baumrock.com There are no errors so it means there's something screwed up on your end. Next, the error you are seeing is - if at all related to my modules - coming from RockFrontend. Please create a topic there where you ideally provide a step-by-step guide to reproduce this issue. Or if that is not possible for whatever reason it would at least be necessary to provide explanations in what you did, what techniques/frameworks/infrastructure you are using, when the error started to come up etc.; What is weird on first sight is that it seems to try to load less files directly without parsing them to css? Do you have the less module installed? Did you follow the installation video?
  13. Ok great, I found the issue and now everything makes sens! πŸš€πŸ˜ŽπŸ˜… Please grab the latest release of RockPageBuilder here https://www.baumrock.com/en/releases/rockpagebuilder/ and also upgrade RockMigrations to v3.35.5 The Problem was the removeFieldFromTemplate() method in RockMigrations. This method also removed global fields from any template if the "force" parameter was true. This operation made the title field non-global, which led to the problems we were seeing. Which makes sense now. Usually it's very unlikely that this ever happened but when working with RockPageBuilder you often have blocks that don't need a title field. That's the same for repeater fields, so I explored how it is done there. It would not be ProcessWire if there was not already a solution for it πŸ™‚ So I learned that every template has a "noGlobal" flag that you can enable and if that flag is enabled then global fields will not be added on template creation and it will also make sure that the RPB blocks don't make any problems if you remove any global field (eg the title field). That's a great update and makes RockMigrations a lot better. Thx for the reports and help with Debugging! Enjoy the new release and please mark the topic as solved πŸ™‚
  14. Update: Ok showing the error message was a good idea. I can now reproduce the issue. For me it happens when I remove the title field from a RPB block.
  15. Could you @Klenkes and @Denis Schultz please install RockMigrations v3.35.3 (latest release on the main branch)? That will add a check for the title's flags on every run of migrations and log some information to the log and show a warning on the backend. If that happens it would be great if you can report what you did and when it happened and maybe share some informations from the log!
  16. Ok this one is a very easy fix for everyone experiencing this! Just make sure that the title field has the global flag enabled: I don't know why or when it loses that flag yet, but I have it on 2 projects so it seems to be an issue. It would be nice to get some feedback if anybody else is experiencing this as well?
  17. Installed RockMigrations - all good Installed RockPageBuilder (+RockFrontend) - all good Installed Accordion Demo Block - all good Installed TracyDebugger - all good Do you have any other Rock modules installed on that website?
  18. Ok first bug will be fixed in the next release. The field hints for rockmigrations messed up the field select, so if you saw something like the below that's history πŸ™‚ I'm working on the issue with having no title field now as that is something else unfortunately πŸ™‚
  19. Yeah I don't think it has anything to do with that setting. It's related to RockMigrations I guess. I'm already searching and just killed my current project by disabling autoload for RockMigrations. Not a good idea if you are using MagicPages because then nothing will be usable any more, no frontend, no backend πŸ˜„ I had to add this at the very top of index.php and then enable autoload back to normal: require_once __DIR__ . "/site/modules/RockMigrations/classes/MagicPage.php"; Maybe someone finds this info helpful some day πŸ™‚
  20. Ok I can reproduce this so I'll have a look into this instantly! I'll be back πŸ˜„
  21. Thx. This one I have seen myself so it looks I need to fix this. These things are always hard to find as you never know where they are coming from, so a report like this is helpful as it says that it's coming from RockPageBuilder and not another module. BUT. Could you please provide step-by-step what you are doing and when you are seeing it? Because it does not appear when I'm just editing the homepage and then try to leave! There must be more steps involved?
Γ—
Γ—
  • Create New...