adrian

# Block access to any PHP or markup files in /site/templates/ RewriteCond %{REQUEST_URI} (^|/)(site|site-[^/]+)/templates($|/|/.*\.(php|html?|tpl|inc))$ [OR] You can't link directly to php, html, tpl, or inc files in the templates directory, or its subfolders. You'll need to place them somewhere else!

Well the SQL command for basic replaces of the "body" field would go something like this: UPDATE field_body SET data = REPLACE( data, 'search_word','replacement_word' ) The key thing for me when using the PW API is to limit it to just the fields and pages with matching results, rather than iterating and saving every field on every page on the site.

You can delete any module manually - just use something like PHPMyAdmin and browse/search the "modules" database table and remove the row for the module. Then remove the module folder from the server and you should be good. In the case of this module, there are also some additional db tables to remove, prefixed with "version_control", but be careful to remove the ones for the version of version control that you want to remove. Also, note that Version Control supersedes Version Control for Textfields. The latter is only still around for older versions of PW.

Absolutely and I have done that several times in the past, but I want to create a tool that can be used by your clients for site maintenance.

Hey Pete - nice one! I know your code is meant as a quick snippet to get the job done, so no offense intended, but the concerns I have with this is: On a site with a LOT of pages, that could be very slow. I don't like the fact that it re-saves every page, regardless of whether there is a change or not, which will affect the modified date and modified user. I have actually already made a start on a feature rich search and replace module which I will get around to finishing up sometime soon. It provides the ability for searching and then showing the search term in context for each match. You can then choose which matches get replaced, or replace all. Stay tuned!

Not sure why this hasn't been mentioned, so I am wondering if I am missing something relevant, but why not use the $template->noSettings option? Do you need to hide on a page basis, rather than per template? Anyway, if it suits your needs, turn on advanced mode in your config.php file and then you will have a Disable Settings Tab? option on the Template's System Tab. Hope that might help.

@sgt.blikey - I am glad you like it. I have put together a fix for supporting repeaters - please let me know if it works for you as expected. If anyone sees any issues with normal Table fields (not in repeaters), with this new version, please let me know! Even though I just added support for repeaters, I want to make sure you have you read this thread: https://processwire.com/talk/topic/8832-error-in-complex-form/ - it is in the Profields support board, but I am assuming you have access. In particular read the post by Ryan where he says that Tables in Repeaters are not officially supported, although he does say that if they were working and now aren't, he'd consider investigating. Mostly just wanted to warn you that maybe you will run into other issues with this approach. Have you considered switching to PageTables or even simple child pages and putting your Table field in those?

What apeisa said, but that error makes me think you've got something incorrect in your Details > Select Options textarea because $value is not being set. The only way I can make that happen is to have more than one ":=" on a row. Of course the module should have a better check on this, but I still think you might have something incorrectly configured. EDIT - I see you found your error

I think I am maybe confused, but shouldn't it behave like other PW muilti fieldtypes. That is, you should be able to do: foreach ($page->selectextoption as $selectedoption) { echo $selectedoption->id //returns 1 echo $selectedoption->name // returns title } //OR $page->selectedoption->first()->id I don't really understand why you need to look up $data['29']. I am assuming 29 is the integer that has been stored and is what $page->selectextoption would currently return if using a single select field. In the case of a single one you would just return the corresponding db fields as properties of the field, like my example a couple of posts above. If it's a multi-select field, then it should return an array of results that you can foreach through or grab a specific index (first, eq, last). Am I missing something?

Hey kixe - thanks for making progress on this. Maybe my example was confusing? When I wrote: $page->selectextoption, the "selectextoption" in my example is the name of my field. I am not sure how your new code works, and I don't have much time today, but perhaps you can get some ideas from: https://github.com/somatonic/FieldtypeDimension/blob/master/FieldtypeDimension.module or https://github.com/adrianbj/FieldtypePhone/blob/master/FieldtypePhone.module or ProFields Table if you have access to it. Then again it's early here and I need to get back to work so maybe I am not sure exactly how your new setup works.

This bug was recently introduced, and just fixed today in the dev version - please check it out and report here: https://github.com/ryancramerdesign/ProcessWire/issues/1014 if you still have any trouble. PS Welcome to PW!

What version of PW are you running? Are you sure all files copied across fully? Perhaps it would be worth installing a fresh copy of PW on that new server and see if you get any problems, then copy in your existing site folder.

Maybe add your comment here: https://github.com/ryancramerdesign/ProcessWire/issues/1014

I havcen't used the MobileDetect module, but I think the first step here is to get to back into the PW admin, so I would recommend deleting the site/modules/MobileDetect folder and then going into PHPMyAdmin and deleting the row from the modules table that is for this module. Then if that is working, then maybe you can try installing the module again.

