teppo

@adrian: I must admit that your approach is unique, to say the least. I've never really seen domdocument in action, so this is quite fascinating For a slightly different approach I've just pushed an old textformatter module I never ended up using or completely finishing (JS approach felt better after all) to GitHub: https://github.com/teppokoivula/TextformatterImageWrapper. This was intended just for wrapping images with a div element to enable more flexible styling, but also has an option for appending the description within said wrapper (which seems to be the topic of discussion here.) It's very much a work in progress / beta / proof of concept, but should be fully functional already

First thing you should always do when having problems is checking your error logs, both for PW (site/assets/logs/errors.txt) and Apache (usually /var/log/apache2/error.log.) Does anything show up there when this error occurs?

This won't help much with your current issue, but I've just pushed new version of this module to GitHub. This version adds an option to log which script triggered (ie. initiated) each action; a path or an URL, depending whether context was HTTP or non-HTTP. This feature can be enabled via settings of Process Changelog Hooks module to either external scripts only or both external and local scripts (ie. current PW installation called in "normal way" -- bootstrap method is considered "external.") Haven't been able to test it thoroughly enough yet, but so far it seems to work. If anyone has time to test this, I'd love to get some feedback.

Most of default content points (created_users_id DB field in pages table) to page ID 2, which is the /processwire/ page. This seems like a sensible solution to me.. even though /processwire/ obviously isn't real "user" either Edit: taking another look at that quote, I'd like to add that having user specific to bootstrapped scripts would be great. At least for those of us who use these quite a lot, it would help keeping track of things.

Some people probably prefer to have more (and more specific) field types, while others (like me) prefer more basic building blocks that can be combined on case-by-case basis to make hyperlinks or whatever else is needed. Repeaters are a great way to achieve this.

@NoDice: this sounds like a perfect match for repeaters. First you'll create the fields you need; one URL field for link href ("link"), one text (or textarea, if you need longer texts) for your description texts ("description") and one image field for your slideshow images ("image", limited to one image per field).. and also one repeater field (let's call it "slideshow" for this example) that you'll configure to hold all the fields mentioned here. After that you'll insert the code, which would work just as @diogo mentioned earlier: <?php if (count($page->slideshow)) { echo "<ul>"; foreach ($page->slideshow as $item) { $thumb = $item->image->size(600,250); echo "<li style='background-image: url({$thumb->url})'><a href='{$item->link}'>{$item->description}</a></li>"; } echo "</ul>"; } ?> I'm making some assumptions about what the markup for your slideshow is like, don't worry about that; you should be quite easily able to adapt above example for your specific needs.

@ceberlin: did couple of quick tests and it definitely looks like a) actions ran through Batcher get correctly logged as actions of the user that ran them and b) API actions via bootstrap method always point to Guest user. In your case I'd keep looking for an external script that bootstraps PW and does some changes OR template code that alters content when a visitor loads a page with that template. Front-end edit forms would be potential causes for this too. I have to agree that actions of API pointing to Guest is confusing, but as it's internal PW feature I prefer to keep it like that here too. Reasoning behind this seems to be that when doing something via API, whether triggered by unauthenticated visitor or some external script, you don't actually log in as any real user .. so the real issue here is probably just that "Guest" sounds very odd in this context.

Sorry Adam, I've completely managed to miss this post! And thanks, by the way -- it's good to hear that someone has found this module useful This is a bit late for a reply, but anyway: I wouldn't be too worried about performance impact. There's no heavy lifting happening code-wise, just some hook methods with a bit of relatively simple logic. One extra query (most of the time) for each page save shouldn't do much harm either and since this only happens when saving pages it's definitely not a problem on most pages. On the other hand, if you do find that there's some kind of performance penalty, I'd be happy to check it out and see if things can be further optimized. (I'm sure they can, just haven't found a reason to do that so far.) Only case where I would worry a bit about things getting out of hand would be a site where pages are constantly changed (ie. some public feature triggers page save all the time) and that data gets logged. In a case like that it would make sense to a) not log every action and/or b) limit the time log entries are stored for. I could also add a template setting at some point, so that admin can select which templates require logging in the first place..

Most likely either API usage, or perhaps some internal PW feature.. for these user seems to be "guest", which is a bit confusing to say the least If you're sure that neither of these were the cause, then I'd love to dig in a bit deeper. These are the cases that have triggered changes by "guest" for me in the past.

You probably mean stop words? Seems like a reasonable feature to me, especially if made configurable (as English stop words make very little sense / are sometimes even harmful for a site written in Finnish etc.) Just saying.

