ryan

This is the method that I use and find it really handy. The main.php file for processwire.com has this at the top: if(strpos($page->body, '<p>https://www.youtube.com') !== false) { $replacement = '<iframe width="640" height="360" src="https://www.youtube.com/embed/$1" frameborder="0" allowfullscreen></iframe>'; $page->body = preg_replace('#<p>\s*https://www.youtube.com/watch\?v=([^\s&<]+).*?</p>#iu', $replacement, $page->body); }

The FieldtypeFieldset* fields behave differently than the rest. This is a detail we should probably look for and answer in the field cloning, so glad you found that. Though also want to mention that you can use any FieldTypeFieldsetClose field to close any FieldtypeFieldsetOpen, they don't necessarily have to be matched in name... but it helps just to keep things organized.

Svet, apologies this message didn't show up in my new content list for some reason (I'm still learning the ropes of IP.Board). There are a couple of different approach you could take with this: 1. Let 1 textarea called 'quotes' serve the need instead. Use a regular textarea field (not TinyMCE) and enter each quote on it's own line. $quotes = implode("\n", $page->quotes); The quotes are now in an array called $quotes. You can iterate that array or pluck one randomly like you would if they had started in separate fields. 2. Or, you can create a 'quote' template and use a separate page for each quote. This is probably the approach I would take. You can select, iterate or pluck them randomly like you can with any other pages. For instance, if you wanted to output a random quote: $quote = $pages->get("parent=/tools/quotes/, sort=random"); echo $quote->body; Please let me know if I can provide additional examples.

There shouldn't be any overhead with using the multisite feature. All it's doing is checking $_SERVER['HTTP_HOST'] to determine what /site/ directory it should use, and that doesn't represent any overhead. I'm not sure I understand. Are you saying that something is not working how it should, or that restarting the server fixed it? B)

Nico, we can't put those in like that just because they translate differently into other languages. We actually did originally, but then learned that it was producing an incorrect translation in Finnish and Russian. However, you can configure how you want these translated in Modules > Inputfield > InputfieldPageName

Looks like I forgot to remove a line in the code. You are right, it wasn't working. Sorry about that. Grab the latest /index.php and try again and it should work. Thanks, Ryan

Diogo, a couple things to check: Make sure that your /index.php and /.htaccess files are both brand new from PW 2.2. Next, I suggesting adding both 'www.mydomain.com' and 'mydomain.com' to both go to /site-testing/. Lastly, if /site-testing/ is just a copy of your /site/ dir, then make sure you've updated something in your /site/templates/ to reflect that, so that you can tell the difference. For instance, have /site-testing/home.php have something like "echo "<h1>Site-testing</h1>";

I just downloaded a fresh/blank copy of PW 2.2 and installed this module just to make sure it didn't have anything to do with the dev site I had tested on before. But it's working as expected, creating the dir in the right place, etc. So there must be something else that I'm missing. The behavior you are describing definitely indicates a core bug. I can't think of any other possibility. I'm going to do more testing here and hope to find and push a solution shortly.

I was planning to keep it in P21, but of course the name is no longer reflective of the version. I think that others do it by just keeping their original one, like ProcessWire (rather than P21). This comes from me being a Git newbie, I didn't know how to use branches when I started. But now we've got all of our "watchers" on P21, and I'd hate to lose them. So not exactly sure what to do? But perhaps we'll take over the ProcessWire repo once again with v2.2.

Can you confirm that you still get this same error message and that your ProcessWire reports it's version number as 2.2? thanks, Ryan

Great ideas, keep it up! I'm planning to use this SocialTwitter module on the new PW site so that every time a new module or site is added, it'll automatically post to the Twitter feed. This is going to be a big time saver.

The one I was testing with did have 2 TinyMCE fields (body and sidebar). Just went back and tested again, trying to reproduce in both of them, but no luck. I am running 2.2, which uses a newer version of TinyMCE than 2.1. I'm wondering if this issue might already be resolved in 2.2 by that update? Let me know if you have a chance to try this with the latest version and if it still occurs? Thanks, Ryan

I understand -- I think that's a good reason for us to add a replace hook. For my own testing when implementing this, can you tell me which function it is that you are hooking into?

Tested here too and it uploaded just fine. At just under 2 megabytes, I doubt you are hitting a server size limit, but it's something to look at if smaller images upload without a problem. What version of Firefox are you using and have you tried in any other browsers? Do you have any 'max dimensions' set in your image field?

Spamec, create a template with your repeatable fields. Then create a new page as a child page (or somewhere else like /tools/slides/ as a parent) that uses your new template for each repetition that you need. You end up with a new page for each repeatable group of fields. This is the way ProcessWire is designed to work with the type of content you are talking about. The method Apeisa mentioned (/tools/slides/) is the same one I use with this particular need. When we add a more formal definition of repeatable fields, they will likely use the same method but just hide the details of the implementation.

Just want to clarify that the problem is not with Pete's module. There was an obscure problem with the modules installer in the core which has been fixed. I'm not certain this is the problem in your case as you are still getting a different behavior than us, but I suggest grabbing the latest copy of ProcessWire before trying anything else.

