Leaderboard

Thank you @Sérgio this was exactly what I was looking for! I really appreciate the prompt and helpful response! I'm just starting with processwire but it seems so lightweight and fast that I think I'll be sticking around for awhile!

Welcome to the forums, @Praxea ! It seems a common .htaccess issue, please take a look on this post: https://processwire.com/docs/tutorials/troubleshooting-guide/page3

It should be mentioned that the getById() is used internal and not access or status aware. So it's like get(id) and will load the page(s) even if they're unpublished or the user has no view rights, all a $pages->find(...) does.

Your link to the topic you followed doesn't work, and I'm not sure what's in your renderPosts() function, but assuming that LostKobrakai is right and you are using $page->render() (edit: I see the render() call now), another alternative is to place this at the top of the template you render: if( empty($options['pageStack']) ) throw new Wire404Exception();

I keep running into this too. More in depth info in this post by ryan.

Rename your post.php to _post.php and instead of $post->render() use wireRenderFile("_post", ['page' => $post]). This way processwire doesn't automatically recognise that post does have a template file and therefore throws a 404 for those pages.

Because it does a db search vs a in memory match thats why it doesn't validate. It's like this ever since. There was even several threads and git issues about this.

I admit I haven't thought too much about nesting, and the wiring around the field's json data would obviously need to be completely different. InnoDB does support searching in nested structures, but PW already treats subfields on the left side of a selector in its own way and throws away anything starting at the second full stop. A different syntax would be necessary, e.g. $pages->find('jsonField=/subField/field:foo') There might be issues where search expressions need some kind of escaping (e.g. searching for literal text "/subfield"), but this would allow for wildcard queries. $pages->find('jsonField=/subField/*/name:foo') Or even searching arrays (any element or by index): $pages->find('jsonField=/subField/fields#*/name:foo'); $pages->find('jsonField=/subField/field#12/name:foo'); Here's a tiny adoption of my module to allow this search syntax. There's no back and forth conversion though, just a textarea containing the JSON. <?php class FieldtypeJsonDocument extends FieldtypeTextarea implements Module { public static function getModuleInfo() { return array( "title" => "Fieldtype Json Document", "summary" => "Fieldtype utilizing native MySQL support for searching JSON documents.", "version" => "0.0.3", ); } public function getMatchQuery($query, $table, $subfield, $operator, $value) { $database = $this->wire("database"); list($path, $value) = explode(':', $value, 2); if(empty($value) && !empty($path)) { $value = $path; $path = ""; } $path = '$' . ((empty($subfield) || $subfield == "data") ? "" : ".$subfield") . (empty($path) ? ".*" : str_replace('/', '.', preg_replace('~/?#(\d+|\*)~', "[$1]", $path))); $table = $database->escapeTable($table); $value = $database->escapeStr($value); if($operator == "=") { $query->where("JSON_SEARCH({$table}.data, 'one', '$value', NULL, '$path') IS NOT NULL"); } else if($operator == "*=" || $operator == "%=") { $query->where("JSON_SEARCH({$table}.data, 'one', '%$value%', NULL, '$path') IS NOT NULL"); } else if($operator == "^=") { $query->where("JSON_SEARCH({$table}.data, 'one', '$value%', NULL, '$path') IS NOT NULL"); } else if($operator == "$=") { $query->where("JSON_SEARCH({$table}.data, 'one', '%$value', NULL, '$path') IS NOT NULL"); } $this->log->message($query->getQuery()); return $query; } public function getDatabaseSchema(Field $field) { $engine = $this->wire('config')->dbEngine; $charset = $this->wire('config')->dbCharset; $schema = array( 'pages_id' => 'int UNSIGNED NOT NULL', 'data' => "JSON", // each Fieldtype should override this in particular 'keys' => array( 'primary' => 'PRIMARY KEY (`pages_id`)', ), // additional data 'xtra' => array( // any optional statements that should follow after the closing paren (i.e. engine, default charset, etc) 'append' => "ENGINE=$engine DEFAULT CHARSET=$charset", // true (default) if this schema provides all storage for this fieldtype. // false if other storage is involved with this fieldtype, beyond this schema (like repeaters, PageTable, etc.) 'all' => true, ) ); return $schema; } public function getInputfield(Page $page, Field $field) { $inputField = $this->modules->get('InputfieldTextarea'); return $inputField; } public function install() { if($this->config->dbEngine != "InnoDB") { throw new WireException($this->_("InnoDB database engine needs to be used for native JSON support")); } $dbver = $this->database->getAttribute(PDO::ATTR_SERVER_VERSION); if(version_compare($dbver, '5.7.8', '<')) { throw new WireException(sprintf($this->_("MySQL Server version needs to be at least 5.7.8 for fully working JSON support, installed version is %s"), $dbver)); } } } There would probably be a bit of recursive shuffling necessary in sleep-/wakeup-/sanitizeValue to build nested structures based on WireData/WireArray so accessing subfields and filtering PageArrays is possible, but that should be doable too. How difficult the backend input + display parts get depends solely on your exact requirements.

same here. but i went the risky way and it was released just in time i still think that this should be a core feature... you could hide the button easily with some JS or CSS, for example using admin custom files or a little hook. do this once and you will be able to do many other little tweaks in the admin without asking for support

@LostKobrakai: No, I don’t use $page-> viewable – there must be another issue. @Robin S & diogo: I filled in the line you suggested and now everything works the way I was searching for. (Okay, I don’t have a clue what the line actually does, but as a newbie there must be some learning potential left.) So big thanks to all of you for your kind answers, you were enormously helpful. Ralf

You could use the PageAutoComplete input for page fields so the page would not load all the people at once.

i usually do this in the head - you will need to echo these directly on the php output, because your .js files won't be processed server-side. <script> var site = { "urls": { "templates": <?=$config->urls->templates?>, "root": <?=$config->urls->root?> } }</script> then you can do site.urls.templates for your var inside your main.js

You can also use page IDs in a $pages->find() selector... $ctas = "1234|1235|1236"; foreach($pages->find("id=$ctas") as $p): ...but $pages->getById() has the advantage that the resulting PageArray preserves the order of IDs as you supplied them.

What I meant was comparing regular web server logs. Assuming you're using apache, you can enable logging for mod_rewrite and see if requests to /some/path are correctly re-written to /index.php?it=/some/path. If you can't see anything wrong there, I'm at a loss too. A good place to hook would probably be Pages::saveReady.

That looks a bit strange to me. You are saying data is an array where the first value is the string 'notices' and the second value is the WireArray $notices - is that intentional? Or do you maybe mean: $data = array('notices' => $notices);

Yeah the initial superusers id is hardcoded in the config, so you can't accidentally remove your own access rights.

Really? So, we cannot have pages titled "X-Ray" then? echo '<pre>'; print_r($sanitizer->testAll('x-ray')); echo '</pre>'; // results Array ( [name] => x-ray [names] => x-ray [varName] => x_ray [fieldName] => x_ray [templateName] => x-ray [pageName] => x-ray [pageNameTranslate] => x-ray [filename] => x-ray [path] => x-ray [pagePathName] => x-ray [email] => [emailHeader] => x-ray [text] => x-ray [textarea] => x-ray [url] => x-ray [selectorField] => x_ray [selectorValue] => x-ray [entities] => x-ray [entities1] => x-ray [unentities] => x-ray [entitiesMarkdown] => x-ray [purify] => x-ray [string] => x-ray [date] => [int] => 0 [intUnsigned] => 0 [intSigned] => 0 [float] => 0 [array] => Array ( [0] => x-ray ) [intArray] => Array ( [0] => 0 ) [bool] => 1 ) http://processwire.com/api/variables/sanitizer/

@bernhard I've used various versions of the firewall over the years (it's usually updated once a year), and while I ran into the occasional conflict a few years back, it's been solid ever since. I'm currently using it on a couple of Apache servers (Ubuntu 14.04 with the most recent version of Apache) on about 6 different PW-powered sites (both http:// and https://), and so far so good. I haven't run any specific test to measure its efficiency, but I see fewer traffic peaks from questionable sources and fewer errors in my logs. And it gives me an additional peace of mind to have this added layer of protection against bad actors. I've added this additional block as my logs showed persistent automated (and dumb) attempts to access Wordpress login or directories. # 6G:[REQUEST STRINGS] <IfModule mod_alias.c> RedirectMatch 403 (?i)(wp-admin|wp-content|wp-login) I don't think this really needs a module as it's a quick copy and paste operation, although it's true that releasing a module would raise awareness and more people would discover it. @Mike Rockett I'm certainly not a Regex expert, but if you look at the "Learn more" section, there are various articles over the years that show how some highly optimized regex rules can go a long way.

Such a pity to see that a developer chose to procrastinate for eight months developing something with PW. I mean, really? If you're building anything that's even half-interesting, you're bound to have some fun doing it or, at the very least, look forward to building it, right?

https://www.reddit.com/r/Wordpress/comments/55pe4l/processwire_vs_wordpress/ These guys need some fight PS: I posted something already: https://www.reddit.com/r/Wordpress/comments/55pe4l/processwire_vs_wordpress/d8dsole

Last week we called it a soft launch, but this week we'll say ProcessWire 3 is now released and considered our new master, version 3.0.35. This post is a changelog of sorts, where we will cover all that's new in ProcessWire 3! https://processwire.com/blog/posts/pw3-changelog/

Robin's method would work in that case. Maybe you should go with that.

Do you use $page->viewable() somewhere? It'll be false when using my method.

I think the cache wouldn't need to necessarily live outside the container, for logs I'd rather hook WireLog / Wire::trackExceptions and sending messages to a 3rd party service instead of trying to shoehorn external paths onto $config. Sessions could simply be SessionHandlerDB or a redis session handler via php conf.

You have to use the role Id instead of the name.

I can confirm the workaround works. Issue logged.

To me, Option 1 seems more logical, and more organized. Page links would be more useful and intuitive in the future when you're trying to select related data, rather than finding them through a node's children. Consider: $pages->find("template=event, personreference=$person"); against: $pages->find("template=event, has_parent=$person"); I think the first one would be easier to understand, and would execute faster.

I figured out what it was, it was an embedded Constant Contact sign up form that had the words: Please enter your email address in name@email.com format this is actually inside a <script> tag. In any case your suggestion about the execution method would be really great, because when you know you only need the script to operate on 1 page, and leave the rest of the site untouched, it's really the safest way on a large project where you don't want things to break...

Yep, but I dont actually use utf-8 addresses, I just needed to redirect them to 404, because without this option, it wasn't working.

I can confirm jüergen's observation (PW 3.0.35, but had it already in earlier versions). No second page table field present.

Great - I have pushed that version to Github.

I'd imagine it should work like this: $this->add(array( // Text field: greeting array( 'name' => 'greeting', // name of field 'type' => 'text', // type of field (any Inputfield module name) 'label' => $this->_('Hello Greeting'), // field label 'description' => $this->_('What would you like to say to people using this module?'), 'required' => true, 'value' => $this->_('A very happy hello world to you.'), // default value ), // Radio buttons: greetingType array( 'name' => 'fs', 'type' => 'fieldset', 'children' => array( array( 'name' => 'greeting', // name of field 'type' => 'text', // type of field (any Inputfield module name) 'label' => $this->_('Hello Greeting'), // field label 'description' => $this->_('What would you like to say to people using this module?'), 'required' => true, 'value' => $this->_('A very happy hello world to you.'), // default value ), ) ) ));

Thanks for the answers @kongondo. Both Media Manager and Visual Page Selector look like useful and clever modules, although the cost/features ratio favours MM. I think what would be really fantastic is something in between the feature set of MM and VPS, and this could perhaps be accomplished by borrowing some of the features developed for MM into VPS. To explain, something I think PW is missing is custom fields for images (and I'm not alone: this GitHub request from today has 4 upvotes in 2 hours). There are loads of use cases for this, but one example: you are using images in your site that have a Creative Commons Attribution license. To fulfill the terms of the license each image needs the following fields attached: Author (text), Source link (URL), License (Page select), License link (URL, although in fact you'd probably store the URL for each license in the License page field). The ImageExtra module only supports textarea custom fields so it's not the right solution. What would work is a page-per-image approach with the custom fields for the image stored in the image's page. VPS is a big step towards making this a workable solution, but to use this as a replacement for a standard image field some extra features are needed beyond what is currently offered... 1. There needs to be an easy way to edit the image's custom fields from the Page inputfield. A modal link to Page Edit is all that's needed to begin with - this is something that's possible with existing inputfields such as AsmSelect. Somewhere down the line this could maybe be enhanced with AJAX loading of the custom fields into the list view of VPS, as per repeaters (just dreaming here). 2. There needs to be an easy way to add an image (page) from the inputfield. This is possible with most existing Page inputfields if the template and parent for allowed pages is defined. Basic support for this would be to open the Add Page form in a modal (the Page Field Edit Links module does something like this). But to be a closer match to existing image field functionality it would be nice to be able to upload multiple images at once. This feature is in MM - could it be added to VPS? (when template and parent are defined for the field). 3. There needs to be an easy way to embed an image into CKEditor. This feature is in MM - could it be added to VPS? Really keen to hear your thoughts on this. Thanks!

I'm not sure if my module would really fit this task, as this seems a rather straight-forward use of page tables while JsonNativeField is for free-form key-value storage per page without constraints. It's also a few weeks from being complete enough to use in a real world scenario. As for switching database engine: changing an existing database is a little more involved than just changing a config entry. I wrote a script to automate the conversion a while ago:

Hi Tom, Hey, there are no silly questions here! I searched and searched the fields and template for a 'max upload' setting but the only one I found was in the sub-field for the image which was set to '1' as I normally do when I need an image to be singular in a field. However, poking around I also found the 'Overwrite existing files' checkbox in the 'Input' tab of the image field. Checking this seems to have solved the issue. No idea why but I'm not complaining! Thanks Tom. Geoff.

I've added it to v072 as I could reproduce the issue. The z-index was applied properly only if RenoTweaks fixed header was on.

This might be a silly question, however it's easy to overlook the obvious sometimes. Do you have a max upload set to the field settings?

Unexpectedly found a half day to spare, so I've pushed 0.0.3 to GitHub. New features: Field settings for custom date, date+time and text fields can now be made on the inputfield's input tab, e.g. date and time formats, placeholder text or text validatoin patterns (numeric field settings are on the todo list) Names for custom fields are limited to start and end with ASCII letters and only have alphanumeric ASCII characters and hyphens in between Custom field name of "data" is silently stripped to avoid bollixing up all entries The custom fields table in the backend is now sorted by name (new entries simply get appended) The module is still alpha. Things are getting smoother, but there are still a few items on the todo list.

As promised, here's the script with delete powers. Only tested on a small subset of an installation I'm switching over to CroppableImage3 so do your own testing please!

You'll probably need to log out - that module only checks for new PW versions when logging in: https://github.com/ryancramerdesign/ProcessWireUpgrade/issues/10

Just a quick status update: I've started implementing different field types (text, integer, float, date, date+time) with native inputfields. Types can be switched back and forth, and I'll make it hookable so custom inputfields can be added as well. Will be a while though, since it looks like I'll be busy with a lot of other stuff until the end of next week. Here's a teaser though...

I haven't really read all of this thread, but just wanted to chime in with a brief overview of a help desk system I built. I can only show you screen shots from the test server — since the real one has sensitive data — but I think you get the idea. Unfortunately it's all pretty specific to our environment here, and was never intended to be released. Ticket List This is pretty small in the test environment. The lighting bolt icons open a modal that shows some "quick look" information for admins. Last comment, ticket history, etc... It's just a way to quickly peek into a ticket without opening it. Ticket View Many of these test tickets are filled with a ton of content, but here's one that shows some of the features. It's conversation based. You can attach specific equipment (we have several equipment databases managed in other PW modules). You can add files/images to any reply. Typical help desk stuff really. Reply options This is at the bottom of the discussion, a lot like it is here in the discussion forum. Agents can reply or create an internal note.

Hello for all, don't know if this is interesting to someone: //pseudocode example (inside some module) //we have some pages array (5 to 10 pages) wire('pages')->find('id=1111|2222|...'); // 0.050s, and ordering is not like selected wire('pages')->getById( array(1111,2222,...) ); // 0.035s, and ordering is exactly like selected It seems that query with "getById" is somehow faster and ordering is correct. Regards

There's also something similar in the core. If you look here https://processwire.com/blog/posts/new-module-configuration-options/#using-an-array-to-define-module-configuration you'll see that module configuration inputfields can be defined by an array. This is also possible for custom created forms, as it's mentioned to the end of the text.

When you create a user through the admin or through the API, it always gets assigned the guest role along with the custom roles that you assign. So if you assign a custom role "user", your user will have 2 roles: guest and user. Now you can check if a user has the role "user" and a total of 2 roles assigned. In PHP: if (count($user->roles) == 2 && $user->hasRole("user")) { //do stuff here }

Short answer: do what your site/application requires and whatever is within the limit of your server's resources. My 2 cents: One question I always ask myself when dealing with session data is whether or not I want that data to reflect the same exact information that I saw while visiting the page the next time I visit. If I revisit the page after I log out, close the browser, or hit the back button, what should that data look like? Typically, if (other) users, applications, functions, methods, etc. need to modify this data, then a session variable is out of the question for me. But if I want this data to be the same after I enter it, (ie: shopping cart information that I have added a shirt to when at work that I want to review when I get home) then that information might be alright for me to use in a session. Nonetheless, I still prefer to store only enough information concerning the session. I usually reserve session variables to hold information (user name, id, department, specific date of something important - maybe sale end date, shirt item number, etc) directly related to the user, application, or page that is being served. Then, based on those parameters, I make Processwire fetch the needed page(s) information (cost of the shirt, quantity remaining, etc) because these things are subject to change.

This option may be coming in the future.

Can we have Unique field setting same as Required under Input tab on any field? The reason is that if I need to have an email address or number type or other built-in field type then I cannot have unique and if I have to apply unique to the field then I have to use FieldtypeTextUnique field type and cannot utilize built-in type.

(but wait! there is someone acting very suspicious...)

Here you go: http://modules.processwire.com/modules/fieldtype-text-unique/