ryan

I took a look at your PHPinfo and it seems to look okay. At first I thought I found something in your configure command with '--disable-json', but then noticed that JSON support is still there, so apparently that's not it. Though I'm not sure I understand that discrepancy. The only other things I noticed were that 32M is pretty low for memory_limit. I would bump that up to at least 64M or 128M. I don't think that's the problem here, but I do think it could be a problem at some point. Though if it's easy enough for you to change, it would be worth a shot. The last thing I noticed was that there are just a whole lot of extras in this PHP install. There are more PHP add-ons in here than I think I've ever seen before, from various caches to other things I'm not familiar with. Doubtful that any of those are the issue, but just an observation that we may come back to if nothing else turns up. I'm not sure what to tell you to try next. But if you would like, I do believe I could figure it out if I could get in through FTP or SSH and do some old fashioned debugging to determine where it's getting caught. If you would like me to do that, just PM me the info needed to get in, and I'll let you know what I find.

In ProcessWire, a Fieldset is technically a type of Field, so the manner in which you edit it is no different than any other field. But what's different is in how you define the scope of the Fieldset. Fieldsets just define a starting and ending point for a group of fields. A fieldset consists of two fields: 'fieldset' and 'fieldset_END', replacing the 'fiieldset' with whatever you named it. Add your starting and ending fieldset fields to a template. Drag the 'fieldset' where you want it to start, and drag the 'fieldset_END' where you want it to end. Then save. The fields between those two will then be grouped in the page editor. Note that tabs work the same way.

Could I get a look at your phpinfo()? Paste this into a file called test.php and then PM me the URL: <?php phpinfo(); One more question, is the installation that's failing installed to the domain root or a subdirectory? If it's in a subdirectory, paste in here what you've got in the .htaccess of the parent (non-PW) directory.

Good idea. We could do this, and I think we definitely will, but it's not as easy as it sounds. On most servers, the file system is not writable to ProcessWire (except for /site/assets/). So the way around that is for ProcessWire to perform the upgrade through a PHP FTP client (and user supplies the login information to ProcessWire). I'm guessing that's not particularly difficult to do FTP through PHP, but I just haven't tried it yet. Extracting ZIP files is also something that's not as universal as I'd like, but we'll make do. When we build this, we'll probably do it with a module. I'm not sure I want ProcessWire to 'phone home' unless the user tells it to, so it could be a module that's not installed by default, but once installed, it will start phoning home to check on version (using LazyCron, like you suggested).

