ryan

Since it's using LIKE in this case (rather than fulltext) it won't matter. I just tested it out here on the skyscrapers profile. These queries worked for me: $pages->find("map.address%=peachtree"); // returned all skyscrapers on peachtree road $pages->find("map.address%=pea"); // returned the same thing $pages->find("map.address%=191"); // Returned "191 peachtree road" skyscraper Try grabbing the latest version of FieldtypeMapMarker. I updated it to have the new getMatchQuery method. I also modified it a bit so that it supports ^= and $=, and all the fulltext searching operators. Though the fulltext operators will only work on newly created fields, since existing installs won't have a fulltext index. But like DaveP said, you'd have to have a very large quantity of items before you'd see the speed difference.

Maybe the ability to have predefined bookmark pages (favorites?) Probably can't do this with the current images fieldtype, as the uploader is part of a fieldtype, and a field is attached to a page -- There is no way to upload images outside of the page editor. Meaning, you have to be editing a particular page in order to upload images to it. If a page has an images field, it manages it's own images. The way to achieve what you are talking about would probably be a new images fieldtype that shares a common storage area with other pages.

See the user comments section on the strftime reference at php.net. There appear to be lots of feedback and means of working around this issue with strftime.

It depends on what admin user you want to grab, as you'd need to refer to them by name. But assuming the name is 'admin', you'd do this to send them an email: $admin = $users->get('admin'); mail($admin->email, 'Hi Admin!', 'This is a test'); You might also notice this in /site/config.php: /** * adminEmail: address to send optional fatal error notifications to. * */ $config->adminEmail = ''; If that is defined, you could use that for your purpose as well.

I'm not sure I understand this particular issue, but will experiment. Thanks, not sure how I missed that one. I have updated it, and it should appear in the source very soon.

ProcessWire now implements ALL of the jQuery traversal functions in the Page API. Existing ProcessWire versions already implemented most of them, but once we started updating parent() and parents() to support selectors, I figured we might as well be fully complete and consistent with the jQuery equivalents. Now we are. The following functions were added or updated: $page->parents([$selector]) -- Now you can specify a $selector and it will return parents that match your selector. $page->parent([$selector]) -- Now you can specify a $selector and it will return the closest matching parent. $page->closest($selector) -- Same as parent($selector) except that it considers the current page in addition to the parents. $page->parentsUntil($selector, [$filter]) -- Return all parents from current till the one matched by $selector, optionally filtering them afterwards by $filter (a selector string). Note that $selector may be a selector string, a Page, a path, or an ID. $page->next([$selector]) -- Now you can specify a $selector and it will return the closest matching next sibling. $page->nextAll([$selector]) -- Returns all siblings that come after this $page, optionally filtered by a $selector. $page->nextUntil($selector, [$filter]) -- Return all sibling pages after this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID. $page->prev([$selector]) -- Now you can specify a $selector and it will return the closest matching previous sibling. $page->prevAll([$selector]) -- Returns all siblings that come before this $page, optionally filtered by a $selector. $page->prevUntil($selector, [$filter]) -- Return all sibling pages before this one until matching the one specified. Optionally filters the results by $filter, which is a selector string. Note that $selector (the first argument) may be a selector string, a Page, a path, or an ID. Arguments in [brackets] are optional. These functions duplicate the arguments and behavior of their jQuery counterparts. The exceptions are that parent(), next(), and prev() have a slightly different behavior: they will traverse to find the closest match (which I thought was a lot more useful in our context). In jQuery, they don't traverse beyond the direct parent/next/previous item in the DOM. As before, all the next and prev functions should be used cautiously when $page has a large amount of siblings. All these functions require loading all the pages they interact with, as comparisons are done in memory and not via SQL queries. All of them accept an optional last $siblings argument, which is a PageArray of siblings you want it to analyze (which is presumably a more limited set), and this is what you'd use if you need to scale to thousands of pages when using these functions. But if you aren't dealing with huge amounts of pages, then you don't need to consider this.

Like Alexa scores, I'm guessing their methodology is mainly good for looking at trends and is just ballpark. But I haven't found anything more accurate. I would be curious how they can track some of this. Certainly WordPress and Drupal are easy to track because they are markup generators and call attention to themselves all over the code. But not all CMS products reveal themselves, and I'd actually consider it an asset for the CMS identity to be unknown (at least from an administrator and security standpoint).

I don't think that's a security problem, but I would personally find it confusing. Why not just name your directory "pw" instead?

The two one would have to consider are: Page Fieldtype -- keeps track of an ID from the pages table, if you choose to use the "parent" as the criteria for selectable pages. It doesn't add anything to the pages table, it just keeps track of an ID already in there. Repeater Fieldtype -- This one actually generates pages as you mentioned (and it's the only I'm aware of that does). Any continuous integration tool would probably want to exclude these two, or at least the Repeater one, until version 2+. I think it fits the commercial option well. My plan is to add JSON import/export to templates and fields very soon (very much like what's in FormBuilder). But this is just a quicker way of doing it manually (copy/paste vs. doing the work), it doesn't have the scope of a fully automated deployment tool.