I've merged the 2.2 dev branch into the 2.1 master branch, making 2.2 the current stable version. I've been switching my own sites between the two branches for weeks without issue, and I've not had any reports from others about compatibility issues, so believe it's safe to merge. However, there are a lot of changes between the two so use caution when pulling in the latest commit. By that I mean backup and test everything out to ensure all still works as expected. Of course, this is something you should always do, but especially so in this case (it merged more than 50 commits from the dev branch). Language Support The LanguageSupport modules are now included in the ProcessWire stable branch, but they are uninstalled by default. These LanguageSupport modules are still considered beta, as I think we need more people using and testing them before we can consider them non-beta. To install them, just click "install" on the LanguageSupport module in your Admin > Modules. It will install everything else. You can also uninstall the LanguageSupport modules just as easily as installing them by just uninstalling the LanguageSupport module (and it will uninstall the rest). I will be adding a Language Packs section to the Download page soon. Thanks to all those that have helped with making translations. In the coming weeks, we will also be making more and more of the core modules translatable, so we'll need continued help from our translators. Special thanks to Avoine (http://avoine.fi) for being a sponsor of ProcessWire 2.2. You will see their name start to appear elsewhere on the site as a thanks for them helping to make the Language Support possible in ProcessWire. Other changes The LanguageSupport modules are the major drive of this version. However, there are several other changes and additions, including: Add module dependencies support. Add module auto install and uninstall support, to correspond with dependencies. Add 'page-create' permission to Setup > Templates > Template > Access. Update to latest version of TinyMCE (3.4.7) Add new Page Clone module to core (may be installed from Admin > Modules) Update error log file to include hostname. Made tab delimited rather than colon delimited. Added built-in multi-site/multi-domain support optiona via config file /wire/config.index.php Addition of several new hooks, especially in the $pages API var and files Inputfield. Add new 'Site' link in default admin theme. Numerous other bug fixes and optimizations, see the commit log for details. Upgrading an existing installation There is no formal upgrade process for going from ProcessWire 2.1 to 2.2, so all you need to do is pull in the latest commit (when you have time to adequately test it). If you aren't tracking the source on GitHub, then you'll want to download the latest ZIP and then do the following: Replace your existing /wire/ directory with the new one in the ZIP. Replace your existing /index.php with the new one in the ZIP. Replace your existing /.htaccess file with the htaccess.txt file included in the ZIP. That's all you need to do. However, I suggest renaming or backing up your existing /wire/, /index.php and /.htaccess files just in case you need to revert for any reason. This is standard procedure with any upgrade. Please let me know how everything works for you. After installing, there is one change that may affect you if you are using multiple non-superuser roles with page edit access. A user must now have page-create permission on a Template in order to create a new page that uses that template. You'll see this setting on any template that is defining access, on its access tab. So if you have non-superuser roles with edit access, go in and add that page-create permission for any templates that they should be allowed to create new pages from.

I do need to make a follow-up tutorial, and am planning on it. I think the best next-step in the documentation would be to read these, in this order: http://processwire.com/api/templates/ http://processwire.com/api/selectors/ http://processwire.com/api/variables/pages/ http://processwire.com/api/variables/page/

Nico, Transpix -- it's correct that you don't need the save() if you are already using $pages->trash($page). that's because the trash() function already performs the save for you.

Pete I was able to test this out today, and really impressed with what you've put together here. Quite a lot of work went into this, and it looks like you've done a great job with the code and functionality here. I signed up for the Twitter dev account and plugged everything in, but unfortunately wasn't able to make it work because my dev server isn't accessible to Twitter. However, I was able to get a good understanding of how it works and what the possibilities are here and it's quite exciting. I've already got a plan to use this with an upcoming client project, and this is going to be perfect for them. The code looks great here. The only suggestion I could come up with was to try out your module config screen with $config->debug enabled. It looks like there are a couple initialized variables (line 111, 115 and 121). Minor issue, but just wanted to mention it since it causes error messages to appear when debug mode is on. This is my first experience with the Twitter API and I must say I really like it and what you've implemented here. Nice work.

Moved to pub since this isn't PW specific (?). But that particular image is CMYK (rather than RGB) and 1.562 DPI rather than 72. I'm definitely not surprised that IE won't display it. Here it is converted to RGB and 72 DPI (and 33k rather than 670k)

Beautiful site Diogo! If the PW admin is also slow, then that means it's not likely any issue with your template code or anything like that. (Unless you've got some hefty autoloading modules, which would run on both the front-and-back end, but I'm guessing this is not the case). I would look at the web host. I'm guessing their MySQL server or web server is either overloaded or underpowered. If this is a budget hosting account, there may be some intentional bottlenecks in there to keep things throttled.

Soma, I've tried several times to reproduce it but can't. Are there any other factors you can think of? Can you paste in the exact text / context where it's occurring and steps to reproduce? Here's what I tried: 1. Enter some text in the body field, like: test test 123 test test 2. Highlight a word (like the second 'test') and then click link icon. 3. Type in a URL, I did http://processwire.com, and click "insert link". 4. Back in 'body' field, click the link and then click the link icon again to edit the link. 5. Type in a new URL (also tried leaving as-is) and click "insert link" again (also tried "cancel"). 6. Click the "HTML" icon to look for extra <a> tags, none found. Testing in Firefox 8, ProcessWire dev, OS X.

Pete, if I'm understanding correctly, I think you can just make the module an 'autoload' module. Then ProcessWire will include it automatically at runtime. If you want to bake in some functions or instantiate some objects, just do it outside of your module's class, but in the same file (or have your autoload module include the file that they are in, in it's init() method). If you want to add a new API variable that will be sent to all the templates, you can do this in your .module file, outside of the class: $myvar = 'string, object, or whatever you want'; Wire::setFuel('myvar', $myvar); Then all your templates will have that $myvar variable and your modules will be able to access it from $this->myvar or wire('myvar');

Another route is to have your calendar template add it to some existing field that gets output in the main template, like $page->body: /site/templates/calendar.php <?php $page->body .= "<iframe ...>"; include("./main.php");