bernhard

This should be quite easy using the bootstrapping feature of PW: https://processwire.com/docs/front-end/include/ Oops, wrong keyword, actually I wanted to link to multi-instance use of pw like @kongondo does in the next post ? You could then grab data from one install and show it on the other instance wherever you want. Yes, for bootstrapping multi-instance that's a good thing ?

Or to reduce the chance of wrong user input you could leave the three fields visible and hide the title field which you could then populate via hook

Hi @gerrmen and welcome, did you read the docs about url segments? https://processwire.com/docs/front-end/how-to-use-url-segments/ Seems like this could be what you are looking for.

Hi @SamC, really nice project! I've just stumbled over your admin theme tutorial: https://www.pwtuts.com/processwire-tutorials/making-a-custom-admin-theme-using-uikit-3-and-the-included-build-tools/ This is not true any more ? Maybe you want to update this tutorial?

@Zeka if you find time it would be great if you could write a little showcase/tutorial of this panel in the tracy thread ? Maybe Adrian could also use it for the docs... Everything is there already: https://adrianbj.github.io/TracyDebugger/#/debug-bar?id=request-logger ? Thx for the great work @Adrian!

That would be fun to build! ? If only I had time for it...

See tracy's Request Logger Panel

date('d/m/Y', $page->latestSubscription()->subsEndDate) // change this date('d/m/Y', $page->latestSubscription()->getUnformatted('subsEndDate')) // to this

PW is built to scale and there are some reports of projects with millions of pages: Though there might be situations where YOU need to know what you are doing. For example if you add some custom hooks that run on each pagesave and do not work efficiently you might run into problems. But you can also use PW with custom DB tables and custom SQL queries, so you can do anything that PHP/Mysql can handle ?

Yes. You can easily check that with tracy debugger: // ready.php $wire->addHook("Page::foo", function(Hookevent $event) { bd("foo was fired!"); }); You will not see any dumps of "foo was fired!" unless you explicitly call it somewhere else, eg $page->foo() in one of your templates.

Adding the hook like you did is perfectly fine. The problem must be in your head.inc that most likely calls the ipapiGetUserLocation() on every page load +1

I'm not sure though if that's a good idea. Usually I wouldn't touch the /wire folder at all. All site-specific things would go into the /site folder. I think it should also work to include your modules in /site/modules

@adrian his screenshots look like he's already using symlinks, that's why I asked for more details ?

Hi @Melvin Suter and welcome to the forum, Your setup should definitely be possible. When and where exactly do you get this error? What are you trying to do at this moment? An installation of a fresh copy of PW?

Hey @Steve_Stifler, since you are new and asking lots of "is there a module for..." questions in the last days I think you might not have a solid understanding of what PW is and how PW works so far. I mean, asking is perfectly fine, but working with PW means working with HTML/CSS/JS in the first place and not - as you might know it from other systems - installing plugin X and plugin Y and plugin Z. PW is something more developer orientated. Something that someone might call "Framework" or "Headless CMS". PW makes it easy for you (and your users/clients) to have a solid, secure and flexible place to store various types of content and manage it. It also makes it easy for you to DISPLAY this content on the frontend. BUT - different to many other cms'es - does not dictate how you do that. You could output your data as HTML page (of course), but you could also output it as JSON, PDF, RSS, chart etc... That's why there are only very few modules that are related to the frontend of your site (the cookie banner module comes to my mind). It's totally up to you how you present your content and what frameworks you choose (CSS/JS). If you are looking for a system that has (=needs) a plugin for everything, PW might not be the best fit. If you are willing to learn and take the next step from using plugins for everything to writing your own code snippets you'll get lots of help here.

Servus @dragan, I didn't deactivate any features of mPDF as far as I can remember. Can you try to set those settings via $pdf->settings([ yoursettingsarray ]) ? This is done on init() and can also be done manually: https://gitlab.com/baumrock/RockPdf/blob/master/RockPdf.module.php#L22

I like the grey background, but I'd prefer a dark grey border instead of the green one. In your case when the checkbox is checked it looks as if the button gets smaller because you use the background color as border color. That's also a little worse for accessibility than a dark grey I think.

