Leaderboard

I know I'm cutting corners here, but in my opinion that distinction already exists: "site" and "core". This should be easy enough for a client to grasp, though of course you may need to explain it (at least) once first ? ProcessWire is by design a modular system, even at the core level, and hiding that would mean that you are hiding a defining architectural design decision and — arguably — advantage over some other systems. If you need to go to such specifics (I haven't, and in fact I have never granted client access to modules at all, though that's of course more about business model; if the client hosts and maintains the site, they will need full access) I would argue that it's better to explain how and why this is actually a good thing, not an issue ? Meanwhile (again in my opinion) "site" modules are third party modules, regardless of who developed them, though of course it's not a huge stretch to argue that those built by Ryan are 1st party. If you want to signal that Ryan's modules are from the project architect/lead, I guess that could make sense. Still sounds like an oddly specific requirement from the client, though, and I would again explain why some "official Pro-modules" are used ?‍♂️

donut worry. this.is stupid scam emails by kids playings on moms computer https://udo.net.au/The-We-Have-Hacked-Your-Website-Email-Scam~5776

Hi, I had integrated ViteJS a year ago or a bit more, it could be used to build for example a dashboard, or even a website, but the main issue I faced was to make Server Side Rendering working with all the setup to be able to get better SEO/ranking. That's said, SSR code was done this morning ?? The test below was made on a non optimized Caddy setup on Windows with sad php-fpm. I built a javascript package which will be published on NPM to give you a smooth experience to integrate Vite into ProcessWire. I have to build a ProcessWire module to make thing even easier instead of putting some file in our template dir, that will be made asap as it doesn't require lot of work. It's also shipped with InertiaJS which I find no point of not using it, but could be used without it. Everything can work with Svelte Framework (I am a big fan of it, I feel like coding web on the 2k years), React work also, and Vue should work without hassle as any other frameworks/libraries. Just saying, but his one I think will not be much of interest for you, I also built a solution which replace Electron for building desktop application based on native code (Pascal) and JavaScript bindings, where ProcessWire is used as headless cms (I think I had already spoke about it in some threads), it could be used as is without the need to put your hand in native code. I'm curious to hear what others in the ProcessWire community think about using ViteJS for your development. Have you tried it before? What has your experience been like? Please share your thoughts and feedback in the comments, and feel free to vote in the poll below to let me know if you're interested in more tutorials and resources on this topic, like profiles, themes. And pheww, I am quite happy! ?

not security hole files .in /site/assets/cache/HannaCode not web access-ible so no need to die()

Just speculating about the SessionHandlerDB link: could this be caused by locking on the session table if there's a long running process holding a connection open somehow?

Cool, yes adding the empty parameter was ?