I agree with you in that having a text would be standard behavior -- for HTML hyperlink. It's very important to note that HTML hyperlinks created using the "a" element are separate entities from URLs. There are many use cases for an URL, so it wouldn't really make much sense to add an option for additional content that's related to only one of those. Repeater method described by @diogo is probably the best way to put things like these together. Another method (probably overkill for most use cases) would be creating a new fieldtype + inputfield for a hyperlink element. There one would definitely expect to be able to fill in text content (and other parameters too, as described by the HTML language reference I linked to earlier.) I would also like to point out that ProcessWire fields (fieldtypes) very rarely generate any markup. TinyMCE is an input method (inputfield) that generates markup and stores it in textarea fieldtype. Even in that category markup generating inputs are, in my opinion at least, quite rare.

URL field only stores URL's, while what you're talking about here is HTML link tag and it's value. These are different things: http://www.xxyyzz.com is valid URL and thus can be stored in URL field <a href="http://www.xxyyzz.com">The text I want to show in place of the URL</a> is HTML link tag and can't be stored in URL field To achieve what you've described above I would suggest using textarea field with TinyMCE enabled (or without TinyMCE, if you prefer to write your tags as pure HTML yourself.) Other option would be storing URL in an URL field and text within text field -- ie. using two fields and outputting them like this in your template: <a href="<?php echo $page->my_url_field; ?>"><?php echo $page->my_text_field; ?></a> The best solution here, of course, depends a lot on where and how you want to use these values.

@ShaltNot: semicolons are definitely comments in INI files, so altering a setting prefixed with semicolon won't affect anything. Also the setting affecting xdebug, as mentioned above, is actually xdebug.max_nesting_level. I haven't used xdebug myself so I'm not sure if it's settings are in php.ini or somewhere else -- it could have it's own config file too. One more thing to note is that you may have to restart your web server after altering PHP settings. Not 100% sure about this, but as it's a local server that probably won't do much harm either. Anyway, since your issue seems to be fixed, you may not have to worry about these anymore, just wanted to point these out in case that someone else stumbles upon this same issue.

Name approved.

Sometimes a bit of inline CSS is better than a whole lot of other hacks to get past it. One of the discussions I mentioned is this: http://processwire.com/talk/topic/2210-help-getting-a-custom-styles-php-file-working/. In a nutshell you'd have to use a .php file for your CSS and send a header telling browser that it's actually CSS file. Not very difficult, but I'd still avoid it unless it's really necessary. By the way, I replied too hastily (tried and true "reply fast, edit later" strategy) and that code there has a few issues. I've corrected them to my reply above, so you might want to check it out before trying this..

You can't use PHP in CSS files by default. I'm sure you could find some discussions about that from the forums, but for now I'd suggest slightly different approach. Do something like this for the element you want to have a background-image for: <div<?php if ($pages->get("/site-settings/")->background_image) echo " style='background-image: url(" . $pages->get("/site-settings/")->background_image->url . ");'"; ?>> Rest of the settings (background-position, background-repeat, background-color etc.) you can define in your CSS file. This is probably the easiest way to get past this -- it adds a bit of inline style to your markup, but that's a very minor issue here.

I haven't tried your module, but if I remember correctly it had some support for files (pdf, doc) too? If that's really the case, that alone would make it very useful.. and that's definitely what I'd recommend focusing on, as it's pretty damn important for certain sites

@Peter: $field = $fields->get("account_status") returns a field object. This would in turn return field ID when converted to string. This explains the error you're getting: while $new_page->account_status returns field called "account_status" attached to that particular page, $new_page->123 (or whatever the ID of that field is) won't work (fields are called with their names, not ID values) and thus it returns an error when you try to use method "add" of this non-existent object. Am I making any sense here? Anyway, reading you post again, I must admit that I don't really get how your application works. There's just not enough data here, I'm afraid. For an example your first example gets field value from $input->post->$field_name but field name itself ($new_page->$field->...) seems to already exist at that point. This is why I'm having a bit of a hard time understanding the relation between these two code examples.

Just a guess really, but have you tried $new_page->{$field->name}->add( (int) $field_value_id ); ? I'm guessing the problem might be that here your $field is an actual field (object), while what you really want is it's name.

.. or combine above answers to get a method that instantiates and returns your submodule when/if needed: public function submodule() { return wire('modules')->get("myModule2"); } $modules->get("myModule")->submodule()->doSomething();

@kyle: well written and easy to read, thanks for sharing! Two things I'd like to point out: You might want to add some random element to your activation hashes. MD5 is easy to spot and based on that information anyone mischievous enough could easily do things like automated account creation. Not that it would matter in most cases, but if a site using this was going to be in large-scale use then I'd be a bit worried about that. You're using custom methods to sanitize URLs, usernames, hashes etc. Take a look at $sanitizer -- it provides methods for sanitizing PW usernames, text (this should be a good fit for your hash) and even URLs. No need to reinvent the wheel