ryan

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).

As far as I know, there was only that one old buggy version of MySQL, but that created problems for anything running in it, so it's kind of a rare thing to find it. I doubt the MySQL version is the problem in this case. What 3rd party modules are installed? What browser and version are you using? When you move a page, does it immediately return back to the original location, or only after you refresh/reload the page? Do you literally have pages named "page2", "page3", etc.? If so, you might want to consider different naming because that's the default naming of pagination URLs.

It sounds to me like that person unintentionally edited and renamed the 404 page. The safest bet would be to just assume that is your 404 page and change the title back to "404 not found" and then lock it. But it sounds like you already found a solution there.

What version of ProcessWire are we talking about here? It sounds like 2.3 based on the file names mentioned, but want to double check. That seems pretty odd that PHP is writing sessions somewhere other than where specified. But ProcessWire uses PHP's native session features, so PHP is the one ultimately reading the session file rather than ProcessWire. Meaning, it's not possible for ProcessWire to read it from the wrong place, and I doubt PHP would read it from the wrong place. The only exception would be if you are using Database sessions, which is a module included with ProcessWire 2.3–did you install that by any chance? That would change the things that we need to look at. Also, just to rule out other possibilities, disable the "session fingerprinting" option in your /site/config.php and change the default session name from 'wire' to whatever PHP's default is: $config->sessionName = session_name();

Welcome @pnikosis, glad that you are enjoying ProcessWire! If you've got an external database that is still being updated than I would just query the external database rather than trying to load it into PW. On the other hand, if the database is no longer being updated (meaning, you wouldn't have to maintain two versions) then moving it into PW might make sense. But for querying the external database, you can use mysqli, but you might also want to look at switching to the PW dev branch (future version 2.4) which switches to the PDO database driver. Mysqli is still available in 2.4, so you can actually use whichever you prefer. Though mysqli will probably be dropped once we reach ProcessWire 3.0, but if it's installed in your PHP then of course it remains available for you. So if you use mysqli, probably it's better to use PHP's "mysqli" class rather than ProcessWire's extension of it, just for future compatibility.

All ProcessWire fields are indexed (including datetime fields), so I don't think you'll have a problem with it being slow. But if you want to retrieve and load a 1000+ pages at a time, that could be potentially slow (and perhaps run out of memory). It's important to place limits (i.e. "limit=50") on any queries that can return huge amounts of pages, in order to ensure that everything stays running fast. I don't think that would be slow. But paginate your results by placing a limit to be sure. Also, I doubt that you need the parent=/events/ since you are already specifying a template. Though if I understand your structure right, if you did want to specify a parent, you'd probably want to use has_parent rather than parent, since the time pages live under /events/some-event/ rather than /events/. Last thing to note is that you can't have spaces before/after operators like you do in your time.date_end > $today" -- that would need to be "time.date_end>today". Btw, you can specify "today" rather than populating a $today variable, if you prefer. Actually you can do this. But note the same suggestions I had above. There would also be this alternative, which might be potentially faster because ProcessWire is a little more optimized for parent-field matching queries than children-field matching queries (given that a page can have only 1 parent, but any number of children): $pages->find("template=time, parent.on_frontpage=1, enddate>today"); When you foreach the results of that, note they are 'time' pages rather than 'event' pages, so you'd want to refer to the parent in order to get the event.

Thanks, I understand now. If you look in the FormBuilderEntries.php file, you'll see this line: protected $dateFormat = 'Y/m/d G:i a'; That 'G' is actually supposed to be a lowercase 'g' for 12-hour format, as 'G' is 24-hour format. I will correct this. You can also change it yourself in that file if you'd like, or you can can do this in your foreach loop above: $e['created'] = date('Y/m/d g:i a', strtotime($e['created']));

It sounds to me like an issue of case, somewhere. The skyscrapers profile field name is fieldset_meta_END (where END is uppercase). What is the case of the table in your MySQL db? I'm guessing it's got the uppercase END in it. You might try adjusting this setting in your /site/config.php to false, or rename the table in PhpMyAdmin to be all lowercase.