I'm creating a new topic in response to @cst989's question in the RM thread as I think this is a common question and misunderstanding when evaluating RockMigrations. It's also easier to communicate in separate threads than in one huge multi-page-thread... Hi @cst989 thx for your question and interest in RockMigrations. This sounds like you have a misconception in your head which is quite common I guess. Did you watch my latest video on RM, especially this part? https://www.youtube.com/watch?v=o6O859d3cFA&t=576s So why do you think it is a good thing to have one file per migration? I know that this is the way migrations usually work. But I don't think that this is the best way to do it. I'm not saying one way is right and the other is not. I'm just saying I'm having a really, really good time with RockMigrations and it makes working with PW in a more professional setup (meaning either working in a team and/or deploying PW to multiple locations and of course managing everything with GIT) a lot more fun an a lot faster and more efficient. If we look at how migrations usually work we can have a look at the other PW migrations module, which works just like usual migration modules work: You create one file per migration and you end up with a list of migrations that get executed one after another. See this screenshot from the modue's docs: In my opinion that screenshot perfectly shows one huge disadvantage of that approach: You don't see what's going on. You end up with a huge list of migrations that you can't understand on first sight. In RockMigrations this is totally different. You don't create one file per migration. You put all the necessary migrations where they belong and - in my opinion - make the most sense. An example: Let's say we want to add 2 fields to the homepage: "foo" and "bar". Ideally you are already using Custom Page Classes (see my video here https://www.youtube.com/watch?v=D651-w95M0A). They are not only a good idea for organizing your hooks but also your migrations! Just like adding all your HomePage-related hooks into the HomePage pageclass init() or ready() method, you'd add the migrations for your 3 fields into the HomePage pageclasses migrate() method. This could look something like this: Now let's say we develop things further and realise we also need a "bar" field: Do so see what we changed? I guess yes ? Now one big difference to a regular migration approach is that you don't write downgrade() or reversion migrations - unless you don't want to revert the changes! In real life I've almost never ever needed to revert changes. Why? Because you develop things locally and only push changes you really want to have on your production system. If you happen to have to remove some changes that you applied on your dev it's easy to do, though: You see what we did? Nice! So does everybody else that has access to the project's GIT repo! So all your team mates will instantly see and understand what you did. Pro-tip: You don't even need lies 43-45 if you didn't push those changes to production! If you only created those fields on your local dev you can simply restore the staging database on your local dev environment and remove the migrations that create the fields. Pro-tip 2: Also have a look at RockShell, then restoring staging or production data is as easy as "php rockshell db-pull staging" Pro-tip 3: When restoring a DB dump from the staging system it can easily happen that you have data in your database that was created only on the remote and you don't have on your dev system (like new blog posts for example). If you then open those new blog posts on your dev system processwire and the blog post contains images processwire will not be able to show those images (as only the file path is stored in the DB and not the whole image!). Just add $config->filesOnDemand = "http://yourstagingsite.example.com" to your config.php file and RockMigrations will download those files once PW requests the file (either on the frontend or also on the backend)! Having all your changes now in your git history you can even jump back and forth in time with your IDE: You could. I thought about that as well. But I think it does not really make sense and I hope my examples above show why. I'm always open to input though and happy to try to think about it from other perspectives. One final note: I'm not sure if what you say about $rm->watch() makes sense here. If you watch() a file that means that RM checks it's modified timestamp. If that timestamp is later than the last migration that RM ran, then RM will automatically execute the migrations that are in that file. All other files and migrations will be ignored. That makes it a lot more efficient when working on projects that have many migration files in many different places. When triggered from the CLI though or if you do a modules refresh then it will always trigger all migrations in all watched files. I hope that makes sense! --- Ok, now really a final note ? One HUGE benefit of how RockMigrations works (meaning that you write migrations in page classes or in modules) is that you create reusable pieces of work/code. For example let's say you work on a website that needs a blog. So you create a blog module and in that module you have some migrations like this: <?php $rm->createTemplate('blogparent'); $rm->createTemplate('blogitem'); $rm->setParentChild('blogparent', 'blogitem'); $rm->migrate([ 'fields' => [...], // create fields headline, date, body 'templates' => [...], // add those fields to the blogitem template ]); You'd typically have those lines in Blog.module.php::migrate() What if you need a blog in another project? Yep --> just git clone that module into the new project and execute migrations! For example in migrate.php this: <?php $rm->installModule('Blog'); If you follow a regular migrations concept where all project-migrations are stored in a central folder you can't do that! Of course you don't have to work like this. You can still write all your migrations in the project's migrate.php file. Because I have to admit that it is a lot harder to build a blog module that can be reused across different projects than just creating one for one single project! It always depends on the situation. But - and now I'll really leave it for today ? - you could also make your Blog-Module's migrate() method hookable and that would make it possible that you build a generic blog for all projects and then you add field "foo" to your blog in project-a and you add field "bar" to your blog of project-b. Have fun discovering RockMigrations. I understand it can look frightening at first, but it is an extremely rewarding investment! Ask @dotnetic if you don't believe me ?

Store, collect and update oembed data from external sources. This module uses the great PHP Library Essence by Félix Girault and adds some processwire magic. It is inspired by Ryan's example module FieldtypeEvents and the TextformatterOEmbed module by felixwahner. Thanks! Download & Install Github: https://github.com/neuerituale/FieldtypeOembed Modules directory: https://processwire.com/modules/fieldtype-oembed/ Composer: composer require nr/fieldtypeoembed

Today I've had a site with a logfile that has grown to 70MB over the years... PW is so low-maintenance that I usually just deploy and forget ? Now while having that 70MB is not really an issue - all parameters still by far in the greens - it's definitely something that could be improved. So I'm wondering: Do you do regular maintenance on your site? Or do you have a script in place that prunes logfiles? I could think of some kind of notification system that sends me an email if one of the logfiles grows over a defined filesize. Or a cronjob that automatically prunes logs to x days. What dou you think? How do you handle logs?

