teppo

I don't think I've ever had to do this before, but now that I gave it a quick try, for me it seemed to work right out of the box: // test.php session_start(); if (!isset($_SESSION['user_id'])) { $_SESSION['user_id'] = date('j.n.Y H:i:s'); } echo "User ID for " . session_id() . " " . session_name() . " is " . $_SESSION["user_id"]; // processwire template file echo "User ID for " . session_id() . " " . session_name() . " is " . $_SESSION["user_id"]; ... and the user_id values were the same. Note that you can't start multiple sessions at once, so if you also included the session_start() part in your template file, this is redundant (and might cause an error). At this point ProcessWire has already started the session. If you do this, is the returned value from $_SESSION["user_id"] empty / unset? Technically yes, though I'm not sure how/why that would be useful. Just assign the value: $session->userid = $_SESSION["user_id"]. Note that if you're trying to log the user in based on the user_id value from another system, that's a different question entirely.

This is fixed in the latest release (SearchEngine 0.25.2).

Sorry @snck and @xportde, looks like I completely missed this question. Just to be clear, you mean the ___savedPageIndex() method? Running this when the entire index is being rebuilt should be doable, but it looks like I'll have to move a few bits and pieces to another class. I'll take a closer look at this — hopefully later today, or perhaps tomorrow.

