ryan

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");

Found it--it was a bug. Sorry for the inconvenience guys. This is one of those obscure bugs that takes the right set of circumstances to turn up, so these can be difficult to track down. Thanks for finding it. I've just committed the fix to the dev branch, and it should be merged into the stable branch likely tomorrow. Here's the commit message:

Pete, try adding an extra line to your install function: wire('modules')->get('MarkupCache'); That will just ensure that it's installed ahead of time and should resolve the problem in this particular case. However, I don't think there is a problem with your code, I think it's actually a bug with the MarkupCache module (or maybe Module installer) because the MarkupCache module is responsible for making sure it's files go into the right place, and clearly it's not doing that. I will locate and fix the issue. I was able to reproduce it here by uninstalling the MarkupCache module and then letting it be installed at the time it's used. That seems to be the only time the issue occurs.

Your display_options in the selector needs one of the following: The literal $page object for page 'not-shown-on-front-page' The full path to the page you are trying to match The ID of the page you are trying to match As a result, I'm thinking you'd want to do this (use the path rather than the name): $stores = $pages->get('/news/co-op-news')->children('limit=4, display_options!=/tools/display-options/not-shown-on-front-page'); If you aren't going to have a ton of display_options, you might also want to consider just using single checkbox fields for these, in which case you could just do this: not_shown_on_front_page=0

Welcome Raydale and thanks for using ProcessWire and joining the forums. I'm late to this conversation--just arrived back in town after being gone for a couple of days. I think Pete and Apeisa replied better than I could have, and just wanted to say we're glad to have you here and look forward to talking more.

Nico, this is something that is technically possible with the way the hook system is designed, but I've not implemented it yet. The idea behind it was that there would be a 'replace' hook, where you can have your own function completely replace the functionality of a core function, so that the core one is never called. I haven't implemented this because it's not so friendly in an environment where there may be multiple modules hooked to a given function. If one module completely takes over a core function, it alters program flow and the behavior that other modules may be expecting. So I've left it out because I think it's a bit too unpredictable, though may still add it in if there's interest. However, you can achieve the same effect by using an 'after' hook and completely replacing the $event->return value with your own. Not as efficient as replacing the execution too, but much more predictable.

Rob, I think that's a difficult question to answer without knowing what you are going to be using the images for? Because I think the approach would depend on the eventual intention and use for those images. I don't see any scalability problems with #1. But you are right that it won't be as simple to upload images as it is with a multi-image field. Though it would be fairly simple to build a module (or even a template) that takes all the images from one page and turns them each into their own page. For #3, here's an example of taking the image field and making a new one that has custom fields attached to it: You are right though that once you've got hundreds of images in there, that might be a little difficult to administer as these things are not paginated in the admin (though not an an issue from API usage).

This sounds awesome Pete, I can't wait to try it out along with the other stuff you sent me today. It seems like every time I have to take a few days away from the computer, all the coolest stuff gets released

Thanks slkwrm, glad you like the new setup. Pete did a nice job getting it going. Congratulations on the new job!

Make that early next week instead. I was going to merge the branches today, but then realized I'm not likely to get much time on the computer this weekend and want to make sure I'm close by to assist with any upgrade issues. Though, I don't think there will be any issues, but just like to be available. So will probably merge Monday or Tuesday.