ryan

It sounds like your version of MySQL won't accept default values for a text field. I've not heard of that before. Perhaps it is some MySQL setting that I've not seen before. Seems like if it won't accept a default value (which we specify a blank string) then it could only be null as a default. Not that it matters much, but I'd prefer the blank string since there is no use for a null here. I agree that removing the default that you did shouldn't cause any issues. I'm curious to see if this issue turns up for anyone else.

I think that supporting multi-day events would just be a matter of adding an end_date field, and consider the existing date field a start_date field. Either that, or you could use a "number of days" field instead of an end_date, but I think having distinct start_date and end_date fields is better because they can support a time component, and they can be queried more easily.

This is planned, just haven't yet found the time to implement it.

The way you describe it, it definitely sounds like something isn't working right with the database then. If you have the opportunity to upgrade, that seems like the right thing to do.

Just add something like this to the top of your events index page. You could compartmentalize this into a LazyCron call, but for such a simple thing it's really not necessary. $events = $pages->find('parent=/events/, date<"-3 months"'); foreach($events as $event) { $event->of(false); $event->addStatus(Page::statusUnpublished); $event->save(); } Btw, when testing something out like this, always comment out the $event->save(); the first time and take a look at what pages get affected by echoing them rather than saving them, the first time around. i.e. // $event->save(); echo "<p>Unpublishing: $event->url</p>"; Once confirmed that it is behaving the way you want, then remove the echo and uncomment your save();

I'm not really sure what could be causing that. Apache and .htaccess know nothing about URL segments... that is only a ProcessWire term. To Apache/.htaccess those URL segments are just a part of the REQUEST_URI like anything else. I would comment out that directive in your .htaccess and look elsewhere (in your .htaccess and in your PW templates) to see where the redirect might be coming from.

I understand what you are trying to do, but can't currently think of a way you can do it (at least not in any straightforward manner). Even if you could do it from the CSS side, there are other factors like sorting (which is designed to work vertically), and the add new items actions, etc.

I think that you are on the right track using Pages rather than Repeaters for your sections. Actually, it looks to me like all of this stuff is intended to be output as pages on the front-end anyway, so you may want to avoid using Repeaters entirely. Repeaters are great for specific use cases, but you are far better off using Pages when it comes to anything site-structure related. If I've misunderstood the need to use repeaters here, then one solution you could look at would be to simply include your section_header field in the year_wrap repeater, and specify in your field description that the user should only specify a section header when they want to change it, and to leave it blank otherwise.

There may be a way to do it from the SQL side, and that would probably be a good use case for using an SQL query rather than a selector. I don't currently have plans to make selectors support that level of query, as it's a pretty rare need (this being the first time it's come up). When a query needs to perform a currency conversion (and this is something I've had to do), I perform the currency conversion first, and then use the converted value in the selector query. That actually reminds me that I have a currency conversion module that I need to finish up and post soon.

Awesome Nikola! I really like this module. Just a few suggestions: The module should not extend Process since it's not an admin process. Instead it should extend WireData. The module should not be autoload since it is loaded from an API call instead. Ideally the module would be called MarkupWeather or MarkupYahooWeather, since the "Markup" prefix is recommended for all markup-generation modules. Please add it to the modules directory as soon as you get the chance. It's a lot simpler to do now, as the modules directory pulls most stuff right from your GitHub page.

