Forum Replies Created

Viewing 15 replies - 1 through 15 (of 36 total)
  • Hi Kim,

    To avoid the complication of catering for possibly empty fields in the “publication-search-form”, I have added a default “%” sign as a value parameter to the <input> line(s) of the code – e.g.:-

    <input type="text" id="wp_owner_name" name="wp_owner_name" value="%" />

    The “default where” is then quite simple:-

    owner_name like httpGet[‘wp_owner_name’]

    The behaviour is then correct, regardless of whether the user enters a value in the box to replace the % sign, enters additional text beside the %, or leaves it untouched. Of course, if the user removes the % sign, but doesn’t enter anything to replace it, then I suppose it will fail – but that’s not a very sensible choice!

    However, the outstanding question is how to cater for multiple entry fields on the publication-search-form? I have not yet found the appropriate “where” clause for that requirement – but it is handled very satisfactorily on the old version.

    Any suggestions gratefully received!

    Thanks,

    Nigel

    Hi Kim,

    Thanks for your message and the video. I have tested that setting on my site, and it now functions correctly.

    I presume that the same configuration can be used for multiple input fields, which may or may not be populated, with a suitably amended “where” clause? I will do some more testing to see if I can generate a suitable clause.

    The only outstanding issue is the question of whether the URL field functions as a link – should I raise a separate topic, as I realise that it is not quite the same question that Charles raised?

    Thanks again for your help.

    Nigel

    Hello Peter,

    Thanks for your help.

    I am trying to implement the approach that you described, based on the pages that I have already created.

    Firstly, I have a page "Search for owners" which uses the publication-search-form model to populate the fields, and submit the query. This has four fields, but I am only using the owner_name field for this test. In the "old" publication-search-form this is defined as "wpda_search_column_owner_name".

    In the App Builder, I have an app named "Owner list". I run this app in the App Builder, and select "Table Builder". I have tried various versions in the "Default where" clause setting, but without success

    If I use? "where owner_name = $wpda_search_column_owner_name" in the "Default where" clause,? then I see this message on the results page:-

    "Unknown column '$wpda_search_column_owner_name' in 'where clause'"

    I have also tried this clause, but similarly without success:-


    owner_name like httpGet['owner_name']

    I have also tried various combinations, as shown in the explanatory notes, but without success. The only version that gives correct results is one such as this:-

    owner_name like "Frampton"
    OR owner_name like "Red%"

    This one does show the correct results, but the URL field is still not clickable.

    Please note that the dev.bristol-re.... site is password-protected - please let me know if you need to run any tests.

    Thanks in advance for your help.

    Nigel

    Hello,

    I have a question which is ( I think! ) related to the issue that Charles has raised.

    I have a page with a tabular view of the contents of an SQL view from one table, with a field which contains a URL link to a detail view of the corresponding data record. The format is :-

    https://dev.bristol-re.co.uk/owner-details/?wpda_search_column_owner_id=1

    I have tested it in the new App Builder and Data Explorer ( also new ), the link functions correctly, and opens the relevant page. However, in the browser, the URL is displayed as plain text, and does not function as a link.

    The link field is set to plain text, not hyperlink – this generally functions correctly ( in the old Data Explorer, etc, )

    Thanks in advance for your help.

    Nigel

    Thread Starter rc169

    (@rc169)

    Hello Kim,

    Thanks for your message. At the moment I have added a message to the affected sites, that users may need to switch to a different browser.

    I understand the point about legacy tools, but I cannot move my tables to the App Builder since I make use of the “publication-search-form” on some of my sites. Peter advised me that it would be replaced by a new version on this topic:-

    https://www.ads-software.com/support/topic/demo-app-display-strange-behaviour/

    I am therefore waiting for the new version before moving the tables to the App Builder.

    Thanks for your help.

    Nigel

    Thread Starter rc169

    (@rc169)

    Hello,

    …and further follow-up info: I have been advised that the problem does not appear in Microsoft Edge. I don’t know about Safari, but it would seem that the problem is probably specific to Firefox.

    Nigel

    Thread Starter rc169

    (@rc169)

    Hello,

    Further follow-up information: this problem seems to be specific to certain browsers. I have tested the behaviour in Firefox, Chromium, Google Chrome and Opera this morning – and only Firefox is affected. The green “plus” buttons function correctly in the other three browsers.

    Thanks again,

    Nigel

    Thread Starter rc169

    (@rc169)

    Hello,

    I have subsequently tested the behaviour on another site, where I have used a different theme. The behaviour is the same, so that the problem would seem not to be related to the theme used on the site.

    Thanks in advance for your help.

    Nigel

    Thread Starter rc169

    (@rc169)

    Thanks Peter. Glad to have been of assistance.

    That is good news about the “publication-search-form”. I will keep an eye open for more news on that topic.

    Regards,

    Nigel

    Thread Starter rc169

    (@rc169)

    Hi Kim,

    Thank you. I have sent the message via the Contact | WP Data  Access page, as requested.

    Apart from straightforward display of data in tables and SQL Views, my usual approach has been to setup a page containing an input page using the “publication-search-form” script ( id = 64 ) from your Code Manager app as a basis ( https://code-manager.com/code/ ). In other words, as per the demo at https://wpdataaccess.com/publication-search-form-demo/ . On that page, I have a shortcode, such as [cmruncode name=”publication-search-for-objects”].

    When the user submits the data that they have entered as search criteria, the next page shows the list of filtered results, derived from another shortcode, for example, [wpdataaccess pub_id=”1″]. These elements were listed on the “Tables” section of WP Data Access – the page with the listing is entitled “Data Tables”.

    I presume that I can continue to use the “publication-search-form” script from Code Manager as before, but I am not sure how to get to the next step. I presume that I need to use a “Data Table” from the new App Builder – so do I just substitute the Front-end access short code? in place of the earlier type with the “pub_id”?

    Thanks in advance for your help.

    Nigel

    Thread Starter rc169

    (@rc169)

    Hi Peter,

    I have now enabled debug mode (on the Settings -> WP DataAccess page in the WordPress console), and I have tested the application. I tried to switch to page 2 of the list of entries in the table (there are 300 records in total in the table), but the system has clearly crashed, although the moving black line at the top of the table on the page is still “rotating”. The other WordPress sites on my hosting account are also now unavailable (this also happened yesterday). Eventually I get a “connection has timed out” message in the browser.

    There are three files in the /logs folder of my hosting account – access_ssl_log; error_log and access_log. I presume these are the files that you need, so I will download them and send them via the contact page of the plugin website, together with the details of the page that causes the error.

    Thanks for your help,

    Nigel

    Thread Starter rc169

    (@rc169)

    Hello Kim,

    Thanks for your message. I am currently trying to build an app with the App Builder, but there seem to be some problems. In the “Table Builder”, I have selected the columns from the selected table. When I clicked on the “Hooks” column heading, the timer icon rotated for a couple of minutes; after that everything from the window disappeared, leaving just the words “App Builder” in the top left corner.

    The hosting then seemed to crash so that other sites on my account became unavailable for a few minutes. As far as I can tell, there were no problems with availability of the servers, so I am concerned about what exactly happened when the App Builder crashed. I have not yet tested the “Hooks” column – as far as I can see from the “tutorial” page ( Creating a Data Table App ), this is not essential.

    Having created and saved the app, I can also see it in the browser – at least, the first two columns of each row. However, when I click on the symbol at the left hand end of a row (to see all columns of the record) then the app window disappears from the page. Can you advise what is wrong here?

    Thanks in advance for your help.

    Nigel

    Thread Starter rc169

    (@rc169)

    Hello Kim,

    I am trying to create an app in the App Builder, following the suggestions on the page that you mentioned above ( https://wpdataaccess.com/docs/app-tutorials/create-a-data-table-app/ ), but the column names are not editable in the Table Builder on my installation.

    Can you advise?

    Thanks in advance for your help.

    Nigel

    Thread Starter rc169

    (@rc169)

    Hello Kim,

    Thanks – yes, I do see the old Table Builder button, and it opens the correct page.

    Going back to your first post on t his thread, I have again tested the use of the “edit” button for a single record in the new Data Explorer, but it still shows a blank window. I will therefore send a ticket, as per your suggestion.

    Thank you.

    Nigel

    Thread Starter rc169

    (@rc169)

    Hello Kim,

    Thanks – yes, the patch has resolved the error when selecting “Legacy mode”. However, the menu items in the left hand column of the WordPress console, under “WP Data Access” are unchanged, so that I still cannot access the selections behind the shortcode [wpdataaccess pub_id=”10″]. The only way I can access these settings is by selecting the <WP_system_code>_wpda_publisher table from WPDA Data Explorer, where I can see (and edit) the settings behind the wpdataaccess pub_id code.

    Can you clarify whether the old codes ( e.g. the above quoted [wpdataaccess pub_id=”10″] ) will continue to work beyond 2025? Or do I have to reconfigure all of the pages that use such queries before the access to the “Legacy mode” is permanently removed?

    Thank you,

    Nigel

Viewing 15 replies - 1 through 15 (of 36 total)