Others have mentioned how to do it in the Markup or in $config. If you wanted to do it using JS, this is how: document.body.addEventListener("htmx:configRequest", (event) => { // add XMLHttpRequest to header to work with $config->ajax event.detail.headers["X-Requested-With"] = "XMLHttpRequest" }) https://htmx.org/events/#htmx:configRequest Not meaning to hijack this thread and I haven't read through everything and I don't know how Markup Regions work...just want to mention that I have set up a GitHub repo for htmx + Alpine.js + Tailwind CSS + ProcessWire demos. It is early days but I am hoping to add all sorts of demos there, from basic to advanced ones, including backend and frontend examples. I'll create a thread for this work at a later time. Meanwhile (and I have nothing against the OP wish), I am happy to take on a challenge like 'how would you build this complex page using htmx' . OK, maybe not as complex as this app: From React to htmx on a real-world SaaS product ?: (too much todo, etc.). Edit First two demos are discussed in this thread:

Same as you, deploy and forget. I've noticed that when hosting providers update something, the log file starts growing with warning logs. I usually realize months later. I love PW?

@Pete, This is now ready. I have done two demos. In the first one, Alpine.js populates the modal with values that have been passed to its $store. These include details about a product's variants, client-side calculation of total price, etc. htmx adds to cart and displays success message. In the second demo, htmx populates the modal with values it fetches when the modal opens (via 'buy now'). It then passes the values (via the returned markup + x-init) to Alpine.js $store. After this, it is the same as the first demo...and htmx updates the cart and displays success notice. I was hoping to do a video demo + tut but run out of time. I'll do a better explanation here (or in a different thread) or in a video later. For now, the most important things to note are: I was hoping to do some very basic examples but got carried away with these demos. I hope to do very basic examples with very minimal markup in future. daisyUI is used here for its Tailwind CSS components (e.g. the buttons, modals, etc.). Stating the obvious here, but it is not needed in a final project. Note the folder structure in /templates/. Demos are in their respective folders in /templates/demos/. Although I would have wanted a simpler folder structure so as not to confuse, it wasn't easy to pull that off given that this repo will host various demos. I didn't want to create multiple templates that display the same thing. Hence, the demos .php files do the rendering and the handling of the htmx request for their own demos. This means the template 'products.php' remains clean and just loads the current demo's .php file (a render file, so to speak). The folder /templates/data/ has JSON of the fields and templates used in the demo, in case you want to test in a separate site. _func.php has a number of utility functions including one which can fetch dummy products from the Fake Store API, and use these to create products and categories. Selecting a demo automatically reloads the page. This is achieved via a redirect passed to htmx. Viewing the frontend will greet you with this, very colourful shop! I went wild with all the available daisyUI themes. The current theme can be changed using the select at the top left. This is persisted using a plugin by Alpine.js called persist. It plays very nicely with $store and x-data. Whereas it is very easy to use things like x-data with local data within a component itself (e.g., <div x-data="{ open: false }">), given the size of the demos project as a whole (now and in future), I decided to handle and store most of the Alpine.js stuff in a main.js file. This separation of concerns helps in the long run. All libraries are pulled from their respective CDNs. There are lots of comments in the demo files. Whilst this makes the files longer, hopefully you also get to understand what's going on. Most things are necessarily named verbosely. Things should be very clear. The demo site itself is not finished. E.g. currently, we only have a very basic template if viewing a single product. There is very little attempt to hide my ineptitude with respect to CSS ?. Any questions, just holla.

Long time no WillyC! Also, I agree.

Hi Ivan - it looks like you are also running SessionHandlerDB (as mentioned by the folks in that other thread). I have found many issues with Tracy and that module over the years so I don't run that module (except when testing) and haven't ever seen that error. For now (if you don't need it, I would suggest disabling that module), but I would like to see if @ryan has any ideas.

Another option could be copy/paste the core ProcessModule inside site/module (it could be patched on ProcessWire version upgrade, if needed, automatically). Maybe @Robin S will have a clearer idea.

Perhaps, next time you need to present the list of modules used do not show the /module/ page under the admin, instead, show /setup/upgrades/ (Upgrades module). The Upgrades module has a LINKS column with links to either support, details or/and directory. Based on that, maybe with some clever deducting logic, rows of modules in this list can be labelled (by coloring, adding additional column, tooltip) according to their "author type". Provided the list is hookable...

Issue fixed and module updated! Should be good but let me know if you notice anything else @gornycreative

Quick question regarding your usage: were you calling the function on its own? Or was it through the textformatter applied to a text field? What I could do is check if $options is not an array and in this case assume it's $field, but the $field argument is not used within the function as it's just there so you can do field-specific stuff using the hook. Edit: oh wait I just saw my mistake... on line 44 ?

Small thing, I was getting an error without any custom options defined. As is, the line where you set up the arguments: public function ___addFootnotes($str, $options = [], $field = "") { This results in an error if you do not pass an additional options array - e.g. just a $str and $field. An error on line 83 array_merge results - second argument is not an array. I didn't pull the repo via git so I can't do a PR handily, but reversing the parameter order resolves it. public function ___addFootnotes($str, $field = "", $options = []) {

Just pushed the 2023-04-08 update: ⚒️ Features Search: Added a first version (proof-of-concept) of the recipe search. #6 Prev/Next Links: Added previous/next links on the recipe pages to for faster navigation around recipes. #7 ? Bugfixes Twitter Meta/Social Tags #4 Internal links, SEO tags and assets #5 ? Misc changes Added: Transparency Report Added: Advertisement Added: Community projects Updated: About, Changelog Listing only 5 recent recipes on homepage, makes it a bit faster Enabled Table of contens on pages where necessary More in the Changelog.

I don't know a solution using TinyMCE but I used a textformatter in a similar case. I used TextformatterPstripper.

We add support for ProcessGraphQL with the additional module GraphQLFieldtypeOembed.