Thanks for your feedback. An additional wizard for some major tasks will be available in some future version. The question is which tasks are important and mostly used?
Concerning the warning message, this issue has been fixed with version 1.1.5 – automatic recognition of regular expressions is now done via native PHP functions (see preg_match in PHP documentation).
Thank you for improving SSR!
Thread Starter
LMP
(@loizos16673)
Thank you very much for your prompt reply (and fix of the issue). I tested the new version, and it works fine!
Your plugin is essential for bulk-changing things that should actually be available from the normal user interface, such as:
- bulk-changing post dates and other post metadata. WordPress’ bulk change features are extremely limited in that respect
- replacing URLs when moving the WordPress installation to a new host
- selectively replacing URLs, for example when I move a download folder to a new location
- replacing values in custom taxonomies, for example zeroning out the sales counters in e-commerce taxonomies, or bulk-changing prices of a product category
I have tried other solutions to do these tasks, such as PHPmyAdmin and Adminer for WordPress, but they have very primitive command-line based search-replace functions with no preview. And I’m no mood to learn command-line SQL commands.
As for the user interface of SSR, I’d suggest that you make the names of the fields a little more user-friendly, or add some accompanying help text.
For example, you could rename the “Selector” field to “Search for:” and the two “Filter” fields to “Replace this text:” and “With this text:”
That would make it far simpler for novices to understand.
I’d also suggest that you move the fields for saving the search criteria in a new block beneath the search table, and rename the entire thing to “Save search criteria.” And there should be a “Save criteria” button to actually save the search criteria, instead of just a “Simulate” button, which is not clear if it will save the criteria or not.
BTW, I still haven’t figured out what “Block size” does or what “Maximum Execution Time” means. Fortunately, I don’t seem to need them.
The button Simulate will save the database table name, its definition schema, selectors and filters in a DataDefinition file. The already computed changes in the database table are stored in DataBlocks, on a table cell level. Suppose the table filter has been defined in such a way that it actually changes 1400 table cells, and let’s assume that the data block size has been set to 500 previously, then the data definition file consists of 3 links to different data blocks: block #1 contains the first 500 cell changes, #2 the next 500 cell changes, and #3 the remaining 400 cell changes. A data block contains the cell states before and after the whole filtering process, i.e. combined result of several filters. Forward Execution refers to the process of replacing the previous cell state with the given post cell state in the data blocks. Backward Execution is the exact reverse, i.e. the Undo operation we usually call. Such a data storage has to be this way to ensure maximum security, e.g. in cases where the table cell’s content has changed (due to user input) before a planned undo operation!
And Maximum Execution Time is needed because PHP scripts are given some time to execute, usually about 30 seconds. SSR tries to increase this limit to some minutes, because updated database tables with several indexes and constraints might actually take some time (the relational mysql database is optimized for read access, not write access). The result would be that SSR will always fail to update tables or undo operations in cases of very large tables and massive updates and / or slow database servers!
To sum up: should you ever get an error message like ‘exceeded maximum execution time’, reduce the block size and try to increase the execution time limit (which is not always possible, because some web hosting environments are configured such that php init values may only be changes from outside of php scripts, i.e. from .htaccess files).
And thanks for sharing your ideas on what tasks most users might need.
Maybe reading the SSR draft documentation might give you more insights into how this plugin works. However, I must confess that it’s just one page, yet.
Thread Starter
LMP
(@loizos16673)
Well, that was a waste of a perfectly good explanation 🙂
I’m afraid you lost me somewhere around the second sentence of your post.
I’m not a database expert, so I’m not familiar with terms like ‘definition schema’.
From what I gathered, you’re saying that the ‘Simulate’ button will save all search criteria, along with the pre-altered data so that the user can undo the changes later on. And the block size somehow controls in how large chunks the search criteria will be saved.
I read the SSR documentation before posting in the forum. However, it read like an alien language. Sorry.
<joking>I think you are suffering from what I term “UNIXitis”. Several of my friends are afflicted by it. Its main symptom is an extreme affinity with machine code -or other types of technical terminology- resulting in an increasing inability to communicate in plain language.
A good example is saying something like “empirical evidence suggests a correlation between gravity fields and manually supported objects of an unbalanced nature” instead of “stuff will fall if you drop them”
Another symptom is a tendency to grow a beard.</joking>
LMP, I’m as confused as you are 🙂
