Leaderboard

@Mustafa-Online I made nice update today on this module after not having touched it in several weeks. It's now basically complete but before I release it I still need to clean up some old code that's left over, make it work more nicely with SelectizeAll and provide similar overriding capabilities that the UIkit theme has. This module includes Bootstrap Icons and it substitutes Font Awesome icons accordingly (I went through each one and found the equivalents!). It also uses the Bootstrap navbar and dropdowns. A side-effect of this is ajax-loaded dropdown content won't work in the first release. I may backtrack on using Bootstrap dropdowns depending on if that becomes difficult. Anyway, it's looking good overall. If anyone is wondering why use this as opposed to UIkit, it may be beneficial if you are doing a lot of custom admin stuff and want to use pre-made Bootstrap styled components since the Bootstrap ecosystem is much much larger than UIkit. Also, it feels a little more fresh, although my actual reason for creating this was to for a way for me to get a deeper understanding of how admin themes work.

It's been talked about elsewhere here in the forums, but an alternate idea would be utilizing .env files. It would satisfy both the installation process and long-term management of values. Some benefits: Widely used across applications, frameworks, and languages running in a web server environment and strongly recommended as a standard practice Secure by default. Web servers do not serve .env files Provides the ability to manage local and production configurations separately Frameworks like Laravel provide a .env file as well as a .env.example file containing all variables used in the application. This is kept up to date, used to document application requirements, and is committed into the repository Values that are not security-critical can be safely stored in the example file Provides a convenient location for additional non-ProcessWire site/app specific values such as API keys, or those required for modules Solves the issue of excluding site/config.php from a repository given that it's a required file containing specific syntax and $config object property assignments If .env was available in ProcessWire I would have my Fluency module look for translation API keys there rather than store them in the database. A benefit there is that different environments like local/ staging/production can mean an environment that is yours and an environment that is a client's. Pulling the latest copy of a database from production wouldn't require manually re-configuring modules that require API keys, or module registration keys. It would be good to eliminate storing security-critical values in PHP files entirely. The .env file could be generated and populated during the ProcessWire install process pre-excluded in the .gitignore file. Example: ENVIRONMENT="development" # ProcessWire PW_DB_HOST=localhost PW_DB_NAME="your_database PW_DB_USER=your_database_user PW_DB_PASS="LowuHeju7[BoI3" PW_DB_PORT=3306 PW_DB_ENGINE=InnoDB PW_DEBUG=true PW_CHMOD_DIR=0755 PW_CHMOD_FILE=0644 PW_USE_PAGE_CLASSES=true PW_USE_FUNCTIONS_API=true PW_PREPEND_TEMPLATE_FILE="_init.php" PW_USER_AUTH_SALT=d5e3ac4beda1e382255bbd8744d7e815 PW_LOCALE="en_US.UTF-8" PW_TIMEZONE="America/Los_Angeles" PW_DEFAULT_ADMIN_THEME=AdminThemeUikit PW_INSTALLED=1580675413 PW_HTTP_HOSTS = "domain.com,www.domain.com" # Some API that is used EXTERNAL_SERVICE_API_URL="https://api.someservice.loc/v2" # Development EXTERNAL_SERVICE_API_KEY=0d41fe1b68244f4ea51ae5e4abd24fab # Mailgun MG_KEY=key-192cde47ab73095e747ebe7556577b2d MG_DOMAIN="mg.somedomain.com" # Forecast.io FORECAST_IO_KEY=c28096383d66bcb1e2cb9ec37153f85c To take the idea further, it could be integrated with the ProcessWire API in a way that would prevent conflicts, keep .env variable naming organized, and make any value added by the developer available. Something like: <?php // An accessor method, this is probably the cleanest and resembles other frameworks $config->env('SOME_ENV_VARIABLE'); // Nested under a property acting as a namespace $config->env->SOME_ENV_VARIABLE; // On ProcessWire projects I implement some extras to easily interact with .env values without needing to access them directly. $config->envIs('production'); // boolean I haven't built a ProcessWire site without implementing this for many years and there's a great widely-used great package that provides .env values to PHP. There are also hosting providers that make environment variables/secrets manageable through their admin UI that eliminates the need for an actual file in production entirely. If ProcessWire were to implement environment variables it could look to values that may already exist and fall back to using a file. Implementation aside, if someone is able to access phpinfo() in production it's a critical issue beyond exposing config values given the totality of information dumped by that function.

