teppo

That works as well! Main reasons I don't (practically) ever use this approach have already been mentioned here: I'd have to block access on template level (may need to do that on a lot of places), search features and highlight lists etc. all have to be aware of this, and so on and so forth. Potentially having multiple developers work on the site doesn't really help either. At some point you're very likely to show publicly something you didn't intend to. Want to schedule pages? install SchedulePages. Need more scheduled content? Add two fields to the template. Easy as it gets ? Also, as a general rule if thumb, I try to do as little permission/access checking myself as possible. Sure, in this case it's probably not a big deal, but... ? "ProcessWire — there's more than one way to do it" ✌

Thanks @Mikie! I'll take a closer look at this ASAP ?

SignalR apparently uses WebSockets behind the scenes to achieve a "real" push effect. I'm not at all familiar with this technology, but if you really need push (instead of polling the server periodically as in the example above — which, for the record, is in most cases quite enough), you could look into something like Ratchet (a PHP WebSocket implementation), or perhaps build that part of the site in JS and then use pretty much anything as the back-end (Node, etc.) Anyway, you're right in assuming that ProcessWire doesn't have anything built-in for this particular need. ProcessWire provides tools for managing content; what you do with that content is not its concern, and technically "pushing the content to the client via WebSocket" is more a matter of presentation than content management ?

Title text is not a best practice when it comes to usability; visible text would be best. Not just because things shouldn't be hidden (unless there's a good reason for it, which I really don't see here), but also because it'll be a problem from accessibility point of view, for touch screen users, etc. Overall there are very few cases where the title attribute should be used ? This makes sense ? I think your suggestions are already pretty good! "Show time input" could be just "show time" perhaps? And "show end input" could also be something along the lines of "date range", though not sure about that one. This brings to mind one question: what do you think about making the labels configurable? For an example if we're talking about events, a label such as "all day event" would probably make most sense (and Outlook Calendar uses this as well, so it's somewhat likely to be familiar to users), but events are not the only use case, so the default label probably shouldn't mention "event" specifically ?

To be fair publishing (or un-publishing) pages at set time vs. just listing pages based on a datetime field are two different use cases. In some cases the distinction may not matter, but in others it will — i.e. when something really shouldn't be viewable before a predefined date/time ?