Don't worry about it. Soma was just saying that there's been a lot of demand for this particular feature and it's a good idea. Keep posting and don't worry too much about searching (the search engine isn't great either). If everyone searched for it rather than posting, we might assume there wasn't much demand for this feature. I'm glad to know about the demand for repeatable fields. This is a small community and I'd almost always rather have people post than not. If we start having to keep up with hundreds of messages a day, than that would be different. But for now, when in doubt, post. You've added some good points to this discussion, and there will be a lot of good reference material in the forums for when this feature is in production.

Check that your server actually supports the .htaccess file. Type "alejkfagjkaelgjk" or something at the beginning of it and save. If you don't get a 500 error on your homepage, then your Apache is not configured to use .htaccess–let me know if that's the case, and I'll tell you how to fix. Do you have SSH access to the server? You might want to do this, just in case some permissions were lost in the transfer: chmod -R og+rw /site/assets The ProcessWire installer can identify most potential compatibility problems at a server. It would be good to download a new copy of PW and install it in a subdirectory there, just to see if it finds any issues with the PHP version, htaccess support, missing drivers, etc. You don't actually need to do the installation, you just need to have a look at the first screen where it performs a system check. This will most likely reveal what the issue is.

I didn't realize that you also added a languages API var, sorry for the duplication there. The new $languages API var can also be hooked in many ways, and I'll be glad to add anything to it that would be helpful to you–just let me know. The $languages API var is extended from this class, which is the same one used by users, roles, permissions, etc. This class: /wire/modules/LanguageSupport/Languages.php Extends this class: /wire/core/PagesType.php Each of the languages is actually just Page. If you iterate the $languages API var, you can get all the language pages. There is also $languages->get(...) and $languages->find(...) that function just like the ones from the $pages API var. I'm not sure that I have enough background on your module to answer that. But did want to mention that the new LanguageSupport module adds a template called 'language' that is used by each Language Page. You can add fields to that template like any other. So if you were to utilize the PW 2.2 languages with your own, then I'm guessing you would likely add the fields to that 'language' template that your module needs, and then they would be available in all the languages. Again, I'm not sure if this is the right strategy for your module or not, but just wanted to mention that is one of the ways it can built upon. It is. The $languages API var can be extended like anything else. If you wanted to add new functions to it, then you would just add a hook for a function that isn't already there. i.e. <?php wire('languages')->addHook('languagesNewMethodName', $this, 'thisClassMethodName'); …or… <?php $this->addHook('Languages::newMethodName', $this, 'thisClassMethodName'); I'm happy to modify or add anything necessary to support the needs of your module – just let me know of any way I can collaborate or be of help.

Remaining the /processwire/ page is always a good idea, especially if your client is prone to using insecure passwords with their accounts. When you first rename it, note that you may get a 404 after saving it. That's okay–it's expected since the admin moved. Just navigate back to your new admin location.

Edit your /site/config.php and change the line that has $config->debug = false; to be true. Then you may get something more descriptive than a 500 error. Check that the /.htaccess file is there, and is the correct one for ProcessWire. Very often when migrating a site, it's easy to miss the .htaccess file and end up with one that was previously on the server. This is the first thing I would check. You mentioned that your index page works? Are you seeing the proper homepage for your site? If so, that's good and that would rule out a database issue. Are you able to access /processwire/ ?

Another way you can go is to use page reference fields. Add two new 'Page' reference fields: topnav and footnav. Make them support multiple pages. Don't restrict it to a parent or template. Select 'PageListSelectMultiple' as the Inputfield for them. Save, and add them to your Homepage template. Now edit your homepage. For the 'topnav' field, select all the pages you want as part of your top navigation, and for the 'footnav' field select all the pages that should appear in your footer navigation. Drag to sort them in the order you want. Edit your main markup file (or head/foot includes) and use the following code to output that navigation: <?php foreach($pages->get("/")->topnav as $item) { echo "<li><a href='{$item->url}'>{$item->title}</a></li>"; } …repeat the same for the footer nav, except iterate the footnav (rather than topnav) field. In the sites that I develop, I almost always have the footer nav hard coded in the main markup file (I don't usually need it to be dynamic). For when I need the topnav dynamic, I'm usually sticking to the site's root level structure for the navigation (iterating the non-hidden children of the homepage). You may need all this stuff to be dynamic, in which case there are a lot of options. But I just wanted to mention that you should only make stuff dynamic that needs to be. When stuff can be hard coded in a template file, it consumes fewer resources. So if you stick to a policy of hard coding stuff that changes rarely and doesn't need to be dynamic, then you'll benefit from better performance, use less energy, save more trees, etc.

I just committed an update that adds counts of abandoned and blank translations with each file (when applicable). You'll see this if you pull in the latest commit, and a screenshot is also attached. I was worried about the overhead/slowness of parsing all those files on every page load. However, I went ahead and tested it anyway. I was surprised not to see any apparent slowdown – it seems quite fast. It is doing some heavy lifting, but apparently not the scale of issue that I thought. Maybe that will change once we get lots more files in there, but for the moment it seems to be fine. Let me know if you experience something different. I will probably add a caching mechanism if it becomes slow.

I definitely like the idea, but don't think I could make it scalable from a development standpoint. It's a rather heavyweight process to parse all the files to detect these things. Once we get to having a hundred translation files in there, I don't think everyone would want to wait 20 seconds for it to parse everything every time the language page loads. I may have to take a LazyCron approach with this to let it do the heavy lifting behind the scenes when you aren't looking. I will plan to do this. I may not be able to cover 100% of everything (like getModuleInfo title/summary fields), but will find out as I do it. My favorite Finnish city today is Turku I watched a TV show last night about the big ships they build there at the Aker (STX) shipyard, amazing projects!

Whenever you click 'edit' for a translation file, it identifies any translations that are no longer current at the top. It refers to them as 'Abandoned Translations' because the original English translation has changed. See the attached screenshot for an example of what I mean. It shows that the original field that was previously worded "Hello, how are you doing?", has been changed to "Greetings, how are you doing?". The field has been blanked, and the translation has been moved to become an Abandoned Translation. We can't make guesses about the scope of the change, so the system has to abandon the translation and let the translator decide what to do with it. The translator may decide that the change is insignificant, and they can just copy/paste their abandoned translation back into the field. Or they may decide to delete the abandoned translation and perform an entirely new translation. If new phrases are added that weren't previously there, then they just show up as new/blank fields to be translated. I maybe able to call these out in some way more prominently too.