Thought this might be interesting for the UIkit/Tailwind users, maybe best of both worlds?? https://www.franken-ui.dev/docs/introduction

@Jonathan Lahijani It's great you still working on this, can't wait to try it. I wish one day you make a tutorial on how to create an admin theme from scratch, as all forum's related content is outdated.

OK, here's my slightly revised `router.php` script: <?php if (PHP_SAPI !== 'cli-server') { die('Expected cli-server'); } if (file_exists($_SERVER['DOCUMENT_ROOT'] . $_SERVER['SCRIPT_NAME'])) { return false; } $_SERVER['SCRIPT_NAME'] = '/index.php'; $_SERVER['SCRIPT_FILENAME'] = $_SERVER['DOCUMENT_ROOT'] . $_SERVER['SCRIPT_NAME']; require $_SERVER['SCRIPT_FILENAME']; The main change is that `$_SERVER['SCRIPT_FILENAME']` is now an absolute path. Not critical, but more correct.

OK, thank you! It helps a lot to know that it *should* work. I'll keep trying to figure out what I'm doing wrong.

I'm doing exactly that in RockFrontend: https://github.com/baumrock/RockFrontend/blob/e2b0beb70427c39ade99dc36547a370dd091f59f/RockFrontend.module.php#L2338

The Download page says that 229 is the current master version: Composer and GitHub say that 227 is the current master version: The difference between .227 and .229 is ~8-10 fixes of various kinds.

Hey @bernhard, just updated a site to Rockfrontend 3.13.1 and noticed that auto-loading assets via $rockfrontend->styles()->add('foo.css'); $rockfrontend->scripts()->add('bar.js'); now has the order reversed in the generated markup. <script src='bar.js?m=1712642262'></script> <link href='foo.css?m=1713850912' rel='stylesheet'> Which in case of using UIKit is probably not ideal, since in my understanding the CSS should be loaded before the JS. Can you reproduce this or is something messed up on my part? Also, on a live site and with debug mode off, RF still renders a tag <script>var RockFrontend = {"isDDEV":false}</script> in the html head, wonder if that is necessary or what the purpose of that could be. Any pointers here? Not using RockFrontend.js if that's related in any way. Greetings to Austria and thanks in advance! ?

If you truly want to make an admin theme from scratch like I'm doing, it's best to just take AdminThemeUikit, since that is the "official" and most supported theme and rip out UIkit and start replacing it with your own approach and just hack away at it. Keep in mind that ProcessWire makes heavy use of jQuery UI and a few other libraries so you'll have to play nicely with them unless you want to replace them too, but that takes it to another level. With Bootstrap, it's straight-forward enough given the similarities with UIkit, although this is turning out to be more work than I anticipated. But that was the point since I want it to force me into looking at how everything is interconnected. One idea for an admin theme is to do it with pure, modern CSS and as little JS as possible and as accessible as possible (good reason why here).

Here's one place this was talked about in the past: https://github.com/processwire/processwire-requests/issues/142

For the present question about 1 product per user, here is example code: <?php namespace ProcessWire; $eventProductID = 2678; $customerEmail = 'wario_best@gmail.com'; /* NOTES 1. line-time -> padloper-order-line-item (order line item template) 2. product_id -> subfield in padloper_order_line_item field with product ID value 3. parent.order_customer -> Order is the parent of line items. padloper_order_customer is the field with customer details */ // $boughtTicket = $padloper->get("template=line-item, line_item.product_id={$eventProductID},parent.order_customer.email={$customerEmail}"); // if ($boughtTicket instanceof NullPage) { // // NOT YET BOUGHT TICKET // } else { // // BOUGHT TICKET ALREADY // } # OR $boughtTicketID = (int) $padloper->getRaw("template=line-item, line_item.product_id={$eventProductID},parent.order_customer.email={$customerEmail}", 'id'); if (empty($boughtTicketID)) { // NOT YET BOUGHT TICKET } else { // BOUGHT TICKET ALREADY } Let me know if you need clarification. Sorry for the delay! Thanks.

@Chris B there are a couple of ways. 1. The most secure... use a hook to add the value to the FB after submit (or whatever hook works for you best). See https://processwire.com/store/form-builder/hooks/ 2. In your template, use the options array to populate the page id into a hidden field that's rendered but not displayed, eg: $forms->embed ('my-form', array('postulate_job' => $page->id));