While you may be able to use some of these syntactic tricks when it comes to setting a value, I think it's better to treat a Page as a Page and a PageArray as a PageArray, just as a matter of keeping your code readable. If I have code that needs to deal with either a Page or a PageArray, but it doesn't know ahead of time which it will be, I usually treat it like this: if($value instanceof Page) { // treat it as a Page } else if($value instanceof PageArray) { // treat it as a PageArray } Or I normalize it to one or the other. For instance: if($value instanceof Page) { $a = new PageArray(); $a->add($value); $value = $a; } // now we can assume $value is always a PageArray

Testing here on a TextareaLanguage field, I also wasn't able to duplicate the issue. Do you have any other 3rd party modules installed? If we can't determine why it's exhibiting the behavior there, you probably just want to turn off autojoin for that particular field. There's not a lot of benefit to using autojoin, particularly on a multi-language Textarea field. On most of my sites, I only have 'title' autojoin.

I took a closer look at this and realized we'd need to set that config.user variable in the admin theme, and that it'd be better not to have an admin theme dependency for this module. So what I did instead is updated your module to pass along the active tab index in it's JS settings (config.LanguageFieldTabs.activeTab). It determines the active tab based on: if a GET variable is present called "language", containing the ID of a language, it uses that. Otherwise it uses the current user's language. This way you can have it focus on the right language tabs when a user clicks "edit" from the Spanish version of a page, for example. Here is what my edit link looks like on the front end: echo "<a href='{$config->urls->admin}page/edit/?id=$page->id&language=$user->language'>Edit this page</a>"; If there is no "language" GET variable specified, then it just defaults to the current user's language, whatever that may be. The end result is that the tabs always focus on the right language. In testing here so far, it seems to work quite nicely. I just sent over a pull request for this update.

That's not by design, and that's not how it works for me. Just tried it on a page with two image fields "screenshots" and "logos" and it shows images from both. The RTE image/file selection tools don't know anything about fields named "image" or "files", they just look for fields that extend FieldtypeFile.

Looking great Soma. One quick suggestion would be to update your getDatabaseSchema method to have separate indexes on the width, height and depth. Currently, your index would only be used if one queried width and height and depth, or width and height, or just width, as the order matters in a combined index. If someone tried to query height independently of width, an index wouldn't be used. Whereas if width, height and depth each had their own index (either to replace, or in addition to the existing index) then they would all have the potential of having their indexes used in PW queries. This is assuming my understanding of MySQL combined indexes is correct: if you query just depth or height there would be no index to use since it is not the first named field in any combined index.

I'm not sure why it wasn't working in my case, but will try again. Good to know how the capability is provided (collagePlus), I like it so much you have me thinking this should be the default output.

There's no harm in going the multi-tree route. Technically, it's probably the simplest to understand and implement. But it is also more work to maintain as it grows. As things get larger, I think you'd enjoy having the Multi Language Page Names + Multi Language Fields modules handling it for you. So it sounds like you are on the right track. Though if you are literally talking about a tiny site (you mentioned 2 pages?) I'd keep it simpler and just use multi-trees, though I think it's still a good experience regardless of what multi-language setup you use.

This is exactly what Fieldtypes are designed for: to contain a type of data represented by a table (schema), whether that implies a single field or a whole bunch of them. You can also achieve the same thing more easily by using 3 separate fields in PW, but you are right that it will take more overhead for PW to manage it, and there are UI benefits to having a dedicated Inputfield. However, query counting is usually a waste of time. Unless you are dealing with these items at a massive scale, there is unlikely to be a measurable difference. So when thinking about this stuff you do have to consider what is more worthwhile. In your case, I think a Fieldtype+Inputfield makes more sense, given that you are willing to explore deeper into the code of creating Fieldtypes/Inputfields. But unless you are dealing with hundreds of thousands of pages, I think the greater benefit here is just the dedicated Inputfield aspect.

If your module is extending WireData, then $this->data is already an internal property. As a result, you can set values in $data just by $this->set($key, $value); and this syntax is preferable since it doesn't bypass change tracking.

I'm in the process of converting everything in the Wiki over to the main site. The Wiki is getting all kinds of strange traffic from the logs, and it's database is many gigabytes in size (when it should be more like a megabyte). Basically, I don't trust MediaWiki here, at least since I'm not an expert with it. I'd feel more comfortable having all this content on the main site, so it should be there soon.

Thanks for posing this Kyle! A few things to mention: For even more security with the activation code, you might want to use something completely random that isn't influenced by the username. We have something built-in that will do the trick: $p = new Password(); $hash = $p->randomBase64String(100); // 100=length of string See here how it works: https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/Password.php#L154 (code is originally from Anthony Finta's password_compat library). Make sure that you are using $sanitizer->pageName("username"); for your username sanitization. Using $sanitizer->text(); is not adequate for sanitizing usernames or any selector values. In your function that checks for duplicate usernames, check for duplicate emails as well. When you check for users or emails do $users->get("name=$username") rather than $users->get($username); as this will ensure it's checking for only the username, and not potentially confusing a numeric username with a user ID. I recommend using $input->get->var rather than $_GET['var'] because the $input->get version makes it so that you never have to worry about PHP's magic_quotes setting. Last thing to mention is that it might be good to include what type of fields the user_real_name and user_activation are. I believe these are supposed to be text fields, but wasn't sure (especially for user_activation) until later.

Not a dumb question it all. Sounds to me more like an issue in the skyscrapers profile, I'll look into it.

The main reason for the date setting being static is that it has to be string-sortable. Many date formats are not string-sortable, so we try to make sure that any shown in the PW admin are sortable among other dates. Not sure how important it is in this case, so I probably could make it configurable, but just wanted to mention the reasoning behind using ISO-8601 style dates in admin situations.

Either mysqli or PDO is equally stable so long as you use PHP's version rather than ProcessWire's version. ProcessWire has the WireDatabase class for mysqli and WireDatabasePDO class for PDO. They are primarily just wrapper classes used for tracking queries, so you shouldn't feel like you have to use them. Yes, it's generally pretty stable, and it's what I use for any site I'm working on. The only thing I'd advise is just keeping more of an eye out for issues and reporting them if you see any. You also want to test thoroughly every time you update to a new commit in the dev branch. Whereas on the master branch, you can assume that what's there has already made it through dev branch testing (i.e. had more people using it before you did).

I've been putting some thought into it here, and am thinking we need a config.user.language variable added to PW's JS config variable. I don't yet see another way for LanguageFieldTabs to identify the current user's language. Let me know if this sounds like what you'd need, or if you had another idea? Also, I just submitted a PR to you that makes the empty vs. populate state of LanguageFieldTabs work with CKEditor inline mode, and also makes makes that state a little more more useful for the page name (2.3.2+/dev branch).