Darn, I thought you'd found it. And I think you have, but looks like we can't take advantage of it just yet. At least not with that particular option. It sounds like most agree that it's best to provide the option for everything to be translatable, but don't require everything to be translated. That's pretty much the way it's setup now, except that I haven't yet made those other modules translatable... I will plan to do it. I want to mention that PW doesn't actually require any language files to run. The language in the code is assumed to be English, and the phrases that appear in the code are the English translation. Those English translations are hashed (md5) and then serve as the tokens for all other translations. So it's reasonably easy for us to make something translatable, even if there aren't any translations available for it. The English language you see in the Languages list right now is actually just a placeholder for the language already present in the code. But you could make your own English translation (if you wanted to) just by adding files to it. The good news is that it really doesn't make module development more difficult. The essence of it is that you just have to wrap your text phrases in a function call, so that $value = "text"; becomes: $value = $this->_("text"); The Wordpress i18n documentation will be our starting point for the documentation (assuming it's open source, I think it is) and I'll modify it to be ProcessWire specific and call out any differences. Once your module is sending its text through $this->_('text'), if you want to add a translation to another language, you just go to Setup > Languages > [any language] > files > new, and then type in the path to the file. I'm guessing that some module developers will choose to include json translation files of their module, and some won't. For those that do, one would just upload that json file to their target language in PW and the given module would translate.

Looking good Soma! Just made those changed and tested it out. Very cool. A couple things I found: It reported 0 results for me until I selected another template, and then changed it again to select 'Show All'– then it worked. In your find() code in the module, you could replace it with this and it would give the same result but be a little faster/more efficient: $pa = $this->pages->find($selector); $total = $pa->getTotal();

I think direct access is kind of assumed, just because you'll see it in nearly any code example you come across for ProcessWire. But maybe it wouldn't hurt to add it, as it's only 2 short lines (see below). But I'm happy either way. <?php $value = $page->any_field; // same as $page->get('any_field'); $page->any_field = $value; // same as $page->set('any_field', $value);

This is great, thanks Jasper! Question for you guys: how far should we take the translations? Do you want the other parts of PW admin included in translations like: Setup > Fields Setup > Templates Setup > Languages Modules Access Or is it better to just keep the basics translated, like the things we would have our clients use? Basically, I want to keep the scope of it small enough that people can add languages really easily. Also want some flexibility to keep adding improvements in the Setup sections without creating work for translators every time I add/update something. But maybe that's just the nature of it. There is potentially a large amount of translatable text, especially in the Setup sections (Fields/Templates). I'm just trying to determine if these parts should be included in the translations or not.

I agree, I think this looks like a great addon to the datepicker. If anyone is interested in implementing this, please go ahead and let me know how I can help. If not, I will plan to implement as soon as there's time to do it.

Thanks, just added my modules to this too.

Statestreet, I just realized I didn't have this on GitHub, so I posted it to there, just in case you've got an earlier version. Here is the version that I am currently using on processwire.com for the Twitter feed that appears throughout the site: https://github.com/ryancramerdesign/MarkupTwitterFeed I'm wondering if your PHP might have allow_url_fopen disabled? You can find out by looking at your phpinfo(), i.e. put this on your server in a PHP file (like test.php) and load in your browser: <?php phpinfo(); I am guessing that you might have the allow_url_fopen option disabled, and that would prevent this module from being able to load the RSS feed. If you find that the option is enabled, then next check your Twitter RSS URL. Logout of Twitter and see if it still works? If I recall, some of Twitter's RSS feeds don't work unless you are logged in with the same browser you are retrieving them from, and you may have to enable access to it somewhere in your Twitter settings... it's been awhile since I've looked at this, so not positive what the current deal is there. But something to look at. Please let me know what you find.