As @LostKobrakai and @Jonathan Lahijani pointed out above, ProcessWire's database indeed is relational. I must also admit that I have no idea what some fields being redundant means — field tables with no values? Fields that don't have values for a specific page? Something else? Either way this is not something you messed up. Unless you've manually modified the values in the database (or the structure, tables, etc.) the database works exactly as it was designed to work, whether or not your client comprehends how it works or why it was designed that way. Also: reusing fields is the best practice, while creating a new set of fields for each template is something I'd advice against (it's bad for performance, will make selectors less useful, etc.) It's true that in what might be the most typical form — particularly for custom-built, one-off applications — each table represents a specific content type (pages, blog_posts, users, etc.) ProcessWire's database structure was designed for custom content types, so this "typical form" doesn't exactly apply here. Instead (at the most basic level) we've got a "master" table for pages, and then a new table for each field, connected to the pages table by the pages_id column. Anyway, I believe this has been explained a number of times already, so let's leave it at that. The long story short is that this is how ProcessWire was built to work, and this part cannot be changed. Behind the scenes ProFields Table creates a single database table for each field. So far it's exactly like any other field, but the big difference is that it actually allows one to modify the structure of that table via GUI, while for most other field types the table structure is "set in stone" (defined as codified rules within a Fieldtype module). The main benefit of a ProFields Table field is that it can very efficiently hold multiple (interconnected/related) value items — or table rows. A Repeater or PageTable field does the same, but behind the scenes each Repeater or PageTable item is a Page, and each property (subfield) is a field value. Thus the Repeater (or PageTable) approach comes with a different set of constrictions and benefits. (You could reap pretty much the same benefits by developing custom per-field Fieldtypes, but that takes a lot more effort than just creating and configuring a new ProFields Table field 🙂) I sincerely hope that you can convince your client that managing content handled by ProcessWire directly via the database is not the right approach. I definitely get that this is a frustrating situation, both for you and your client.

@Robin S, that works (in some cases) as well, but there are two reasons why I mentioned runHooks: Direct method call will cause an exception if myEvent hasn't been added as a hook method, runHooks won't. In this sort of scenario (events and listeners) the one emitting the event can't reliably know that someone is indeed listening, so this makes more sense. Direct method calls require that the name be a valid method name, runHooks doesn't. Notice how I used 'event-name' in my example? 🙂 First one is really the key reason, second one is just a little quirk that one might find useful, i.e. it's easier to make sure that your event name can't accidentally clash with a real method. Note: runHooks is tagged with #pw-internal. I've used this before in my code because I really needed it, but it's officially not a part of the public API, and thus in case Ryan decides to alter the implementation at some point, there's a chance that code relying on this feature may need revisiting. Just saying. Using only "official API methods" one would have to either check hooks with getHooks before calling the method (directly or via __call()), or just call it and handle possible exceptions with try ... catch.

I must admit that I can't understand all of this. Are you still having problems with the AJAX search feature? If so, it would be helpful to see a bit of code, to see what you're actually doing. Perhaps you could post your search template code and the JavaScript part via https://gist.github.com/ or something?

Sounds like $config->pagefileExtendedPaths would make sense here. Note, though, that I'm not at all certain what will happen if you enable this on an existing site with million pages — if you have the chance to create a copy of the site and test there first, that'd be a good idea. Otherwise be sure to take backups of both your site's files and the database before enabling this feature.

Do you mean the part about "$this->runHooks('event-name', $args)"? 🙂 If so, what I meant is that you could register your "listener" by hooking into some non-existing method in the TemplateFile object (or class), and then "emit an event" by running hooks: // somewhere early; prepend file or something: $this->addHook('event-name', function(HookEvent $event) { echo "<!-- I'm " . $event->arguments['what'] . " -->"; }); // alternatively you could add the hook in module or init/ready.php: wire()->addHook('TemplateFile::event-name', function(HookEvent $event) { echo "<!-- I'm still " . $event->arguments['what'] . " ->"; }); // then "emit an event" in the template file: $this->runHooks('event-name', ['what' => 'listening']); It's not quite the same thing, there's no queue, syntax is a bit crude... but as I said before, this might be enough, depending on your actual use case 🙂

A while ago I added an event listener / event queue feature for Wireframe objects: https://github.com/wireframe-framework/Wireframe/blob/master/lib/EventListenerTrait.php. The rough idea is that the object itself keeps track of events and listeners, and if an event is emitted ($this->emit('event-name', $args)), related listeners will be notified. This concept was loosely based on the Vue.js events system. This might be overtly complex for your needs, though. Something as simple as $this->runHooks('event-name', $args) would likely work just fine (though it depends on your use case) 🙂

Hey @eydun! While this could indeed be a potential addition at some point (not making any promises, but will keep this in mind), it's also already doable with a bit of code: if you hook after getItems(), you can add new items to the returned array 🙂

Not sure I fully understand what you're doing, but if you want to submit a search query with AJAX you need to post it to the same URL that you normally would post it to — if your search page is /search/, then that's where the AJAX query should go as well. Note, though, that by default SearchEngine responds to GET requests, not POST requests, so that may be one reason why you're not getting the results you'd expect. Might want to switch to jQuery.get() or change the method from POST to GET in your jQuery.ajax() call. Just for the record, SearchEngine has a built-in way to render results as JSON. This is what I typically use for AJAX search features. JSON data is pretty easy to handle with JS, and this way I'm not stuck with whatever markup the search results list on the regular ("full") page is using. When you asked if "Is it possible to realize showing results with AJAX like on the pics", the short answer is "it sure is" — but you'll have to create the markup and the JS parts yourself, since SE doesn't provide those out of the box 🙂

$selector = "category=$category, name|text~%=$q, name^=$letter, sort=$getsort"; I must say that I'm a bit confused about all this so might've completely misunderstood your point, but just to clarify: "name" and "text" were table column names, not fields on the page? And you're passing this selector to $pages->find() or pages()->find()? If so, you would need to specify them as subfields: "table_field_name.name|table_field_name.text~%=$q, table_field_name.name^=$letter". The point is that now you're referring to the "name" and "text" fields of the page, not the "name" and "text" columns of a specific table field.

One more addition to this: The API is, in fact, one of the biggest advantages of ProcessWire. While the preferred term is "content management framework", one may as well think of it as an ORM of sorts. ProcessWire was never designed for direct database access, and that's the whole point: it's meant to (mostly) abstract the database layer away so that both developers and content editors can (as much as possible) avoid the complexities and inherent risks of dealing with SQL queries. I must say that I don't agree at all with your point about ProcessWire's advantages taking a backseat once the website is finished. I get where you're coming with this, but I'd assume that we can both still agree that it's extremely rare for a client to actually prefer SQL over a GUI — let alone them being competent and meticulous enough to produce data that fulfils all expectations we as developers might have. Obviously we come from different backgrounds and thus have different expectations. If I would've suggested to any of the clients I've ever worked with a platform that requires them to use SQL, that would've been a disaster 🙂

Corrected in my post above. You're right, wires_challenge is in fact a persistent cookie that lasts 30 days. What kind of additional description are you looking for? 🙂

Each field may belong to more than one template, and each template has a different set of fields. Current structure works well with that concept, makes it possible to connect (or disconnect) fields with/from templates with ease, makes it unlikely for a single table to grow to giant proportions (thus making all queries against it slower), and also allows fetching/searching/saving the exact data that ProcessWire needs to fulfil a specific request. So yes — there are advantages to current structure. It's also a very fundamental part of ProcessWire, so changing it is not possible without major changes to the core 🙂 It has been. If you'd like to read a bit more on it, I'd suggest doing a google search for something like "processwire database structure". You'll find a lot of existing content on this topic 🙂 Your point of view is not unheard of for newcomers but trust me, there are valid reasons why the database architecture is what it is. Much of it is due to the fact that ProcessWire — unlike some competing platforms, I might add — was designed with custom data structures (custom fields) in mind from the ground-up. Some other systems (WordPress, for one) have a much simpler database structure, but that's because they weren't originally intended for the same kind of use as ProcessWire. In the context of ProcessWire this would be a bad idea: First of all the Admin is a ready-to-use tool for managing content, and I highly doubt that anyone will really have easier time managing the content with raw SQL. It can be fun and/or if you've had to do that a lot in the past you may be used to it, but still: ask them to give the Admin a try and I bet that this idea will go away in no time. If you manually update the rows in the database, most of what ProcessWire's fields do will be completely skipped. This includes validation, filtering, and sanitization; things that are there to help you build sites with valid and well formed data. Without these features you will run into trouble eventually, it's just a matter of time. ProcessWire does internal cleanups and such using hooks, and those will not get triggered if you update the data manually in the database. This means that you'll likely be left with broken data, missing pieces here and there, and so on. Some fields (take Repeaters for an example) will also be very difficult to update manually via database. Finally, while we're on the topic of hooks: they are a major feature in ProcessWire, used by both core and third party (module) code — and, once you get used to it, probably your own code as well — and again if you don't go through the "official channels" (API or Admin) you'll loose this benefit altogether.