No, I've accidently overwritten this version. But the second version is not accessible via keyboard anyhow. Damn... and I did it again! Now the pen https://codepen.io/baumrock/pen/pGXWxO has no shadow any more. It's the same as the second version but with grey border on focus to see it both on checked and unchecked state. Does codepen not save different versions like jsfiddle does when saving??

I was talking about :focus, sorry ? https://codepen.io/baumrock/pen/bzPrLV Edit: First I liked the styling of your toggle a lot, but looking at it closer, the drop-shadow is out of the surrounding container which does not look great. I changed my pen and removed the box-shadow and increased the border width to 2px. Not saying that this version is better - was just playing around with it... What do you think about this one with box-shadow but no vertical offset? https://codepen.io/baumrock/pen/zeVErm Ok, making the border green on focus is pretty, but does not work, because you'll not see the focus-state on checked checkboxes! I changed it to make the background dark grey (green would be prettier but misleading): https://codepen.io/baumrock/pen/bzPrLV Not so bad IMHO. This version also has horizontal shadow and it has 2px border instead of 1px. Ok, another one ? https://codepen.io/baumrock/pen/pGXWxO

Maybe you could add some nice styling if the checkbox is active (for accessibility / keyboard navigation)? ?

This is how I'm doing it in my migrations module: outdated

Hi Jeremy and welcome to the forum ? I know that feeling, coming from a terrible one ? Sounds like a lot of work ? And I know what I'm talking about: ProcessWire is great for building custom forms for whatever "datatype" you need (regular page edits) and for building relations between those pages. It is IMHO not so great for displaying this data in a user-friendly way. We have listers and we have MarkupAdminDataTable, but both are not ideal for a little more complex tabular data (and I guess that's what you'll need a lot for such a system). That's why I built RockFinder, RockGrid and recently also RockCharts (early stage, not released yet). All of them are not totally easy to use for non-devs. You'll also need to learn how to create custom admin pages, but that's easy ? And finally, you'll need to grasp the concept of hooks: https://processwire.com/blog/posts/new-ajax-driven-inputs-conditional-hooks-template-family-settings-and-more/#new-conditional-hooks To make everything maintainable (and maybe also reusable), you'll need to pack everything in a module: https://processwire.com/docs/modules/ Good luck and have fun ?

Hey @Robin S , just found a problem when using this technique for handling shopping cart content: The user can select products (choose colours in your module) and those colors are stored in the users session. But when the user visits a different page, the user gets logged out and therefore loses all his session data (including the cart products, here colours). Another problem would be ProCache as it would not be usable when users are logged in ? Happy to hear your thoughts.

This looks really promising! What do you think? I'm using this library: https://github.com/davidjbradshaw/iframe-resizer It's as simple as adding your iframe to your frontend: <style>iframe{width: 1px;min-width: 100%;}</style> <iframe id="myIframe" src="/your-public-backend-page/" scrolling="no"></iframe> <script>iFrameResize({ log:true, bodyMargin: '0 0 30px 0', }, '#myIframe')</script> Further improvements could be to sync the page url with the iframe url, but the great thing is: We'd only have to do this once and could use it on all our projects. No matter what frontend we are using! Imagine what a powerful tool this could be: Creating forms, registration pages, carts, event signup pages etc etc., everything as modular and reusable as we know it from the pw backend. And everything instantly styleable via RockSkinUikit ?

Thx Robin, this is (almost) awesome! ? I forked your repo and did two minor changes: I implemented a hookable method to modify the HTML, here to remove the admin url that is exposed in the pw config js object: https://github.com/BernhardBaumrock/ProcessFrontendAdminPage/commit/1fed071d3f951b82fbae6c98b2c4834efec2b6bd I removed the $session->redirect in the processmodule. I guess the reason why you did that was to get rid of the ?modal=1 parameter in the url? The parameter is appended in InputfieldForm when ?modal=1, so I reset this parameter on initialisation of the process: https://github.com/BernhardBaumrock/ProcessFrontendAdminPage/commit/d19f71c03b7169734dca243bc45f35a205782bf3 Do you know how/if we could throw a regular 404 on a Unrecognized path exception in the backend? Thank you very much for your work on this! ?