Looking fantastic Soma!! You went further with the number of items hidden in 'advanced' than I was originally thinking, but now that I see it, I like it, and it makes sense. Creating, modifying and saving items really is more of an advanced thing, so I think your selection of what should go where is very well crafted. When in 'simple' mode: what do you think about all the sections that have advanced items ending with a tiny 'more' link or something like that? That way, one could look at all the $page options (for instance) without expanding all the advanced options for everything else. It would also make it clear that there is more depth to the cheatsheet for someone that might miss, or not understand what the 'advanced' option is at the top. I'm thinking these options below might fit better under 'advanced'? $page $page->next; (because one has to be careful with next/prev and large groups of pages) $page->prev; $page->next(); $page->prev(); $page->setOutputFormatting(); WireArray $a->getArray() (because rarely used) $a->getKeys() $a->getValues() Selectors: start=n (used more by system than user) end=n (rarely used) include=all include=hidden check_access=0 children.count=n created=timestamp (because these were advanced in $page section) modified=timestamp created_users_id=int modified_users_id=int $user $user->pass (because only useful for setting value) $input $input->get["name"] (because no need to list 3 ways of same thing in 'simple' mode) $input->post["name"] $input->cookie["name"] $session $session->getAll() (because rarely used) Lastly, what do you think about having the direct access get/set mentioned in $page like it is in $session? Maybe people already assume this, but I wasn't sure. $session->$name = $value $value = $session->$name

Thanks Soma, I tried to install and test this. While I can't get the module itself to work yet (getting some errors) I am seeing the proper load order for it's js file when viewing the 'data tables' page and looking at the source. I am wondering if this module ever had autoload enabled? The autoload setting in PW's modules table will be according to what it was at the time of installation. So if it was autoload at one time and you changed it, PW might not realize it's no longer autoload. If you view the modules table in the DB (via PhpMyAdmin) or the like, and locate the ProcessDataTable in there, what does it have for the 'flags' column? It should be a '1'. If it's a '2' or a '3', then it's autoload. If that's the case, try changing it to a '1' manually, or just uninstall and re-install the module from PW admin. Let me know what you find here...

You caught me! ;D Just checked, and you are right it looks like the files do not show as UTF-8 when I load them in my text editor (mine show Mac OS roman encoding). I don't really know why because they are saved with nothing but PHP's file_get_contents() and the data in there is UTF-8. I'm guessing the file has no explicit encoding and it's just showing up as whatever is one's editor default (?). I suppose it doesn't really matter if one doesn't need to load the JSON file in a separate editor, but would like them to be explicit about the encoding if possible–just not yet sure how. The only thing I can find in the file_put_contents user comments at php.net (for "utf") is this: <?php $myFile = 'test.txt'; $myContent = 'I love PHP'; file_put_contents($myFile, utf8_encode($myContent)); But that doesn't really help us, because utf8_encode() is for converting ISO-8859-1 encoding to UTF-8, and we're dealing with text that is already UTF-8 encoded.

If I understand correctly, you want the code snippet you pasted to appear at some place in your bodycopy that you designated. This is something that I do regularly with both images and fields. I tell the client to type either the word "images" or "files" in it's own paragraph with nothing else, and then all of their files or images will appear there in the right order with description, etc.. Here's the code I use to do it: <?php function bodytext($text, $page) { if(strpos($text, '<p>files</p>') !== false) { $out = ''; foreach($page->files as $file) { $out .= "<p><a class='file file_{$file->ext}' href='{$file->url}'>{$file->description}</a></p>"; } $text = str_replace('<p>files</p>', $out, $text); } if(strpos($text, '<p>images</p>') !== false) { $out = ''; foreach($page->images as $image) { // make the image small enough to fit bodycopy column, if it's too big if($image->width > 500) $image = $image->width(500); $out .= "<p><img src='{$image->url}' alt='{$image->description}' /><br />{$image->description}</p>"; } $text = str_replace('<p>images</p>', $out, $text); } return $text; } ?> <!-- later on in your code when you output the bodycopy --> <div id='bodycopy'> <?php echo bodytext($page->body, $page); ?> </div> I've done this on a couple sites now, and am thinking I should just make it a Textformatter plugin or something.

I've tried to duplicate here this morning, but still can't. Can you tell me if I'm missing any parts necessary to duplicate? Here's what I did: Copy the code you pasted to create ProcessDataTable.module, and also created an associated ProcessDataTable.js file with this: $(document).ready(function() { alert('test'); }); Then I put those two files in this directory: /site/modules/ProcessDataTable/ I installed from the Modules menu. Then I went and created this page in the admin: /processwire/test/. I select ProcessDataTable for the 'process' field of that page and save. Now I have a 'test' menu item in my admin top nav. If I click that page, I get the test alert. If I view the source, I see ProcessDataTable.js loading after JqueryCore and JqueryUI, as they are supposed to. Are there any parts I'm missing? For instance, I'm using the default admin theme. Do I need to install a different admin theme to duplicate? Is it possible there is some other autoload module calling upon ProcessDataTable in your case? Thanks, Ryan