Leaderboard
Popular Content
Showing content with the highest reputation on 08/20/2020 in all areas
-
There is this module made by @bernhard:3 points
-
Thx again @teppo ? I hope you don't mind if I throw some suggestions here while I'm exploring wireframe ? One more suggestion for the docs: I think this docs page is a little bloated. Don't get me wrong, I really appreciate the huge amount of informations, but for me it would be easier to start from the minimum working setup and then expand from that. See the docs here: https://wireframe-framework.com/docs/view/components/ It seems to be quite complicated to create components, while all you actually have to do is this: /components/Card.php <?php namespace Wireframe\Component; class Card extends \Wireframe\Component { } /components/Card/default.php I am a Card component! /layouts/default.php echo Wireframe::component("Card"); Once I got that via try&error your "advanced" example was great ? PS: Maybe add a note that /components/Card/default.php could be replaced by adding a render method in /components/Card.php ?2 points
-
Hello @Ralph, 1. The developer tools (Inspect Element in FF) shows the font size set in your main.css file on line 1760 for screens wider than 768px. You will need to search for other media queries to set the font size for other screen sizes. See here for more information. 2. The developer tools shows your link definition in main.css on line 1107. See this reference for more information about styling links. 3. You will need to edit your "<div id="header-wrapper">" to include whatever logo image you wish. You will most like likely need to add css styles to make the logo appear as you wish. 4. The text "', 'auto'); ; ga('send', 'pageview');" appears to a remnant from a previous copy/paste. The developer tools shows this text immediately after the <body> tag. You can edit the template where the body tag is located and delete this extraneous text. 5. A google search for changing your site's favicon will give you sufficient results to accomplish this task. Hope this helps.2 points
-
No worries ? The error is pretty clear: there's no $page->view, but in the context of the wireframe bootstrap file you can access $this->view (or wire('view') / $this->wire('view'), that's the same thing). API variable $view — behind the scenes it's an instance of Wireframe\View, which in turn extends TemplateFile — is basically how you access the View layer (layouts, view files, etc.) from a) the bootstrap file, or b) controller classes. What I often do is something along these lines: if ($page->is('template=some|template|or|another')) { $this->view->setLayout('teaser'); } Although if it's just about this one template, then I typically create a controller class that sets this. This keeps things neatly in context — just like you mentioned about custom Page classes ? <?php namespaces Wireframe\Controller; class TeaserController extends \Wireframe\Controller { public function render() { $this->view->setLayout('teaser'); } } Note: personally I don't mind having a Controller that is as simple as the one above ?♂️ Originally Controllers were built to solve more or less the same things that can now often be dealt with custom Page classes, though personally I still prefer the Controller approach. That being said, your idea about handling init/ready hooks is interesting. In a typical project I don't have that many hooks, so I usually just stash them in init.php/ready.php, or perhaps create a module for a specific (bigger) feature (particularly if they apply to more than one template), but this might be worth exploring further in some future project. (Also a little off-topic, but we've bundled a bunch of "very often needed" hooks into a shared module that we install on all our new projects, and I personally try to keep hooks to minimum — they are powerful, but the more you have the more complex the project gets. Basically the same thing you said about it getting chaotic; I try to fend that chaos off by saying "no" to new features/hooks/etc. as often as possible ?) This does sound like a good use case for multiple layouts. Again I try to keep my layouts pretty "dumb": in my experience too many bells and whistles and flags and toggles result in unmaintainable code. Everything that is specific to a single template generally belongs to view files instead of layouts; sometimes when I have a single page with a completely custom look — say, a campaign one-pager within a bigger site — I disable layout completely for that page, and put everything in the view (as long as it doesn't get massively complex in itself... in which case components and partials can come in handy) ? I feel your pain ? This was the main motivation for creating the original pw-mvc "framework". Imagine that you've got a team of developers all working on their own projects and inventing their own ways to structure things and solve the same issues. And not just some one-off projects that get handed to a client, but ones that the team has to maintain for many, many years to come. Proper level of standardization == happiness.1 point
-
Thx, here is my working version ? class TeaserPage extends Page { public function init() { $this->addHookBefore("Wireframe::render", function($event) { if(!$event->page instanceof self) return; $event->view->setLayout('teaser'); }); } } Hm. That confuses me a little. What I'm doing is basically just creating a "coming soon" page. So I'd really just need a template for that. Let's call it "teasertpl". Now to keep things managable in bigger projects I learned that custom pageClasses are a HUGE help. There are always little tweaks we have to do, right? And we all love PW and hooks, right? But in my experience this can quickly get extremely chaotic. My first approach was to split ready.php into several sections and do this: // ready.php include('foo.php'); // all foo related things include('bar.php'); // all bar related things The problem with that approach? One day you need to add a hook on init() instead of ready() and all the trouble begins... Using pageClasses on the other hand is really clean (and also easy): class MyPage extends Page { public function init() { // add init hook } public function ready() { // add ready hook } } I love that approach, because you can even use class constants like MyPage::foofield and you can quickly open that file in VSCode via CTRL+P, type "MyPage", boom --> all there! Want to hook the page edit screen for MyPage pages? Add a buildForm hook on that pageClass! Want a custom random pagename? Add a saveReady hook. Want to auto-publish MyPage pages? One additional line in the saveready hook. ? And you get all that by just setting the pageClass in RockMigrations: $rm->migrate([ 'templates' => [ 'my-page' => ['pageClass' => 'MyPage'], ], ]); Ok sorry, I got a little off-topic, but that was the context ? Back to your statement... Ok, so I have this single "teaser" template and want to render "layouts/teaser.php". I dont have (want/need) a Controller, because that's really just a single page with a logo. Where would you place the setLayout() ? In wireframe.php like this? $page->view->setLayout('teaser'); This throws an error Call to a member function setLayout() on null Maybe I'm missing something again? I must admit that it does not feel like I really got the concept yet ? Or would I use a view for something like this that uses the default layout? My idea was to have one default layout for all other templates of this website and one for this "coming soon" page. The 404 page would also be a candidate for a custom layout where I don't need any menus, headers, footers etc.; Or would you create ONE layout for all that and then show/hide sections based on the page (template) that is currently viewed? Thx a lot for you help! I'm really looking forward to implementing a streamlined workflow for my projects. Yesterday I had to work on an old project and I got lots of "where did I place this, where did I define that, what the ** did I do here?" moments ?1 point
-
Keep 'em coming! ? I'm currently digging into a few Wireframe core things based on your earlier comments. It's really helpful to hear how others are using / getting started with Wireframe, and what sort of troubles they may be running into while doing it. Your comments have already been quite helpful, and I may be able to simplify / streamline some things in the next release. Docs definitely need some love. I'm still learning how to write useful documentation — one that doesn't omit anything that might prove out to be valuable later on, yet still feels "light enough" to get you up and running quickly. Every time I dive into a new library or language or something like that I seem to run into the very same "just give me the damn facts so that I can try it!" thing. I mean... yes, I get that this is all important and all, but do I really need to know all that just to give it a quick try... ?1 point
-
This makes no sense... if($today == $start AND $today == $start) This is redundant, it is simply 2x the same check Use this: if($today == $start)1 point
-
@bernhard, here's a quick test based on your hook approach: $wire->addHookBefore('Wireframe::render', function(HookEvent $event) { $event->view->setLayout('default'); }); At least from init.php this works as expected. In my own projects I would rather set this in Controller or wireframe.php, though, since this is a little unexpected (and impossible to override without modifying the custom Page class itself, though not sure if that's a problem for your use case.)1 point
-
@bernhard, sorry by the way, looks like your edits were not visible yet when I wrote the answer. Quick answers: Right. To be honest this falls to the area of which I have no experience whatsoever, but apparently ProcessWire prevents setting any values at this point ? When Wireframe::render() is called, Page::render() has already been called earlier, so this has no effect on current render page request. When you're in the wireframe bootstrap file or Controller file and want to change the layout used for current request, you need to go through the $view object: $this->view->setLayout('teaser'); (In the case of your hook, I believe $event->view->setLayout() should work. Though not sure I've actually tried to do this.) Page object methods are mostly intended for cases where you want to render some other page, i.e. something like this: <?php foreach ($page->children as $child): ?> <?= $child->setLayout(null)->setView('card')->render() ?> <?php endforeach; ?> This is likely something I need to clarify in the docs. Same issue here.1 point
-
You need to check whether there's something in the end date field. Then, if you're going to use the value in a function, you need to give it a suitable value if there's nothing in the field. For example: if ($single->End_date) { $end = date('d. m. Y', $single->getUnformatted('End_date')); } else { $end = date('d. m. Y', 0); // This would be 01.01.1970, but you might want something in the future } I also note that you are getting the unformatted dates from the fields and then formatting them again with the date() function. As you are just comparing values (at least in the code you have posted), you could simply use the values from the fields, or the unformatted value if it's easier to work with UNIX times. And you have $today == $start twice in your first 'if' condition!1 point
-
thank you @Robin S kudos goes to @bernhard really helpful.1 point
-
Spoke too soon — there was actually a reason for this: "resources" is not a "path" for Wireframe, just an "URL". This may sound weird, but the point is that while Wireframe needs to keep track of code related paths (so that it knows where views, layouts, controllers, etc. are located), it doesn't really need to know where your static resources (CSS, JS, images, fonts, etc.) are. URLs are added as helpers, so that you can refer from code to your resources directory with <?= $config->urls->resources ?> instead of writing a long directory name over and over again. Anyway, upcoming 0.12.0 release will provide an option to create directories for specified URLs as well. This obviously only works if they are relative paths (they don't have to be — in some cases I've pointed resources directly to a CDN service, etc.)1 point
-
@rookie I wish you hadn't said that. I've been using Windows since 1987. Probably need a blood transfusion to get it out of my system.1 point
-
@MoritzLost This is a very elegant approach indeed! I’ve already built it in and it works flawlessly. I also appreciate it’s temporary nature that allows me to keep everything like it is, and just get rid of the helper field and the hook as soon as the select issue might be fixed someday. So another big thanks for that! (Btw: time comsumption was manageable, 5 minutes or so …)1 point
-
@rick @horst @pwired @zoeck @dragan @clsource Thanks for you replies. I'll take a look at your suggestions shortly.1 point
-
Seems like an oversight from my part, good catch ? There shouldn't be any backwards compatibility breaks. At least not intentional ones... ?1 point
-
@rash One possible workaround to this problem is to use a hidden text field that acts sort of like an index to your Selectable Option fields. I've used this approach before to make the selected options searchable (since their titles can't be searched, as you noticed). This would also work for your sorting problem: Create a text field (let's call it direction_index) and add it to the templates where you have your direction field. Use the Pages::saved hook to automatically write the current title (or value) of the direction field to the direction_index field. Now you can use the hidden direction_index field for sorting and searching. Since it's a regular text field, it has it's own database table and has full support for all ProcessWire selectors. Though of course that's probably more work than just migrating the the select field to a page reference ?1 point
-
Hi @teppo finally did some more testing, this was my experience: Installed the module, smooth Created default site structure, smooth Set alternate template file for home.php, smooth Empty frontpage --> what now? https://wireframe-framework.com/getting-started/ stops at this step! Ok, it does not stop, but it leads to https://wireframe-framework.com/docs/ -> this is all great informations, but it does not help getting a quick grasp of how to output something on the frontpage... Please don't get me wrong. Your docs are great, but for me (and maybe others) I think some small improvements can make the experience even greater. Maybe something like this (based on my efforts from today): --- Here's a rough, unpolished tutorial for getting started with wireframe and getting the concepts on the road: Follow https://wireframe-framework.com/getting-started/ until the end Set alternate template file for home.php Create /layouts/default.php and visit the homepage --> you'll see the default layout <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Default Layout</title> </head> <body> <h1>Wireframe default layout</h1> </body> </html> Congratulations, that's your first layout! Now add some php variables: <p>My name is: <?= $view->myName ?></p> Of course, why should the layout know the name? We need a controller that tells the view what value is in the myName property! Create /controllers/HomeController.php <?php namespace Wireframe\Controller; class HomeController extends \Wireframe\Controller { public function myName() { return 'Bernhard'; } } What about my favourite CMS? <p>My favourite CMS is: <?= $view->cms ?></p> <?php namespace Wireframe\Controller; class HomeController extends \Wireframe\Controller { public function myName() { return 'Bernhard'; } public function cms() { return "ProcessWire"; } } Ok, I got it - and that's great stuff! ? Now set the alternate template for "basic-page" to "wireframe". Visit a "basic-page" site (eg the 404 page) and you'll see the default layout: The variables are empty, because the HomeController is only loaded on the home template and that's for some good reasons. Read about views in the docs: https://wireframe-framework.com/docs/view/views/ Partials to the rescue ? We modify the default layout: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Default Layout</title> </head> <body> <h1>Wireframe default layout</h1> <?php include $partials->name ?> <?php include $partials->cms ?> </body> </html> And the partials: // partials/name.php <p>My name is <strong>Bernhard</strong>.</p> // partials/cms.php <p>My favourite CMS is <strong>ProcessWire</strong>.</p> Let's make that dynamic! // name.php <p>My name is <strong><?= $name ?></strong>.</p> // cms.php <p>My favourite CMS is <strong><?= $cms ?></strong>.</p> // default.php <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Default Layout</title> </head> <body> <h1>Wireframe default layout</h1> <h2>Viewing template "<?= $page->template ?>"</h2> <?= $partials->name(['name' => 'Bernhard']) ?> <?= $partials->cms(['cms' => 'ProcessWire']) ?> </body> </html> Note that the partials are now echoed instead of included and we added the line that outputs the template of the viewed page! Note though, that partials are really just for simple chunks of code. At best even static ones. As soon as things get more dynamic, start using components instead of partials: https://wireframe-framework.com/docs/view/components/ What do you think?1 point
-
This doesn't look too different to how everything can be defined in RockMigrations... /** * Migrate issues related things * @return void */ public function migrate() { $this->log('Migrate Issues'); $this->rm()->migrate([ 'fields' => [ self::field_sections => [ 'type' => 'FieldtypeRockMatrix', 'icon' => 'files-o', 'tags' => self::tags, ], ], 'templates' => [ self::tpl_issues => [ 'childTemplates' => [ self::tpl_issue, ], 'tags' => self::tags, 'icon' => 'stack-overflow', 'parentTemplates' => ['home'], 'childNameFormat' => "title", 'fields' => [ 'title', ], 'noSettings' => 1, 'useRoles' => true, 'roles' => [self::role_admin], 'addRoles' => [self::role_admin], 'pageClass' => '\RockMag\Issues', ], self::tpl_issue => [ // no children allowed // children will only be added via rockmatrix field 'noChildren' => 1, 'parentTemplates' => [self::tpl_issues], 'tags' => self::tags, 'fields' => [ 'title', self::field_sections, self::field_pdf, ], 'pageClass' => '\RockMag\Issue', 'noSettings' => 1, 'noLang' => 1, // single language 'icon' => 'book', 'useRoles' => true, 'roles' => [self::role_admin], 'createRoles' => [self::role_admin], // may create pages 'editRoles' => [self::role_admin], // may edit pages 'addRoles' => [self::role_admin], // may add children (MagPage) ], ], ]); // create issues page if(!$this->getIssuesPage()->id) { $this->rm()->createPage("RockMag", null, self::tpl_issues, 1, ['hidden', 'locked']); } } But you get all your defined fields and templates with a single ->migrate() call ?1 point
-
Which method exactly? It would help us reproduce/test. I don't quite get this. Aren't all hooks called from a class context? Perhaps you meant to say frontend versus backend? What errors? Where are you calling the hook? Some code to look at would help :-).1 point
-
Hey I updated the spec. Now it's more like Pseudocode than a whole language in itself. The idea is just to communicate better and make plans before building or thinkering with the fields. Example for this small project that I'm building https://github.com/NinjasCL/chileanbirds-api @document { @wire { @templates { home: template().options({@once, @strong, @root}), notfound: template().options({@once, @childless}).description("Used in 404 errors"), birds: template().options({@strong}).family({ parents: ["home"], children: ["birds-item"] }), birds-item: template().options({@childless}).family({ parents: ["birds"] }) }, @fields { title: text().options({@i18n, @global}), body: textarea().options({@i18n}), uid: text(), href: url(), file: files().max(1), migration: checkbox(), dimorfism: checkbox(), size: text(), order: text(), species: text(), image: images().max(1).mediatypes([@jpg, @png, @svg]), images: images().mediatypes([@jpg, @png, @svg]), value: text().options({@i18n}), habitat: textarea() .description("Stores the habitat property") .options({@i18n}), didyouknow: textarea() .description("Stores the did you know property") .options({@i18n}), iucn: pagetable() .max(1) .fields({ body: body().description("Stores the iucn description"), value: value().description("Stores the iucn value") }), audio: pagetable() .max(1) .fields({ file, title.label("Author") }), map: pagetable() .max(1) .fields({ image, value }), }, @pages { + "Home" (template:home) @many -> { + "Birds" (template:birds) @many -> { + "Bird 1" (template:birds-item, fields: { title: title().label("Names"), body: body().label("Description").description("Stores the bird description"), images, habitat, didyouknow, iucn, audio, map, species, migration, dimorfism }) } // /birds } // /home } // /pages } // /wire } // /document1 point
-
I combined dotnetic's suggestion with elabx's hook: <?php $wire->addHookAfter("InputfieldCheckbox::render",function($event){ $field = $event->object; $output = $event->return; if($field->name == "privacy_policy_accepted"){ $output = str_replace($field->entityEncode($field->checkboxLabel), $field->checkboxLabel, $output); } $event->return = $output; }); ?> Basically undoes the encoding1 point
-
Couple of other notes: Quote: "All $config->ajax does is checking for the request header "X-Requested-With", which is not even a real standard. It is included in jquery's ajax tools by default, but most modern ajax libraries don't do that anymore. There's nothing more to it." Quotes: "Make sure your post url ends with a slash." "Otherwise the .htaccess (or php not sure) will do a redirect, which essentially strips all the headers sent with the request." Also, use $this->halt() instead of exit() or die(), read more on it here. (such as: note that return $this->halt(); must be called from directly within the template file, outside of any function or class scope) Use Tracy Debugger to ease the pain ? https://processwire.com/talk/topic/12208-tracy-debugger/page/31/?tab=comments#comment-1355581 point
-
u.can do on anyee page template like .this if($config->ajax){ // u do.ajax $data=['status'=>'ok', 'massage'=>'hi whirld']; header('content-type: application/json'); echo json_encode($data); exit; }else{ // u.do html }1 point
-
Hello @Greg Lumley, From what I understand (and I am not an expert as are the others here) there are two ways to process an ajax request: 1, create a page with corresponding template and php file (preferred/common method), or 2, create a php file outside of the site folder. Which method you choose has different requirements. The common method is to create a php file (in templates folder) named ajax_contact.php to handle the ajax request, assign that file to a template named ajax_contact, and create a page for that template named ajax_contact. Your ajax url them becomes the name of that page, ie, /ajax_contact/. Note that the page should be published or PW will ignore it during your request. Method two I think requires that you initially load PW (index.php) in your ajax_contact.php file since you are outside the document root referenced during the processwire installation. In this case, your ajax url would be the actual php file name; ajax_contact.php. I don't know which method is preferred, but I use the first method simply because that is the way processwire handles normal page request. I think you have both methods implemented in your script at the same time when it should be one or the other. I hope this helps. I'm sure someone more knowledgeable will provide you with a better answer, and hopefully correct me as well.1 point
-
Hey, thanks for your compliment! ?1 point
-
This is interesting! Full disclosure: on a few occasions I've considered adding a separate model layer to Wireframe, but I've never found a proper reason, i.e. I couldn't think of anything I can't do without it — or even anything it would make notably easier or more effective or more organised — and I'm trying not to add features just because they'd be fun to implement. That being said, I'm always on the lookout for interesting new stuff to add, as long as it adds real value to the framework ? I think when you say "model" you probably mean something a little different than what it means to me personally. In my mind models are tied to data structure, have very little to do with routing, and so on. In fact from what I could gather from your examples it looks like such models would indeed be a lot like custom post types in WordPress in that they'd be located in a single "bucket" and define a per-model route that's separate from the regular page tree structure. If that's the case, wouldn't one variation of that just require creating a parent page on the root level and then subpages below that? Or, for more complex routes, you could make the parent page render its subpages based on URL segments. All the building blocks are already there, though obviously this one needs quite a bit more work — you have to define the routes programmatically, for one. Any chance you could flesh your idea out a little more: What would you use this sort of thing for? How would you envision defining the routes? How would this be different from existing options, such as placing a parent page under root and then subpages using specific template under that, or using URL segments — i.e. would the biggest benefit be some abstract method of defining routes? WordPress templates are a bit different in that they're about representing data, while ProcessWire templates are obviously all about structuring data. Wireframe, for an example, has concepts called "layout" and "view", which are largely in line with WordPress' templates: each template can have multiple views, and each of those views can then be used to render pages in different ways, and/or for different purposes (JSON, RSS, HTML, etc.) Long story short: I'm intrigued, but not entirely sure of all aspects that this concept would bring to the table. Definitely interested in hearing more though!1 point
-
Hello Robin, Is not meant to be a programming language. Is more like a prototyping language. maybe in the future tools can be written to generate files or similar. The objective is to create a document that can show pages, templates and fields relationships in a eagle view fashion. Before you start creating the templates in PW you can prototype in this document like a scratch pad to clear ideas and see different options before investing time in programming.1 point
-
Hey @Tom. JAMstack itself is just a marketing term created by Netlify’s CEO to onboard people onto their hosting platform and CMS. Netlify CMS is not really a CMS, it is an admin panel that integrates with static site generators like Hugo and Jekyll. The use case for static site generators is usually very simple sites with basic structured content like blogs and portfolios. See examples here https://jamstack.org/examples/ The JAMstack methodology also encourages using cloud CMS platforms like Contentful, however there are benefits and drawbacks to this I won't go into. To set up something like what you are asking about (but way more fun and flexible) with Processwire, imagine you have a domain http://api.website.com pointed to a Processwire instance with a homepage template like this: <?php namespace ProcessWire; header('HTTP/1.1 200'); header('Content-Type: application/json,charset=utf-8'); header("access-control-allow-origin: *"); $data = []; $projects = $pages->find("template=project"); foreach ($projects as $p) { $data[] = [ $title -> $p->title; $content -> $p->sometextareafield; ] } echo json_encode($data); and the main domain http://website.com is just a static hosted at netlify and your index.html contains the below: <body> <div id="projects"></div> <script type="text/javascript"> $(document).ready(function() { $.ajax({url: "http://api.website.com"}).done(function(data) { var $projects = $('#projects'); data.forEach(function(project) { var html = "<div class='project'>" + "<h2>" + project.title + "</h2>" + project.content + "</div>"; $projects.append(html); }); }); }); </script> </body> ... then you have the beginnings of a single page javascript app. Of course building an entire site like this and incorporating routing and state management etc would become tiresome very quickly in jQuery, which is why javascript frameworks like React and Vue exist. Regarding build tools and task runners like Webpack and Gulp, they exist to do what they say, i.e. bundle up static assets or run tasks. Before getting to that tho, it is important to understand the way people use node and npm for front end dev. See this article maybe: https://www.impressivewebs.com/npm-for-beginners-a-guide-for-front-end-developers/ I personally hate Webpack, I use npm scripts and the CLIs of my preferred libraries to do everything. I can post an example if you like, but these blog posts sum it up: https://deliciousbrains.com/npm-build-script/ https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/1 point
-
The documentation could be clearer in this regard, and I'm probably oversimplifying here, but there two basic categories of selector usage in PW. 1. Methods that use the PageFinder class - common ones would be $pages->find($selector), $pages->get($selector), $page->children($selector). Also find/get selectors for $users. Those are the ones that spring to mind, although there might be a few more. These methods do a database query behind the scenes. 2. All other methods that accept a selector, for example $some_pagearray->find(), which is actually WireArray::find(). These methods do not query the database but work on items that are in memory. There are differences in the ways that these two categories of selector usage are implemented. Some things work in a PageFinder selector that don't work in an in-memory selector. The documentation for Selectors seems to be assuming the reader is interested in PageFinder selectors because there are code examples there that won't work with in-memory selectors. There isn't any definitive list of the differences (that I know of), but here are some things that I have found do not work with in-memory selectors (but do work with PageFinder selectors): 1. Datetime values as strings, e.g. "some_datetime_field>today" 2. Page statuses as strings, e.g. "status!=hidden" 3. OR groups In a perfect world selectors would work the same everywhere and you wouldn't have to think about it. There's an open request for this here.1 point
