We're looking to use our TWiki as part of our development process. As we produce releases of our product, we will create a master release page for the current tool.
The goal is that at any time, someone could start from this page and produce an identical version of the current release.
Is it possible to 'tag' TWiki pages? (By 'tag' I am referring to the sense as it is used in the versioning of source code).
The only way I can see to do this is to hard code revision tags into the links between pages, although that in itself will be very difficult to maintain.
Cheers!
A solution, using revisions, is to include a table at the top of each page where the released product version links to a specific revision of the current page that is appropriate for that release. Something like:
| *Release* |
| [ [http://twiki/Page/rev=1.7] ][Product 4.0 -]] |
| [ [http://twiki/Page/rev=1.4] ][Product 2.0 - 3.0]] |
| [ [http://twiki/Page/rev=1.2] ][Product 1.0]] |
An advantage of this is that a modification to a leaf page does not require links to that page to be updated. The readers select the product version they are interested when they navigate to the page.
This is a similar technique to that used in other documents where they say: For the most recent version of this document see http://www.mypage.com/README.
Related
I recently created new category of products.
The ID and name are base of every link in my shop like in example below.
www.example.com/ID-CATEGORY_NAME
Newest category with ID 12 somehow links to one of the old categories.
So instead of redirecting to www.example.com/12-categorynew it links to www.example.com/5-categoryold which is valid link but for another category of products. Any idea what may caused that? I'm running 1.7.5.2 version. No change in code was made yet.
You probably already found a solution; however, I would start with the following:
Try to clear the cache.
Try regenerating the category tree.
The reason I answer is different though: If you have not updated your Prestashop yet, then do so quickly. For versions < 1.7.8.7, a security issue was found back in July of 2022. You should have been notified by Prestashop about this.
We are working with Storybook in our React Native project and were wondering how to organize our components since nested structures are not supported. From the web application, we are used to creating individual components and building our "pages" from them. We have been aiming for a similar workflow for the React Native application, but are having trouble implementing it. Target is a structure like that:
Components
--Buttons
----Button 1
----Button 2
--Input Fields
----Input Field 1
----Input Field 2
Pages
-- Page 1
----Sub Page 1
----Sub Page 2
-- Page 2
...
as you mentioned this feature isn't yet implemented. However you can to some degree group things together by making them part of the same story.
For example if you used
storiesOf("Buttons").add("button1")
You can also do
storiesOf("Buttons").add("button2")
In another file and since the stories of is the same they will be grouped under Buttons.
However having a third level of nesting is not really doable currently. You could Start all page stories like
storiesOf("Pages/Page1").add("SubPage1")
storiesOf("Pages/Page2").add("SubPage1")
And then they should be appear together whenever you search Page for example.
I realise its not ideal but I have it in the backlog to add this feature to the project. Once 6.0 is ready the aim is to introduce the grouping feature as an enhancement for the first milestone after the initial release. So 6.1 probably is what I'm hoping for.
I have an online shop in development, all went well until I decided to do SEO on the shop. After this, if I chose a product variation from front-end it just redirects me to a random product.
This picture describes the first state. The default product load.
This picture describes what is happening after you select a variation. As you can see the product name stays the same, but the link indicates that a totally different product is displayed.
If I have the debug mode enabled when selecting a variation it throws "An error occurred while processing your request" and in the request file I can see that besides some errors (Deprecated: array_key_exists(): Using array_key_exists()) it shows the request for a different product.
I can't understand why this is happening, so I am in dying need of your help.
That's the way Prestashop 1.7 works :
First time a customer lands in a multi-variation page, the default attribute will be loaded,
URL will show only the ID product.
Once you choose an attribute , an AJAX call will refresh the page
with the current attribute and URL will change with id_product-id_product_attribute value.
Not sure what you mean by "random product" as in both of your examples I see an attribute
being selected.
Anyway there are several (paid) modules to change this behaviour in a better SEO perspective,
this is definitely one of the most famous :
https://addons.prestashop.com/en/url-redirects/16633-pretty-urls-seo-friendly-url-remove-ids-numbers.html
EDIT: Just noticed that the ID product is different in the two screenshot, this could be related to some DB issues with attribute too, you should check if you have some not coherent values between id_product and id_product_attribute(s)
I found a fix for this. Apparently or appeared because I was using the duplicate function for uploading products. I don't know why but on some products it makes this behavior.
I've spent over 12 hours to find a explanation for this and I was unable to find one. The PrestaShop forum straight up banned me for posting this topic.
My advice is to NOT USE PRESTASHOP it's and old sistem and full of bugs, the support is expensive and I get the impression that even they don't understand their system.
If you find yourself in this situation, know this. Don't duplicate and upload products using "add new" function.
And I can't state this enough, do yourself a favour and don't use Presta, with all the expenses the time to invest and what the product looks like at the end of the road, is just a waste of time. Even after you finish is guaranteed to break in 1-2 years, any updates will break your store and you will need to invest even more more to fix it. It's an old, slow and buggy CMS. It's days are numbered.
Thanks a lot for help.
Best regards, Daniel.
I have standard plan of Big Commerce store.
I have to integrate product filter dropdowns in my store. So which is the best way to achieve this functionality.
Kindly suggest
Thanks in advance
You have a few options:
1.) Upgrade to a Pro or Enterprise plan, and activate product filtering.
2.) Install a product filtering app and configure.
3.) Make a purely JavaScript solution where you hit different product list pages and append results to the current page.
4.) Make a standalone PHP app (or other BC API supported language) and use JS to hit and display the filtered products on your page.
Options 1 & 2 require no code. Options 3 & 4 could take lots of hours to implement. It depends what your budget is, and the requirements of your project.
I've been working on a project that requires draft/live versions of content and have thought of a design such as below:
Article
ID
Creator
CreationDate
DraftContent(fk to ArticleContent)
PublicContent(fk to ArticleContent)
IsPendingApproval
ArticleContent
Title
Body
I am wondering if it would be better to change the foreign keys upon an article being published or if it is better to just copy the contents from the draft table to the live table.
Any suggestions?
Edit: Both draft and live versions exist at once although the live version is the only one that is visible to the public. There can only be one draft and one live table
Part of the reason for this design is to force users to have their articles approved before they go live.
Update:
We decided to use Kieren's solution with a slight modification. Instead of using a column for items like IsPublished IsLive we decided to use a single state column. Otherwise the design remained the same.
Draft articles that become live and then are 'published'
The usual thing would be to have a status/type flag on the article table - IsLive.
Using separate tables is unnecessary and redundant; changing foreign keys doesn't make much sense either. Think of the article as a valid object, whether its draft or live. The only difference is, in most cases you only want to display live articles. In some cases in the future, you might want to display both.
Articles that might be edited and have a new draft version after initially becoming live
In terms of one article having both a live and draft version - the most common pattern would be to have a master Article entity/object, and then say ArticleVersion coming from that. The ArticleVersion would have the IsLive property, or even better, the Article itself would have a property, CurrentLiveVersionId. That way there can be a live and draft versions lying around, but you'd only usually join Article onto the ArticleVersion by that CurrentLiveVersionId to get the current live version.
Advantages of having the ArticleVersion table include the fact that the entire history of an article, a changelog, can be stored, so you can revert to previous versions if needed, or review changes. All for a very low implementation cost..
Let me know if I can clarify this method.
Your design looks appropriate to me. When a new version goes live, I would:
UPDATE the PublicContent key to point to the (formerly) draft article.
DELETE the no-longer-referenced formerly-published article.
NULL the DraftContent key or, if your model calls for always having a draft version, INSERT a new, empty draft into ArticleContent and point the DraftContent key to it.