You may need to enable URL segments for your template where this is being used. Setup > Templates > [your-template] > URLs If you've got code checking the user language, you want to make sure you set it somewhere. I am assuming that the $user is a guest user and not a logged in one (where they could have a predefined language setting). if($page->name == 'english') $user->language = $languages->get('en'); Also note that when you set $user->language, it's only going to be retained for the request. So if you want it to be remembered between requests, you'd want to track it with a session: if($page->name == 'english' || $page->name == 'en') $session->language = 'en'; if($session->language) $user->language = $languages->get($session->language); baseUrl will only add confusion, so I would avoid that. It sounds to me like you need to enable page numbers for your template. Setup > Templates > [your-template] > URLs > page numbers

Okay cool, I've been on the 2.3 dev for awhile and might not be remembering if this was in 2.2.9 or not. But give it a try sometime and let me know if you find it's missing anything in that regard. This is one thing that ProcessWire does not do out of the box. In this regard, it starts from a security over flexibility model. It maintains a strong separation between what is public/guest and what is admin. Whereas with something like Drupal, you can blur the line quite a bit. In fact, I've actually used Drupal when I needed this quickly. But ProcessWire can certainly do it all just as well, if not better, but it'll take a good deal of code to implement it and make it secure. The admin is for trusted users, even if they don't have access to do a lot in there. So if your users fit the definition of "trusted" then this would be a fine approach. But I would avoid anything that would make it possible for any random person to create an account and then get into your admin. This is the approach I personally prefer, and it's the one I use for modules.processwire.com. But you do have to consider security at ever step. Make sure you limit the fields they can populate and don't let them change things like template, parent or status. I would also avoid any kind of file uploads, unless you are using a tool like FormBuilder that can quarantine them for approval.

I noticed that too. At the time, I tinkered with it for a bit, but couldn't figure and gave up. Will play with it more next time I'm on there, but if anyone else finds the solution sooner let me know…

FieldtypeMapMarker doesn't implement a getMatchQuery method, which is required in order to support any operators that don't exist in MySQL. For instance, MySQL knows what "=" and ">" are, but it doesn't know what "%=" is. So I'm guessing you are getting a "Operator '%=' is not implemented in FieldtypeMapMarker" error message. The second issue is that there isn't actually a field named 'address' in the DB, as this fieldtype represents it with the default 'data' field. Meaning you would just refer to it as "map_marker" (or whatever you field name is) rather than "map_marker.address". But the truth is, since we're using 'address' as in this Fieldtype at runtime, we really should allow it for queries too. Try adding this to your FieldtypeMapMarker.module, which should solve both issues: public function getMatchQuery($query, $table, $subfield, $operator, $value) { if(!$subfield || $subfield == 'address') $subfield = 'data'; if($operator != '%=') return parent::getMatchQuery($query, $table, $subfield, $operator, $value); $ft = new DatabaseQuerySelectFulltext($query); $ft->match($table, $subfield, $operator, $value); return $query; } Let me know if that works out for you, and I'll add it to mine too. I'm also going to add a fulltext index to the 'data' field so that we can use other partial match operators.

This is because all users are required to have the guest role. If the guest role were checked, the LoginNotifier would never send any notifications.

Sure--though I am aware of most of them, but it would be good for me to know which ones are most important to people so that I can put those first. The two you mentioned are actually fields, so they are in the DB rather than a file. You can edit them by editing the 'roles' or 'email' fields. These don't appear in your fields list until you click Filters > Show System Fields. Currently we only support singular and plural, and not multiple kinds of plurals. I will have to add support for this the next time we are doing upgrades to the Language Support modules. Though so far it's not clear to me how the function implementation work for this. I'm looking for gettext examples that demonstrate it.

I tend to think of the tools that I use in ProcessWire as part of the overall API for the site even if they aren't part of the PW API. But you may be right, and Lib might be better for stuff that isn't actually extending or connected to the PW API.

You most likely ran out of memory. MAMP and other *AMP installs often come configured with 32 MB memory limit for PHP, which isn't enough to upload largish files via ajax. View your phpinfo to see where your php.ini file is located. Edit it, and change memory_limit to 256M. Also in php.ini, update post_max_size to be the same or larger. Restart server and double check that the changes took effect by finding memory_limit in your phpinfo output.

Matthew, don't worry I know what you mean. You always have good ideas, so I'm just trying to make sure I understand. I'm still confused, so bear with me. When a page is created you only have two fields: "title" and "name", and of course name is populated automatically. If you don't populate the required field (title), the page won't get created. Do you mean when an existing page is saved, rather than when a page is created? Once the page has been created, you are editing an unpublished page. If you have an email address field that is required and neglect to enter an email address, or you enter an invalid email address, it won't let you publish the page. That page isn't publishable until it validates with the rules you've set. At least, this is the way it's supposed to work (at least in 2.3 or dev branch). Let me know if you are getting different behavior? Creating custom forms from the API and using the submissions to create/modify pages -- I'd consider this an advanced topic. In fact, the only place I've done it (that's in current use) is the site modules.processwire.com. While it's true that it's relatively easy, it's also something where security is a major factor to consider, so something I don't think newcomers should start doing right away. We've outlined how to do this many times on the forum, but think we'd benefit from a tutorial on the wiki or something -- more documentation always a good thing. Form Builder is a good alternative for this, though not as wide-open for options as doing it all yourself from the API.