Yep - I see that it totally works with PW tables. Thanks for looking into an option for non PW tables. I am actually wondering if you might be able to do something like: $page->selectextoption->db_field_name and be able to return the value from any field (column) for the row that contains the selected integer ID value? This could work with both PW and non PW tables. Some examples of what you could return with this. PW fields table: $page->selectextoption->id = 1 $page->selectextoption->name = title $page->selectextoption->label = Title $page->selectextoption->flags = 13 a non PW table (maybe a list of country codes): $page->selectextoption->num_code = 276 $page->selectextoption->iso3 = DEU $page->selectextoption->name = Germany I think this would be much more powerful than just returning the value and label fields. I think it might also be nice to be able to magically return the selected value and label without knowing what the fields are, so: $page->selectextoption = 1 $page->selectextoption->selectedLabel = Title (assuming the field I chose for the label was the title field) Of course you can't use "Label" in this last example because "Label" is a field name in some PW tables, hence my use of "selectedLabel", but there might be a better option. Does that make sense? Thanks for your hard work on this - it's going to be very useful!

I know this is a very late followup, but I recently posted an alternative over here: https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=89599 and https://processwire.com/talk/topic/1716-integrating-a-member-visitor-login-form/?p=89616 Pros and cons to each version, so you should read all the posts in between as well. Personally I would go with the second one, just be aware that if you want it to work on the front-end you need to consider the name of your form fields.

Now another new notice: Notice: Undefined index: option_table in /site/modules/FieldtypeSelectExtOption/FieldtypeSelectExtOption.module on line 145 You really need to turn on debug mode, or at least check your php error log I see why you went with integers for the value - it makes sense to stay with the schema of FieldtypeMulti - I hadn't thought of that. But when using a non-PW DB table, when outputting the label of the selected value on the front end of your website, how are you going to get the value you want to display? This will require an SQL query to retrieve, right? For some devs this is no problem, but for others it may be too technical. Do you think you could include a method for rendering the label on the front end, based on the stored value? I am thinking that you should be able to do: echo $page->selectextoption; and get the label of the selected value, rather than the stored value. What do you think?

That suggest to me that 105 is maybe missing a semi-colon at the end of it. But I am sure you haven't edited that file. What happens if you replace it with an original version of the index.php file?

Here is something I hacked together quickly for automatically adding new child pages to the pagetable field. This is only if you are using the page as the parent. It also handles deletion of items if they are trashed externally. I also disabled the internal check for orphans - because they have been automatically added already, there is no need for the "Children were found that may be added to this table. Check the box next to any you would like to add." option. I seems to be working great here, but please test carefully!! Add this to your admin.php file: wire()->addHookBefore('InputfieldPageTable::render', function($event) { $pp = wire('pages')->get(wire('input')->get->id); $ptf = $event->object; //remove pages from pagetable field if they were externally trashed foreach($pp->{$ptf->name} as $item) { if($item->is(Page::statusTrash)) $pp->{$ptf->name}->remove($item); } //add pages to pagetable field if they were created externally foreach($pp->children as $child) { if(!$ptf->has($child->id)) { $pp->{$ptf->name}->add($child); $pp->of(false); $pp->save($ptf->name); } } //reset orphans property so that we don't get a message asking to add new pages that are now already automatically added $ptf->setOrphans(new pageArray()); });

PageLinkAbstractor has been deprecated (Ryan has removed it from the modules directory). The core PagePathHistory is his preferred approach to dealing with changed URLs now.

Awesome enhancements - this is very cool! Still getting one notice: Notice: Undefined variable: v in /site/modules/FieldtypeSelectExtOption/FieldtypeSelectExtOption.module on line 109 Can I make one suggestion - if the option label field is blank, could the label use the value field? PS Is there any reason for the "type (int)" part of this description "Choose a column of type (int)." ? Why can't I use a text field? I am guessing it is just suggestion, and while it is generally a good idea, there are often reasons this is not convenient.

You should also check out Bea's new module - it is much more powerful and stable than the one I mentioned above and I think would be a great fit for your needs: https://github.com/justonestep/processwire-imageextra

That fixed it! Everything seems to be working again now - just a pesky notice: Notice: Object of class WireArray could not be converted to int in /site/modules/FieldtypeSelectExtOption/FieldtypeSelectExtOption.module on line 105

Well you could create a new Pageimage from the image path: $image = new Pageimage($page->images, "/path/to/image.jpg"); Then you could run sizer on the page image. Then delete the pageimage if you want. I think something like that should work. Either that, or just use standard GD commands.

Assuming BitPoet is correct and that is your problem, then it should work after that. Nothing wrong with doing it manually obviously, but just an FYI - there is a module for grabbing video images from YouTube/Vimeo and populating an images field, along with descriptions: https://processwire.com/talk/topic/4614-youtube-and-vimeo-thumbnail-grabber/