If I understood this correctly (instead of text, there's now just an icon?) I would actually recommend against this — simply because icons will never be as obvious as text labels. From an usability point of view text labels are much better ? From an accessibility point of view, on the other hand, this is just fine — as long as your checkboxes still have proper labels. If the icons are images an alt text is quite enough, but if they're something else (<i> with FA classes etc.) you should hide them from screen readers with aria-hidden="true" and then introduce a separate screen reader only text version.

Another SchedulePages user here. Works just fine for PW3 ?

Managed to miss this one. Check /site/config.php, you should find the database host/domain, credentials, etc. from there.

Hey! Bernhard already summarised the steps quite nicely above, but one thing I'd like to add is that if you do run into Windows specific issues, you might find solutions from some of the existing threads — e.g. On a loosely related note, the forum search can be pretty horrible at times, so if you're looking for something specific you'll usually have better luck googling for it (site:processwire.com/talk) ?

Just an idea: it's not the most street credible way to use Vue, but if you've got an existing app and you want to give it a try to see how it would work for you, adding it via a CDN is always an option. You won't get the benefits of a build process or all of the benefits of a full blown JavaScript framework, but what you should get is a rough idea if Vue is the right fit for your needs. Once you've (re)built a part of the admin side with Vue, you can decide to either dive in deeper, or just stick to good old jQuery+HTML ? Even if you go with the full "vue create app" route, you don't have to rewrite your entire site. For an example I recently built a PW website with a single Vue app embedded within — a member catalogue with a lot of data, sorting, filtering, etc. involved. Would've been a major headache with jQuery+HTML, but Vue made it pretty easy. I used Axios and treated one path of the PW site as a simple JSON API, which was — apart from some head scratching related to Access-Control-Allow-* headers — basically a no-brainer. Would do it again. Note: in the example above the page itself is served via PW (we've also done full-blown Vue SPA's with ProcessWire, but that's a very different route). Vue app is built in a separate location, generated JS file and required assets are moved to a directory within /site/templates/, and then the JS file is embedded within the page's markup. PW outputs a HTML element with an ID, which you then tell Vue to render the app in.

I can't properly compare Svelte vs. Vue as I've zero experience from Svelte (and not a whole lot from Vue either), but regarding this question: it depends a lot on how complex stuff you're planning to build. I'm still using jQuery — or just vanilla JS, since native features have mostly caught up with jQuery by now — for stuff I can do almost completely with plain HTML and CSS (with a PHP backend), while for "complex" front-end stuff where a lot of data is processed, sorted, filtered, displayed (possibly in different ways), etc. I would definitely go with Vue. From what I have heard, the most common argument for Vue (vs. Svelte) seems to be that the Vue community is much more mature, and you'll find a lot more ready-made stuff for it. And, of course, more people with the same issues (which, as a relative newcomer to the JS scene myself, I've found really useful). This is all very opinionated, but the way I see it, jQuery is great if you just want to sprinkle HTML with some added-on behaviour, while for bigger stuff it actually tends to get more complex than if you'd chosen a full-blown front-end frameworks in the first place. So again, it depends on what you're actually building ? If you do decide to go with Vue, for admin UI's in particular you might want to check out https://vuetifyjs.com. With Vuetify you'll have to sacrifice some freedom in terms of UI design, but once you get up to speed with it, it's pretty amazing — in many cases seemingly complex stuff gets done in a matter of minutes ??

First of all: for feature requests you might want to open an issue at https://github.com/processwire/processwire-requests. This is how it'll have the best likelihood of gaining the attention of Ryan ? I do agree that a sufficiently complex and rapidly expiring initial key embedded within an URL should be enough, but saying that the verification key wouldn't add any extra security isn't, in my opinion, completely fair. The longer the key the more secure it should be, and a second verification method (particularly one that user has to enter separately) adds another layer of safety. Technically it could also a) force the user to actually read the message, and b) prevent attacks where the user is somehow fooled into clicking an URL — though I'm not sure how common attack vector this would be. The way I see it, current implementation trades some ease of use to some extra safety, and personally I'm fine with that: password reset process should be a relatively rare occurrence, and attacks targeting such features are a common problem. (But you do make a good argument here; perhaps this should actually be a configurable setting for the module?) Again I think this depends a bit on your of view: on one hand current implementation makes sure that if one just gains access to a reset link they won't be able to change the password (particularly if you ask them to confirm something other than the email field), but on the other hand some experts recommend that this step should occur before sending the reset message (exactly for the same reason — security). Seems like another potential module setting to me, perhaps even so that both options (confirmation before and confirmation after) would be available. Just a quick note on this one: you don't actually have to force the users to go through the password reset procedure. In a case like this it'd be relatively simple to set up a custom process to handle the initial password reset — create and send the links to your users and process them through your own code. I've done that a few times during large scale migrations, and it's not that hard to do — though in most cases I would still recommend going through the password reset feature. Personally I don't think that the process is that hard on users. Just an idea — again I get that you're hoping to change things in general, but if you need to get this done on a timely manner, it would probably be best not to wait for a core level change. Especially since it isn't necessarily a complete no-brainer how this feature should work ?

After reading and re-reading the posts here a few times, I must admit that I'm lost. What is the problem you're running into? ? I realize that this is an old topic, but... in what HTML markup exactly, and how (and where) are you trying to add that script tag? ? If you're editing a template file, you can just add in the script tag — just like any code. Or was your issue that the script itself is not working? If it's the latter case, please share the markup and the script so we can better figure out what's going on.

This is fixed: in the latest dev version wire/config.php points to the HTTPS URL of the modules directory, and the modules directory also again accepts HTTP connections (which should guarantee backwards compatibility).

Was actually going to suggest that perhaps the modal window could have both options, but this would be much better ?

Hey @montero4! Just to confirm: are you using the Blog module (https://modules.processwire.com/modules/process-blog/), or perhaps something else?

Depends a lot on the use case: if you already know the title of the page you're going to pick (and only have a single item named like that), autocomplete is nice. Otherwise it can be pretty useless (as a selection mechanism): in some cases I've actually had to open a separate tab to browse to the page in the page tree just to find a name I can then type in an autocomplete field ?

Definitely an interesting topic! We've developed a few PWA's for our clients recently, and I'd say that they've been very well received — but, to be fair, they've been a) services for existing members and b) basically apps that wouldn't work (well) as regular websites, so that option was out of the question. When it comes to native vs. PWA, in our case PWA seems like the obvious choice: easy to use and efficient to maintain, upgrades are effortless, and obviously the web platform is "our thing" (more than native anyway) ? Some "random" websites (news sites, blogs, etc.) are now offering the option to install, but to me that feels a bit weird: unless it's a service I'm going to use regularly and there's a clear benefit for me in installing it, I don't really see the point. In fact it can also be a little intimidating: why do I need to install this service to use it? Again I think it boils down to the question of "would it work as a regular website": if the answer is "yes", then perhaps it should just be that ?‍♂️ (Sorry to hijack the thread, by the way!)

Opened an issue for this here: https://github.com/processwire/processwire-issues/issues/1083. It's great that http to https redirects are finally in place (assuming that this was intentional), but it appears that it's going to be an issue for the core.

Thanks @Mikie! I'll definitely look into the table part. There's no built-in way to get the entire index at the moment, but it might make sense to have one -- though what you're doing sounds like a perfectly good way to solve this for the time being. Anyway, I'll look into this as well. Just for the record, the renderResultsJSON method was added primarily to solve client side search needs (but I'm guessing that's not exactly what you're after) ?

Hey Pete, Thanks for looking into this! Note that this (probably) same issue is also discussed in the issues repository (https://github.com/processwire/processwire-issues/issues/1058). That issue lists some related threads here on the forums ?

This is related to the Wireframe::page() static utility method (https://wireframe-framework.com/docs/static-utility-methods/) but not specifically covered in the docs, I think. This is also one of the things I struggled trying to explain briefly in the changelog ? The general idea is that since Wireframe works through the Alternate Template Filename setting of templates, in earlier versions you couldn't do things like $pages->get(1234)->setLayout(null)->render() and expect the output to come from a Wireframe view UNLESS the Alternate Template Filename for the template this page uses had the alt filename pointing to a Wireframe bootstrap file (i.e. /site/templates/wireframe.php). After this update the syntax mentioned above will — in most cases at least — work right out of the box. And even in cases where it won't work (such as when you're fetching data from ProcessWire via a command-line script), Wireframe::page(1234)->setLayout(null)->render() will almost certainly work. Typical use case for me are pages that are not supposed to be directly accessible, like a contact page that lives under a shared "bucket" (e.g. /data/contacts/lastname-firstname/) and is only ever made visible when rendered as part of another page's markup. If I only need to output a few fields from the page I can do that directly in the view file for the containing page, but if I need to reuse this data all over the site, I prefer to define a view file for the contact (e.g. /site/templates/views/contact/embed.php) and render it using that: <!-- some page that lists contacts --> <?php foreach ($page->contacts as $contact): ?> <?= $contact->setLayout(null)->setView('embed')->render() ?> <?php endforeach; ?> Hope this makes more sense ?

Heya! Just released Wireframe 0.9.0. Here's the changelog for this version: ### Added - New EventListenerTrait. Currently used by Components only. Adds support for listening to and emitting events. - Support for Renderer modules for adding templating engine support for view files, component view files, etc. - New Page methods Page::viewTemplate(), Page::getViewTemplate(), and Page::setViewTemplate(). - New method Component::getData() for manually defining the data passed to the component view. ### Changed - Controller::init() and Controller::ready() are now hookable methods. - Component::setView() and Component::getView() are now final methods, preventing accidental overrides. - Layout file is no longer necessary; if it's missing, the page can be rendered using just a view file. The component system is a bit more mature now, and there are a couple of new features: Component::on('event-name', callable $callback) can be used to listen to events emitted by a Component instance, and in a Component class events can be emitted with $this->emit('event-name', array $args). This is mostly just syntactic sugar on top of the hook system, but it seemed fun and potentially useful, so... ? The Component base class extends WireData, so by default what gets sent to the component view when a component is rendered is the internal $data array. Since 0.9.0 it's possible to alter this behaviour by implementing getData() method which returns the data that the component should expose to its view. Another "big" update is support for renderers. These are add-on modules that add support for different rendering / templating engines to Wireframe, and the first example is the Wireframe Renderer Twig module. I haven't really used a templating engine in a while so it's possible that I've missed something important, but in my limited tests the Twig engine seemed to work quite well right out of the box. I'll likely add a separate module for Latte at some point, just to make sure that the logic works for other engines as well ? By the way, it looks like I forgot to post here about Wireframe 0.8.0. It was released last month, and here's the related changelog entry: ### Added - Support for Components, along with a new static factory method Wireframe::component($component_name, $args). - Support for rendering pages that have not been "routed" to Wireframe using the altFilename template setting. - New static getter/factory/utility method Wireframe::page($source, $args). - New static utility method Wireframe::isInitialized(). ### Changed - Wireframe::$initialized is now a static property. This was a necessary change so that Wireframe::isInitialized() could be implemented effectively. On a related note I'm considering tagging the next release as 1.0.0. We've been using Wireframe on production sites for a while now, and I can't recall any truly breaking changes so far, so I think it's already quite stable ?

That's correct. It's a bit of a nuisance, admittedly, but I don't consider it a huge issue. It's a whole different deal when we're talking about other bundled classes – in the case of Wireframe, for an example, I already have View, Component, Controller, and Config, which would be very likely to cause issues if they weren't namespaced. In fact most of my own recent modules come with a Config class... ? Honestly: I would probably leave the module name as-is for the time being, but at some point in the (perhaps near) future add a custom namespace and declare 3.0.150 as a dependency. But obviously it's your call – if you want to do your best to avoid any issues right now, renaming would be a safe bet. It'll force existing users to likely reinstall, but that's unlikely to become a massive issue. 50-50 ?

That's true, and one reason why historically all module files have been declared in the ProcessWire namespace – another being that most modules don't need that many classes to begin with. In cases where a module makes use of non-module classes, I would definitely recommend defining a separate (i.e. something other than ProcessWire) namespace for those ? (This part is also well supported, so no need to wait for 3.0.150.) Just for an example, here's how I've handled this in Wireframe: Here's the classLoader setup: https://github.com/wireframe-framework/Wireframe/blob/6530b96/Wireframe.module.php#L297:L317 In this case Wireframe "core classes" live in the /lib/ directory: https://github.com/wireframe-framework/Wireframe/tree/master/lib While namespaces are often enough to tackle the issue of clashing traits and classes, it's also a common recommendation for traits and interfaces to be named differently: SomeNameTrait, SomeNameInterface, etc. PSR also recommends (or requires, really) this approach.