For modules that add something to the API or are intended for API use, I agree with Adam that "Lib" would be a good prefix, but "Api" might be even better. In terms of the module directory, we'd probably call the category "API Extensions" or "API Tools".

All fieldtypes provide their own validation configuration options. Some have a lot of ways you can customize and configure the validation, whereas others don't. Which fields do you think would benefit from more validation options, and which validation options would you add? I regularly add more configurable validation options to fieldtypes, so always looking to spot needs here. Can you go into more detail -- I'm not sure I understand? At least the code igniter example is confusing to me because it seems like it is just wrapper functions for general purpose form markup, and not clear on the benefits of that. But I'm also confused about the creating/editing pages part.

Good idea. I've added a role exclusion feature to the module's configuration so you can check boxes next to any roles you want excluded from sending notifications. https://github.com/ryancramerdesign/LoginNotifier/commit/178c45681deab344e120eb64e4270a23866626e8

We can open this up so it doesn't filter out brackets. But it would only be in 2.3+, so this module should probably stick with the current method for the moment.

Good to see you here Radik, and thanks for your work with the localization and module. This is a high volume function, so I'm implementing the hook a little differently here. Can you try replacing your LanguageSupport.php file with the attached and let me know if this still works with the hook the way you need it? LanguageTranslator.php Also, when ready, it would be great if you'd like to add your localization and module to the modules directory at: http://modules.processwire.com/add/

If nothing is going to get stretched to reach the target, and the source is bigger than the target, it's kind of splitting hairs. My eyes won't be able to tell the difference at least (not that I have good eyes). I don't disagree that the capability is desirable and that there will be those cases where one would have better than the other. But everything costs time and money to do, and so the developer of this module (or the developer of any module) often has to focus on their own needs. If it's not something the developer will use themselves, it can be too costly to develop without a sponsor or collaborator. If this is something you believe in and are interested in developing, you can always update the module and submit a pull request, or offer to sponsor the feature with the developer. Sooner or later someone will have a similar need, so it's also good to get the ideas down here as you have, as another developer may come along and implement it too.

Antti has been developing a Shop module for ProcessWire and it is in successful use already. I'm not sure how many other users might be using it, but I think he's done a very nice job with this. However we don't have plans for e-commerce to be part of ProcessWire's core product, at least not in the current roadmap. So any e-commerce solutions for ProcessWire will be 3rd party solutions, whether running on ProcessWire or on an external service. I've developed and run an online store for many years and have quite a bit of experience with several self-hosted e-commerce software products, and more recently, hosted e-commerce products. When a client asks me what to do for e-commerce, I like to point them towards services like Shopify (my favorite), Volusion, BigCommerce, etc. These services are targeted specifically towards the needs of e-commerce in a way that no self hosted product can touch (at least for what matters to me and my clients). Plus they are hookable (at least Shopify is) making it easy to perform actions in your PW site based on an order, in real time. Paid membership sites suddenly become a piece of cake. This makes nearly anything possible, and IMO more powerful even than dedicated products like Magento. Now with PCI compliance (at least in the US) I really dislike the hassle and time expense of self hosted solutions for my own needs. I don't think ProcessWire needs to be all things to all people, and I'd rather focus our energy on the things where we are and can be better than everyone else. For the same reason, I don't want us to invest time in creating forum software when something like IP.Board exists. We want to empower web developers with the best solutions out there. This is a much bigger question for proprietary and non-open source products. It's a good question, but doesn't have the same gravity when applied towards an open source product with hundreds (or thousands) of people around the world familiar with the system and code. At least in our case, when a bug turns up, many times the user submits a fix with the bug. Beyond these forums, I also do some support email. But very little comes to me anymore. The forums and community here have been better than I could have ever imagined. I should also note that a goal for 2013 is to provide commercial support options for those that want it. I'm not yet certain if the market is there for it, but it's something I would like to have available. We are on a path for growth and I see us continuing our current strategy of building and improving the software and resources around it. My 5-year goal has been for us to power 3% of the PHP open source CMS-driven sites in the world and/or be top 10 (open source) in terms of usage. I think that our growth comes from WordPress users looking for more, and front-end developers getting into content management without a previous allegiance. We'll also get our users from other CMSs. But WordPress is the one building the audience, and the developer and non-blog-portion of that audience is using the wrong software. With that audience, ProcessWire answers everything that WordPress can't, while being simpler to use and develop for. There are other CMSs that are also good stepping stones, but all are significantly more complex.